Data Migration Rollback Planning: A Cutover Worksheet
Plan data migration rollback with a cutover worksheet covering decision authority, write fencing, changed data, recovery targets, and acceptance evidence.
On this page
- Overview
- Define what rollback must recover
- Set RPO and RTO as requirements, then measure recovery
- Choose the changed-data recovery path
- Identify the point of no return
- Cutover and rollback worksheet
- 1. Scope and decision authority
- 2. Write boundaries and recovery data
- 3. Triggers, acceptance, and release
- Sequence a recovery without reopening a stale source
- Rehearse changed data and blocked recovery
- Before approving cutover
A data migration rollback plan must name who can authorize recovery and specify the data state the recovered application will use. Before the target accepts writes, returning to the source may be straightforward. After it accepts transactions, the source becomes stale unless those changes are transferred back and checked.
Use the planning worksheet below to record that boundary, recovery assumptions, and the evidence needed to resume service. Download the same worksheet as plain text for your change record. Attach a runbook with commands rehearsed for your application, database engines, replication mechanism, and dependencies.
Define what rollback must recover
Plan recovery for four kinds of change, and check that the recovered versions work together:
- Schema: tables, constraints, types, and old application compatibility.
- Data: the cutover baseline plus accepted changes, including inserts, updates, and deletes.
- Configuration: endpoints, connection pools, credentials, permissions, and scheduled jobs.
- Application: a version that can correctly read and write the recovered schema.
A backup establishes a recovery point. It does not prove that an old application can use the restored database or that payments, messages, files, and other external effects have been reconciled. A traffic switch changes where requests go; it cannot copy transactions back into a stale database.
AWS's cutover guidance separates rollback before and after the target receives transactions. It recommends checkpoints, a data-handling strategy, and a person who decides between rollback and fixing forward. Its network-routing examples apply only when the data and application architecture support them.
Set RPO and RTO as requirements, then measure recovery
Recovery Point Objective (RPO) is the acceptable data-loss window. Record which transactions it covers and how the team identifies any missing transactions. Recovery Time Objective (RTO) is the required time to restore the agreed service level. Define the clock's start and end, including write fencing, transfer, reconciliation, application checks, and reopening service.
Measure recovery in a rehearsal with representative volume, write rate, and dependencies. Check the complete recovery against your target, including work after the endpoint change. Price the retained environment, backups, log retention, replication, engineering, and rehearsals needed to meet your approved targets instead of assigning a fixed budget percentage.
Choose the changed-data recovery path
| Recovery path | What it can recover | Evidence required before relying on it |
|---|---|---|
| Retained source with no target writes | The accepted cutover baseline | Prove target writes have not begun, source is consistent, and the previous application still works |
| Backup or point-in-time restore | Data available at the selected recovery point | Successful restore, readable schema, transaction coverage, and an approved treatment of later writes |
| Reverse replication or captured-change replay | Target changes that the capture mechanism supports | Reverse mappings, insert/update/delete coverage, transaction order, retained logs, replay checkpoint, and reconciliation |
| Repair on the target or recovery into another compatible environment | A recoverable target state when returning to the source is unsafe | Tested repair or restore procedure, named authority, and the same data and application acceptance checks |
Design and test reverse replication separately from forward replication. A working forward path does not prove reverse compatibility. A transformation that merges records, drops fields, changes identifiers, or loses precision may prevent recovery into the old schema. Record how those cases are handled before allowing target writes.
A change query that selects recently updated rows can miss physical deletions. Google Cloud describes ordered capture and delete markers or a separate deletion record for polling in its migration principles. The same guidance warns that application writes to two databases are separate transactions and can diverge. If using dual-write, rehearse partial failure and conflict repair.
Identify the point of no return
The point of no return is the first event that invalidates the approved rollback path. It might be the first target write without reverse capture, an incompatible schema change, an irreversible external action, log expiry, or source decommissioning. Set an observable event or deadline, its owner, and what happens after it: hold, repair forward, or invoke a separately approved recovery path.
Recheck the rollback conditions when write rates, mappings, replication health, or the target application change, even if the deadline has not passed.
Cutover and rollback worksheet
Fill every field before the rehearsal. Replace role labels with names and a reachable alternate. Keep evidence references in the change record; do not put credentials or customer data in this worksheet.
1. Scope and decision authority
| Field | Complete before cutover |
|---|---|
| Change identity | Change ID, runbook version, rehearsal date, source/target engines and versions, datasets, applications, and exclusions |
| Decision authority | Named cutover/rollback decision maker and alternate; how to reach them; escalation deadline if neither responds |
| Execution owners | Named database/replay operator, application/write-fence operator, data acceptance owner, service acceptance owner, and communications owner |
| Recovery contract | Approved RPO and RTO, transaction coverage, clock start/end, availability assumptions, and who may accept an exception |
| Point of no return | Observable event/deadline, monitor, owner, and approved action after crossing it |
2. Write boundaries and recovery data
| Field | Complete before cutover |
|---|---|
| All writers | Applications, connection pools, workers, queues, ETL jobs, schedulers, integrations, and administrative sessions |
| Source fence | Platform-specific procedure, treatment of in-flight transactions and queued work, evidence that every source writer is stopped or rejected, and final source commit position |
| Final synchronization | Applied target position, lag/backlog evidence, rejected changes, snapshot boundaries, and reconciliation report |
| Target write opening | Named approval, opening timestamp, first target commit/capture position, and source-fence confirmation |
| Post-cutover capture | Inserts, updates, deletes, key changes, ordering, transaction boundaries, checkpoint/retry rules, retention deadline, monitoring, and owner |
| Reverse compatibility | Versioned inverse mappings, non-reversible fields, conflict policy, sequence/identity handling, and old application compatibility |
| External effects | Payments, messages, files, downstream changes, and retry/deduplication or compensation procedures with owners |
| Recovery fence | Target-fence procedure, drained/aborted transactions, final target commit/capture position, and evidence the recovered source stays fenced during replay |
3. Triggers, acceptance, and release
| Field | Complete before cutover |
|---|---|
| Triggers and stop conditions | Signal, threshold, observation window, evidence location, observer, and escalation; include missing capture, incompatible replay, and unexplained discrepancies |
| Recovery sequence | For each step: prerequisite, tested command/script version, expected result, evidence, operator, stop condition, and next escalation |
| Replay evidence | Captured boundary, applied boundary, backlog/gaps, rejected events, duplicate/conflict handling, and insert/update/delete reconciliation |
| Acceptance checks | Key-set and mapped-value equality, critical totals/relationships, approved exceptions, old application workflows, access controls, and dependent systems; name each approver |
| Reopen service | Decision record, data/service owner approvals, single active writer confirmation, endpoint/pool checks, monitoring, and communications |
| Rehearsal and retention | Actual recovery time/data loss, environment differences, unresolved gaps, rerun evidence, rollback-path expiry, and separate source-decommission approval |
Add the tested commands and expected results to your platform-specific runbook. Do not substitute a generic Kubernetes scaling command for a write fence: background jobs, administrative clients, or already-open connections may still write.
Sequence a recovery without reopening a stale source
Use this order to plan the dependencies between recovery steps. Each step still needs a tested procedure for your platform:
- The named authority evaluates the trigger, current rollback boundary, and recovery options. Record the decision and notify execution owners.
- Fence target writes through the rehearsed controls. Drain or abort in-flight work under the agreed policy, retain queued work, and record the last committed target position. Keep source application writers fenced.
- Verify capture reaches that position. If logs are missing, transformations cannot be reversed, or conflicts remain unexplained, stop and escalate; do not point applications at the stale source.
- Restore or prepare the recovery database and replay supported changes through the boundary. Apply updates and deletes as well as inserts. Use durable checkpoints and tested retry behavior; prevent replication loops and competing writers.
- Reconcile the recovered state against the accepted target boundary under the mapping contract. Validate application/schema compatibility, critical workflows, permissions, and external effects.
- Obtain data and service acceptance. Switch the appropriate application configuration and endpoints, check pooled connections and dependencies, then enable the chosen single writer. Monitor and preserve the evidence.
See database migration testing strategies for a worked reconciliation example. The data migration best-practices checklist covers the wider migration lifecycle.
Rehearse changed data and blocked recovery
Start with a tabletop review of decision authority, communications, and dependencies. Then test restore, fencing, mappings, replay, and application compatibility separately. Finally rehearse the complete cutover and recovery using the versions intended for production.
Include transactions after cutover: change an existing value, insert a record, and delete one. Demonstrate that the recovered system reflects all three. Also exercise missing change records, replication lag, a replay retry, an unavailable dependency, and a reconciliation failure. Inject failures in an isolated rehearsal environment and define how to stop and contain the test.
Retain the command outputs, positions, mismatch report, approvals, and actual recovery duration. Record differences between rehearsal and production. A toy example can explain a mechanism; it cannot establish your production recovery target.
For a local illustration, download the SQLite reconciliation demonstration. Its exact commands, results, inputs, and limitations appear in the testing article. It performs no production database or infrastructure operations.
When a supplier owns recovery, the data modernization provider comparison can help identify candidates. Ask the delivery team for evidence of changed-data replay and a measured recovery rehearsal for a comparable source-target pair. Require a rehearsal in your environment; a past result cannot establish your RPO or RTO.
Before approving cutover
Confirm that the worksheet has named owners, the current runbook has been rehearsed, post-cutover changes have a recoverable path, and acceptance evidence meets the approved targets. Hold the change and escalate to the decision maker if a data discrepancy remains unexplained or an inverse transformation is untested.
Reviewed October 1, 2026. The worksheet and recovery sequence are editorial planning guidance informed by the linked primary sources. Provider documentation describes specific capabilities and constraints; it supplies no universal failure rate, rollback budget, or recovery duration.
Chief Analyst, Software Modernization Intelligence · 10+ years B2B market research
Published: ·Updated: