Data migration cutover plan: template and rollback

What is cutover in data migration?

Data cutover is the point at which the new system becomes the authoritative place for live work. Migration copies and transforms records; cutover controls the final changes, validates the result and switches users, integrations and scheduled jobs to the new system. A successful import alone does not establish that the service is ready to take over.

A data migration cutover plan records the sequence, responsible operators, evidence required to proceed and conditions that stop the switch. Agree on the write policy first: a planned freeze, controlled synchronization or a phased move with explicit ownership. The right choice depends on the interruption the business can accept and the synchronization the team can actually verify.

Migration begins before the import script

A migration plan must define what happens to data created while the move is in progress. Inventory entities, identifiers, relationships, timestamps and attachments. Decide which system owns writes at each point. A script that imports yesterday’s snapshot correctly can still lose today’s changes. Name the business owner who accepts the result and the operator who can stop the cutover.

Rehearse with representative, protected data

Use sanitized data that includes duplicates, missing values, old status codes and large records. Check totals and relationships, then verify a sample of complete business journeys. For a fictional membership service, matching the member count is insufficient: active entitlements, payment references and cancellation state must also reconcile. Record how long rehearsal steps took in that environment rather than promising an unmeasured outage window.

Define reconciliation beyond record counts

Prepare checks for counts, key relationships and business meaning before writing the migration script. In the membership example, verify that a current entitlement points to the correct member and subscription, and that a cancelled membership is not accidentally reactivated. Check attachments and reference identifiers as well as the main table. Keep a list of records intentionally excluded, with the reason and the person who approved it. An unexplained difference is a failed check, even if the total number of imported rows looks reassuring.

Write the cutover as operator actions

Create an ordered runbook naming the action, operator, expected evidence and stop condition at each step. Include communication to staff, control of new writes, final data capture, import, reconciliation, application switching and observation. Rehearse the sequence in an isolated environment and revise it where someone needed an undocumented decision. The rehearsal duration describes that environment only; it should inform the plan without becoming a promise about an untested production move. Arrange access and an escalation route before the window, so an operator does not have to find the account owner during a blocked step.

A data migration cutover plan template

Use this sequence as a starting point for a system-specific runbook. Replace each role with a named operator and backup, add planned and actual times, and link the evidence produced by every step. Rehearse the completed runbook before setting the production window.

The CSV contains the same steps and checks shown below and opens in Excel, Google Sheets or another spreadsheet editor. Add named owners, backup contacts, planned and actual timestamps, dependencies and links to your own evidence. No signup is required; the file contains no macros or project data.

Download the cutover plan template (CSV)

Protect changes created after the switch

The moment users start writing to the new system, reversal needs more than a database copy. Identify the records created or changed since the cutover, their external effects and how they will be preserved if service returns to the old application. Where reverse transfer is not safe, define a controlled forward-recovery route and make that limit explicit before launch. Decide who can make the stop-or-continue call and which evidence they need. After a successful transition, keep the agreed recovery material protected and retire temporary access and duplicate jobs according to the runbook.

A rollback needs a write policy

A brief write freeze simplifies reconciliation but interrupts work. Parallel operation can reduce interruption while increasing synchronization and conflict-handling effort. Restoring the old application is not a valid rollback if users have already made changes only in the new database. Define a point of no return, reverse synchronization where feasible, or a controlled recovery path that preserves those changes.

Define rollback triggers before opening writes

Set measurable stop conditions for the actual service: unexplained reconciliation differences, a failed critical workflow, an unavailable dependency or a cutover step exceeding the agreed window. Record who decides, how operators are contacted and what recovery evidence is required. Choose thresholds from business requirements and rehearsal results rather than copying a generic outage allowance.

Before new writes begin, returning to the old system may be straightforward if its state remains intact. Afterward, preserve new records and external effects such as payments or notifications. Do not reopen the old system until the team has a tested reconciliation or reverse-transfer procedure. If reversal cannot preserve these changes, document forward recovery as the available response and obtain that decision before cutover.

Worked example: a payment arrives after cutover

Consider a fictional membership application. The new system has passed its opening checks and accepts a renewal. The payment provider confirms the charge, but a delayed entitlement update leaves the member unable to access the service. The old database does not contain that renewal. Switching traffic back immediately would hide the new transaction without undoing its external payment.

First stop the affected workflow under the agreed incident procedure and capture the renewal identifier, provider reference, event position and observed entitlement. Check whether the problem is confined to entitlement processing or also affects the transferred data. Do not charge the member again to recreate a missing database record.

If the tested recovery procedure can transfer the renewal and preserve its external reference, the release owner can assess reversal against the agreed checks. If it cannot, keep the evidence and use the prepared forward-recovery procedure. In either case, reconcile the payment and entitlement before reopening the workflow. A backup of the old database is evidence of its previous state, not proof that later transactions are safe.

Prepare the cutover sheet

Ask Orvun Labs to review the migration alongside the replacement software. Keep a timed sequence, named owners and objective stop conditions accessible to the operators. Do not rely on the same person improvising both the migration and its recovery.

• Which checks must pass before opening writes?
• How are late changes and failed imports reconciled?
• Who can pause the launch, and on what evidence?
• How will new-system changes survive a reversal?