Skip to content
  • New: asasii S2 handheld barcode scanner. 1D and 2D, IP52 rated.View S2
  • asasii POS is live and deploying to Malaysian retailers.See asasii POS
  • asasii BSC: supply chain software for multi-outlet operators.See asasii BSC
  • Browse the full asasii hardware line: terminals, printers, scanners, payment, drawers.View hardware
idataraya
idataraya

Migrations.

Move off legacy without losing a row.

We migrate databases, warehouses, and pipelines from the systems you've outgrown to the ones you need. Schema mapping, data validation, dual-write periods, and cutover plans that don't require a weekend downtime window.

  • Schema mapping and data type translation
  • Dual-write migration with rollback capability
  • Row-level validation before and after cutover
  • Zero-downtime cutover plans
legacy-to-modern · cutoverDual-write · 72h window
Running
SourceOracleMaptypesDual-writeliveValidaterow-levelCutovertarget
Step 6 of 11 · rollback armed
OBJ-07 · customersObject migration trace
Dual-write
MappingValidationCutover
oracle → postgres · mapMaterialized
customersTable2.1M rows
ordersTable8.4M rows
sp_recalc_totalsProcrewritten rows
vw_monthly_revViewmaterialized rows
148 objects · 0 unmapped
dual-write · hour 38 of 72Both systems in sync
  • Source writesOracle · 100%
  • Target writesPostgres · 100%
  • Read trafficTarget · 68%
  • Rollback pathSource authoritative

Legacy out.

Every migration follows a disciplined process: map, validate, dual-write, cut over. No big-bang weekends, no prayer-based deployments.

Every object mapped before a single row moves.

A full inventory of schemas, stored procedures, jobs, and cross-table constraints. Type-safe column-by-column mapping with explicit handling of encoding and precision differences between source and target.

oracle → postgres · mapMaterialized
customersTable2.1M rows
ordersTable8.4M rows
sp_recalc_totalsProcrewritten rows
vw_monthly_revViewmaterialized rows
148 objects · 0 unmapped

Dual-write until the new system is proven.

Writes land in both systems, reads shift gradually. If the new stack surprises us, the old one is still authoritative. No prayer-based cutovers, no weekend war rooms.

dual-write · hour 38 of 72Both systems in sync
  • Source writesOracle · 100%
  • Target writesPostgres · 100%
  • Read trafficTarget · 68%
  • Rollback pathSource authoritative

Row-level proof, not sampled hope.

Automated row-count, checksum, and hash comparisons before and after cutover. Discrepancies are flagged to a queue, not buried in a log file, and we do not cut over until the queue is empty.

Validation · pre-cutover sweep
customers · row countSLO 0 drift0
orders · checksumSLO matchmatch
order_items · hashSLO matchmatch
payments · driftSLO 0 rows4 in flight
412,881 rows verified · 4 transient drifts

Cutover rehearsed in staging, run in production.

A runbook with rollback at every stage, rehearsed end-to-end in staging before we touch production. Afterwards, the legacy system is wound down with a documented retention window, not left running on a forgotten server.

Cutover runbook · orders-db
Staging rehearsal · full cyclerollback tested
4h 12m
Production cutover · traffic shiftstep 6 of 11
18m
Validation sweep · post-cutscheduled
T+30m
Legacy decommissionretention 90d
T+90d
0 rollbacks triggered · staging-verified

A clean migration with proof it worked.

  • Migration scripts

    Version-controlled, idempotent migration scripts that can be re-run safely. No manual SQL, no one-off patches.

  • Validation report

    Row-count and checksum comparison between source and target, run automatically before and after cutover.

  • Cutover runbook

    Step-by-step procedure with rollback instructions at every stage, tested in staging before production.

  • Decommission plan

    Timeline and checklist for shutting down the legacy system, including data retention and compliance requirements.

Ready to talk about migrations?

Book a discovery call. We will walk through how this fits your business, scope, timeline, and what you will get at the end.