Database Migration Cutover: A Rollback Decision Runbook

When should a migration cutover proceed, pause or roll back?

The answer should be agreed before the cutover begins. A rollback decision runbook defines the evidence needed to proceed, the conditions that require stopping, and the people authorized to make those decisions. It turns a technical sequence into an operational plan.

This article focuses on the final transition rather than selecting a migration platform. A low-downtime approach still needs a controlled decision window; replication alone does not settle application routing, transaction consistency or how new target-side writes would be handled after a failure.

Establish the business limits first

Ask the business owner to approve acceptable downtime and data-loss limits. Identify functions that must remain available, processes that can pause, and dependencies that would make a partial transition unsafe. These are project-specific decisions, not universal numbers.

Define who can approve go-live and who can call rollback. List communication channels and support coverage. A runbook that depends on an unavailable approver is not ready for production, even when the technical tasks have been rehearsed.

Write a sequenced cutover plan

Each step should specify the operator, prerequisite, expected evidence and a stop condition. A practical sequence may include confirming backups, restricting writes, completing final synchronization, validating the agreed boundary, changing application connections and observing critical transactions. The exact order depends on the systems involved.

Do not assume every workload can be safely write-frozen. If transactions must continue, document how changes are captured and reconciled throughout the transition. Also identify external consumers, scheduled jobs and integrations that may write to the old endpoint after application routing changes.

Record connection configuration, credentials handling, cache behavior and scheduled tasks. Check the complete request path rather than only a direct query against the new database.

Distinguish recovery from rollback

Recovery fixes a problem on the new system; rollback returns service to a prior state. The two may have different consequences. Once the target accepts new writes, returning to the source can create a reconciliation problem. Decide in advance whether those writes can be replayed, reverse-synchronized or otherwise preserved.

A useful decision table contains three conditions:

• Proceed: approved reconciliation checks pass and critical application tests meet the agreed criteria.
• Pause: an issue needs investigation while the safe decision window remains open.
• Rollback or invoke a contingency: a predefined threshold is exceeded or the team cannot demonstrate correctness within the approved window.

State the consequences and authority for each choice. A generic instruction to 'roll back if anything fails' is not executable enough.

Rehearse the decision, not just the commands

Run the plan in a representative nonproduction environment. Measure how long essential steps take, verify that evidence is captured, and deliberately test an interruption. Confirm that operators understand the point after which reversal becomes more complex.

Microsoft's migration execution guidance covers readiness, execution and rollback considerations. Its workload migration execution documentation describes preparation, cutover and post-cutover activities. Adapt the guidance to your workload; it does not replace a rehearsed system-specific runbook.

Keep checking after the routing change

Monitor reconciliation, failed transactions, queued work and downstream reports after cutover. Assign an observation period and an owner for unresolved issues. Remove the old system only after the agreed retention, backup and business acceptance decisions have been completed.

You'll Love Our Smart AI Data Studio (Demo), Try It to explore file-based comparisons, SQL and reporting before discussing a migration. The demo permits 100MB per file, while deployed solutions can support 5GB uploads; it does not execute production cutovers.

Izan Technologies delivers custom data migration, data engineering and cloud solutions. All IP in anything we build, provide or deliver belongs to you. Request a consultation to scope your cutover and acceptance plan, or explore our services.