For a cutover that survives contact with production
Data Migration Services
A migration that stops the business is a failure, even if every record eventually arrives correctly. This practice runs old and new systems side by side, validates data continuously, and moves functions across only once reconciliation proves they agree. A rollback stays live until the last validation clears, not after.
How a low-downtime cutover actually gets proven
Dual-run sync, reconciliation checks and the rollback that stays ready, walked through end to end.
80 secSample frame · video pending01Before any cutover gets scheduled
Downtime tolerance decides the whole approach.
A fixed cutover window and a zero-downtime requirement need entirely different engineering, and picking the wrong one costs later. Four questions settle which approach actually fits.
Can the business accept any downtime window?
If a short, scheduled outage is acceptable, a simpler cutover migration is faster and cheaper to build than a dual-run approach.
How large and how live is the dataset?
A small, mostly static dataset migrates simply. A large, constantly changing one needs continuous synchronisation, not a single copy pass.
What is the cost of a discrepancy after cutover?
Financial or regulated records demand exhaustive validation. Lower-stakes data can tolerate a lighter reconciliation pass.
Is a rollback genuinely possible after cutover?
Some migrations are one-way once the source system retires. Confirming rollback feasibility changes how cautious the plan needs to be.
| Cutover migration | Dual-run migration | Platform migration | |
|---|---|---|---|
| Downtime | A scheduled window | Near zero | Depends on scope |
| Complexity | Lower | Higher, needs sync | Infrastructure-level |
| Validation | One full pass | Continuous reconciliation | Workload-specific |
| Owned by | This practice | This practice | Cloud migration |
02Fixed before the cutover date is set
What stays yours while the migration runs
Every migration engagement fixes the split up front: which systems you bring, what gets built around them, what returns to you, and what stays under your control regardless of the approach.
- Your side
You bring
- The source system and its full data model
- The target system the data is moving into
- The cutover date the business already committed to
- Our side
We build
- A field-by-field mapping between source and target
- A rehearsed migration script validated on a full copy
- A validation pass comparing every migrated record
- Your side
You receive
- A completed migration inside the agreed window
- A validation report covering every record moved
- A rollback plan kept ready until sign-off
Never leaves you
- The decision to declare the cutover complete
- Ownership of both source and target systems
- Approval of the final validation report
Where the line sitsWe carry the migration mechanics. Declaring the cutover done, after seeing the validation report, stays your call alone.
03From two systems to one trusted record
Four stages, each closing on an artefact
Migrations fail quietly when validation gets treated as an afterthought instead of a gate. This system makes each check explicit and closes every stage with something you can inspect.
Map source to target completely
Every field, transformation and edge case is documented before a migration script writes a single record.
A field-level map between both systemsRehearse the migration on real data
The script runs against a full copy of production data first, so surprises surface before the real cutover date.
A rehearsed run against a full copyValidate before, not after, cutover
Every migrated record is compared against its source before the old system is allowed to retire.
A reconciliation report covering every recordHold rollback ready until sign-off
The path back to the old system stays rehearsed and ready until your team formally accepts the migration as complete.
A rollback kept live until sign-off
04What actually drives the number
Four drivers, not a flat rate card
Migration work is priced against the assessment, because these four factors change the effort by multiples, not by a small margin.
Downtime tolerance
A zero-downtime requirement costs more to build than a scheduled cutover window, because it needs a live synchronisation layer.
Dataset size and rate of change
A large, constantly updating dataset needs continuous reconciliation. A smaller, static one migrates in a single validated pass.
Schema and format differences
A near-identical schema maps quickly. Structural differences between source and target need transformation logic built and tested.
Validation and audit requirements
Regulated data demands an exhaustive, auditable reconciliation trail that a purely internal, low-stakes dataset does not.
05Evidence and proof
Cutovers proven before they were declared complete.
Migration proof is downtime avoided and records reconciled, not migration speed. Every record here waits for written client approval before production.
Explore case studiesA ledger platform switched providers without a single outage.
Vela Ledger needed to leave a legacy provider without disrupting live transaction records. A dual-run sync kept both systems in step until the final cutover.
- Customer-visible downtime
- None recorded
- Records reconciled before cutover
- Every migrated record
A failed prior migration was diagnosed and corrected cleanly.
Tern's earlier attempt at a system move left shipment records out of sync. A reconciliation pass found and corrected every discrepancy before a second attempt.
- Discrepancies identified
- Fully accounted for
- Second attempt outcome
- Completed cleanly
The rollback plan sat ready the entire time. We never needed it, but we would not have signed off without it.
Sample · pending client approval
06Read this first
When this migration practice is the wrong spend
Selling a dual-run data migration to a project that is really an infrastructure move costs more than it earns in trust. The exits are marked before the pitch. When the build is justified, it runs on your existing databases and warehouse tooling.
- Cloud migration
The real move is infrastructure, not data shape
Lifting a workload to new infrastructure without changing its data model is a platform question, scoped separately.
- Data governance
The real question is data ownership policy
Who is allowed to access which migrated data is a governance decision, not a migration engineering task.
- Team extension
Your team should own this build
If your engineers already understand both systems and just need capacity, team extension gets you there without an added delivery layer.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | The mapping and cutover date are settled | Priorities and acceptance | Migration and validation delivery |
| Delivery pod | Several systems migrate over time | Product decisions each cycle | Engineering, validation, releases |
| Team extension | Your leads run delivery well | Standards and roadmap | Named engineers and continuity |
07Straight answers
Asked before a cutover date is set.
01Is zero downtime always achievable?
Not always, and claiming otherwise upfront sets a false expectation. Some systems genuinely require a short, scheduled window, which a cutover approach handles more simply than a forced dual-run.
02How do you keep two systems in sync during a dual-run?
Through a dual-write or replication layer that mirrors changes between source and target continuously, paired with reconciliation checks that catch any drift between them quickly.
03What happens if validation finds a discrepancy?
The affected records are corrected and re-validated before cutover proceeds. A discrepancy found during validation is far cheaper to fix than one found after the old system retires.
04How is this different from a cloud migration?
This practice moves and validates data itself, at the record level. Cloud migration moves the infrastructure and workloads a platform runs on, which is a separate engineering problem.
05What does a data migration cost?
Scoped engagements are priced against downtime tolerance, dataset size and validation depth from the assessment. Ongoing delivery runs as a monthly team commitment for larger, phased moves.
06Can you take over a migration that already went wrong?
Yes, starting with a diagnosis of exactly where the two systems diverged rather than a fresh-attempt pitch. Recovery needs an honest account of the prior failure first.
07Do you keep a rollback plan ready throughout?
Yes, a rehearsed rollback stays available until your team formally signs off on the validation report, not only during the planning phase.