Data migration: define the last safe rollback before cutover

The cutover plan says “switch back if there is a problem”. The new platform will accept customer updates as soon as traffic moves. Unless those updates can also reach the old platform, the rollback instruction is incomplete before the migration even begins.

For the data platform lead, a credible migration plan has two related proofs: the destination produces the required business outcomes, and the team knows how to recover after writes begin to diverge. A completed copy job establishes neither on its own.

Reconcile the result the business uses

Identify the datasets, producers and consumers that must move together. Include scheduled extracts, reporting jobs, APIs and operational applications. A database can be internally consistent while a downstream process still reads yesterday’s export or applies an old transformation.

Set acceptance rules at three levels. First, compare completeness: expected records, partitions and rejected items. Second, compare values and relationships, including keys, nulls, timestamps and updates. Third, compare the outputs used to make decisions or complete transactions.

In a hypothetical order dataset, both systems contain three records worth £1,000 each before adjustments. One record has a £200 cancellation adjustment. The old report shows £2,800; a new transformation that ignores the adjustment shows £3,000. The row count matches, but the business result differs by £200.

The owner must decide whether a difference is an intended change, a timing effect or a defect. Define any tolerance with a reason: a rounding allowance may be appropriate for a particular calculation, while a missing customer record is not cured by a percentage tolerance applied to the whole table. Include representative edge cases such as late events, corrections and deleted records.

Know what the migration tool actually validated

AWS Database Migration Service data validation compares source rows with corresponding target rows and reports mismatches. AWS also documents pending and suspended records, and requirements such as a primary key or unique index. Validation consumes additional source, target and network resources.

Build time and capacity for that work into the plan. A table waiting for validation has not passed. A table the tool cannot validate needs another agreed method. Check the current limitations for the particular engines, data types and transformations rather than assuming that enabling a task option covers the entire migration.

Keep row-level validation separate from the report or application test. Even correctly copied source data can feed a changed business calculation. For an analytical platform, reconcile representative queries and reporting periods; for an operational database, exercise the transactions and downstream effects that matter.

Mark the point where the recovery problem changes

Before the destination accepts writes, recovery may be as simple as returning consumers to the unchanged source, subject to the architecture and any external effects already triggered. After the destination accepts unique writes, the team must account for them.

AWS’s guidance on migration rollback explicitly describes the limitation of basic fallback: changes made on the new target after cutover can be ignored or lost when applications are switched back. It discusses alternatives including dual writes, bidirectional replication and a further replica, each suited to particular circumstances.

Choose and rehearse a recovery design for the actual workload. Reverse replication needs supported types and transformations, a known starting position and a plan for conflicts. Replaying a transaction journal needs reliable ordering and protection against duplicate effects. Dual writing needs a response when one write succeeds and the other fails. Naming a pattern does not establish that these conditions hold.

There may be a point where fixing forward is safer than returning to the old system. Make that decision boundary explicit, with the person authorised to invoke it. The boundary could depend on the first target-only write, an incompatible schema change or an irreversible downstream action.

Turn the cutover rehearsal into evidence

Rehearse the sequence with the relevant application owners. Identify how writes are paused or redirected, which queues must drain, how replication lag is measured and what establishes a consistent comparison point. A low lag reading alone does not prove that every consumer is using the same state.

Use a small set of traceable test transactions around the handover: an insert immediately before the pause, an update during the transition and a correction after the destination becomes authoritative. Follow them into downstream outputs. Then invoke the chosen recovery path and establish where each transaction ends up.

The go/no-go decision should include unresolved validation failures, untested consumers, recovery duration and the operational cost of extending parallel running. Give each accepted difference an owner and an explicit consequence. Avoid turning a collection of exceptions into a blanket migration pass.

Retire the source only after the agreed observation period and recovery conditions have been met. Preserve the evidence and access needed for outstanding reconciliation, while applying the approved retention rules to temporary copies. Use the same service-level thinking in the wider cloud exit plan: moving the data is one dependency in moving the business service.