Why this matters
A cutover is the hour when the old system stops taking traffic and the new one starts. The plan for that hour is a timed list of commands, checks and decisions, each with a name beside it. The rollback plan is the other half of the same document: what you do, in what order, when a check fails.
Writing it down surfaces the problems early. You find the integration nobody owns, the job that runs at 02:00 and would write to both systems, the DNS record with a 24 hour TTL. Those are cheap to fix in a document and expensive to fix at cutover.
The plan also names the point of no return. Some migrations can be reversed for hours at little cost. Others become irreversible the moment the first write lands in the new store, because the old system has no path to receive it back. Decide which one you have, and write down what makes it so.
Before you start
Inventory everything that reads from or writes to the source. Application servers, cron jobs, ETL pipelines, finance spreadsheets, SFTP feeds, API clients, mobile apps with cached endpoints. For each one, note the owner and how it gets pointed at the new system. Anything you cannot point somewhere is a blocker.
Negotiate the freeze window in writing. During the freeze there are no schema changes, no deployments, no configuration edits and no data fixes in the source. Get sign off from the people who normally do those things, because they are the ones who will break it under pressure.
Decide how deep the rollback goes. Reverting traffic takes minutes but loses writes made in the new system. Reverting data needs a documented reverse path or a restore. Rebuilding from backup takes hours. Pick a depth per system, write down the data loss you accept, and name one person who can call the rollback, plus a deputy.
How to do it
How to write a migration cutover and rollback plan comes down to one document with three parts: the cutover runbook, the rollback runbook and the communication plan. Store it in the repository you deploy from and version it. A plan in a wiki page tends to be edited by nobody and read by nobody.
Format the runbook as a table: clock time, step, owner, the exact command or console path, expected result, the check that proves it, and the branch to take if the check fails. Estimate each step and set a hard stop for the window. If you reach the hard stop unfinished, you roll back.
Write verification queries as literal text someone can paste: row counts, a checksum on key columns, a known record lookup, one synthetic transaction. Rehearse the whole runbook against a refreshed copy of production at production data volume, and use the rehearsal timings for the schedule.
- Inventory every consumer of the source system. List every app, job, feed, report and spreadsheet that reads from or writes to the source. Note the owner and the switch method for each. Anything without a switch method is a blocker to resolve before you schedule the window.
- Set the freeze window and hard stop. Agree the freeze start and end with the business owners and put both in writing. Set a hard stop inside the window that leaves room for a rollback attempt. Past the hard stop the decision is automatic.
- Write the timed runbook. Put each step in a table with clock time, owner, exact command, expected result and the check that proves it. Keep platform detail, including console paths and setting names, inside the step itself. Anyone on the team should be able to run it without asking questions.
- Define rollback triggers with numbers. Write the specific conditions that force a rollback: a missed replication lag threshold by a set time, a failed validation count, an error on the synthetic transaction. Attach each trigger to a person who watches for it. Vague unease is not a trigger.
- Write and time the rollback runbook. Mirror the cutover table: traffic switch back, data reversal or restore, configuration revert, verification. Time it against production sized data. If it takes longer than the outage it prevents, the plan is not finished.
- Rehearse both runbooks on a production copy. Run the cutover and the rollback end to end on a refreshed copy at full volume. Record how long each step actually took and fix the places where two people needed the same console. Update the timings and the order.
- Prepare comms, access and the bridge. Book the bridge line, the scribe and the on call list for both systems. Confirm every account and secret works from the environment you will use. Draft the start, hold, rollback and success messages before the window opens.
- Run the cutover with a scribe. Log actual times against planned times as you go. Announce the go or rollback decision at the hard stop, with the named authority making the call. Keep the source read only and monitored for the agreed period before decommissioning.
How to check it worked
Functional checks come first. Walk the five or six journeys that matter end to end in the new system and have a named person sign off each one. A screenshot of checkout succeeding saves an argument later.
Then reconcile data. Compare row counts per table as of the freeze, checksum the columns that matter, and sample records field by field from both sides. Look at the newest record timestamp: it proves replication caught up rather than stopping quietly partway.
Check the operational layer last: dashboards, alert rules, log shipping, backups. A system that works but is invisible, with alerts still pointed at hosts that no longer serve traffic, is the common post cutover failure. Finish with a business check, such as batch totals or the invoice run, that ops or finance recognizes.
Mistakes to avoid
Rolling back without written triggers. Set the numbers in advance: if replication has not caught up by 23:40, or if more than a set count of records fails validation, roll back. Without them, a tired team argues and the window burns.
Testing rollback on an empty database, or forgetting the boring parts. Lower DNS TTLs a day ahead, install certificates in advance, create service accounts and secrets in the new environment, open firewall rules, move licenses. Each is a five minute task that costs an hour when it appears at the wrong moment.
Decommissioning the source in the same week. Keep it read only and monitored for an agreed period, then take a final backup. If the target design or the sequencing is still open when you sit down to write, settle it first. The Cloudverg Discovery and roadmap sprint is a two week fixed price engagement at $9,500 that ends with an architecture, a phased roadmap and a fixed price for phase one, and the fee is credited to phase one. It is one option among others.
Frequently asked questions
What is a rollback trigger in a migration cutover plan?
It is a pre agreed condition with a number and a deadline that forces the team to roll back, such as replication lag above a set threshold at a set time. Triggers take the debate away from a tired team at 03:00. Each one needs an owner who watches for it and the authority to call it.
How long should a cutover window be?
Long enough to run every step at rehearsal speed plus room for one rollback attempt. Base it on measured rehearsal timings, not estimates. Add a hard stop well before the business needs the system, because a window that ends as staff arrive has no slack.
Can you test a rollback without touching production data?
Yes, by rehearsing against a refreshed copy of production at full volume in an isolated environment. Restore a recent backup, run the cutover, then run the rollback and time both. The copy will not catch everything, such as DNS propagation, but it catches most sequencing errors.