Executing a migration: replication, cutover and rollback

Why this matters

Planning decides what shape a workload takes. Execution decides whether the business notices.

Cutover is the part with the least room for improvisation. It happens in a fixed window, usually outside working hours, with a group of people waiting on each other, and the decisions that matter — go or no-go, roll back or press on — have to be made quickly by people who are tired. Everything that can be decided in advance should be.

The single most common execution failure is not a technical one. It is discovering during cutover that the rollback plan stopped being viable an hour ago and nobody noticed.

The lesson

Seeding data, then replicating changes, so the final delta is small

The general pattern for any online migration is the same regardless of tooling:

1. Seed. Take a full copy of the data to the target. This is the slow part, and it happens well before cutover while the source keeps serving.
2. Replicate. Continuously ship changes from source to target, so the target stays close behind.
3. Converge. By cutover time the delta is seconds or minutes of change, so the final synchronisation is short.
4. Cut over. Stop writes at the source, let the last changes drain, verify, and redirect.

What to watch during the replication phase:

• Replication lag. The measure of how far behind the target is, and therefore of how long the final drain will take. It must be stable or falling as cutover approaches. Lag that is growing means the target cannot keep up with the source's change rate, and cutting over on a growing lag produces an unbounded window.
• Error and retry counts, which indicate rows or objects failing to replicate and quietly producing a divergent copy.
• Schema changes at the source. Many replication tools handle data changes and not structural ones. Freeze schema changes during the replication window, and say so explicitly to the people who deploy.

For file and object data, the same shape applies with a different mechanism: a bulk copy, then repeated incremental passes, each one shorter than the last, until the final pass fits in the window. For very large sets, the bulk copy may be a physical transfer appliance with incremental catch-up over the network afterwards.

Where downtime is genuinely unacceptable, the fallback is a dual-write or strangler approach — the application writes to both, or traffic is moved feature by feature. Both are significantly more work and belong to a refactor rather than a migration.

The cutover window, its go/no-go criteria, and who is allowed to call it

A cutover window is a plan, not a period of time. It should exist in writing before the night and should contain:

• A timeline with each step, its owner, and how long it is expected to take.
• A point of no return, explicitly marked. Before it, abandoning is cheap. After it, you are going forward. Knowing where that line is, and announcing when it is crossed, is the most valuable single element.
• Go/no-go criteria, agreed in advance.
• A named decision maker. One person decides go, no-go and roll back. Committees do not make this decision well at three in the morning.
• A communication plan — who is told what, and when, including the people who will notice the service is down.

Go/no-go criteria should be objective and checked before starting:

• Replication lag below an agreed threshold and stable.
• Target environment validated — the smoke tests already pass against it.
• Backups of the source taken and verified restorable, not merely taken.
• Rollback path confirmed available.
• The right people present, including someone who can authorise a decision on behalf of the business.
• No conflicting change in progress elsewhere.

If a criterion fails, do not start. A migration postponed by a week costs much less than one abandoned halfway. The exam likes scenarios where the correct answer is to defer.

DNS and TTL preparation, because a 24-hour TTL decides your rollback speed

DNS is the most common mechanism for redirecting traffic and the most common cause of a cutover that drags.

The time to live on a record tells resolvers how long they may cache it. If the TTL is 24 hours, a change can take up to 24 hours to be seen everywhere — and, critically, so can changing it back. A long TTL does not just slow the cutover; it slows the rollback, which is when speed actually matters.

The preparation is simple and must happen in advance:

1. Days before cutover, lower the TTL on the records you will change — to five minutes or less. This itself takes effect only after the old TTL has expired, which is why it cannot be done on the night.
2. Cut over, changing the record.
3. Watch the traffic drain from the old endpoint. It will taper rather than stop.
4. Raise the TTL again once you are confident, to reduce query volume and cost.

Two cautions the exam rewards:

• Clients and applications cache beyond the TTL. Some runtimes cache DNS for the life of the process, and some appliances ignore TTLs. Expect a tail of traffic to the old endpoint, and keep the old endpoint able to serve — or able to redirect — rather than turning it off at the moment of cutover.
• A load balancer or proxy in front of both avoids the problem entirely for the clients that reach it, which is why traffic-level cutover is preferable to DNS-level cutover where it is available.

Validation after cutover: function, performance and data integrity, in that order

Validation is a checklist written in advance, not exploration on the night. Run it in a deliberate order, because each layer depends on the one before.

1. Function. Does it work? Log in, run the core transactions, exercise the integrations, confirm scheduled jobs are enabled and pointed correctly. Include the paths that are easy to forget: outbound email, file exports, third-party callbacks, and anything with an IP allow-list at the far end.
2. Performance. Is it acceptable? Compare against the baseline from objective 2.1 — that is what the baseline was for. Watch the latency of the chatty paths specifically, because that is where a migration degrades first.
3. Data integrity. Is it all there and correct? Row counts, checksums on critical tables, spot checks of recent records, and confirmation that the last transactions before the freeze are present. Automate this; counting by hand at four in the morning is how errors are missed.

Then monitor for longer than feels necessary. Problems that survive validation tend to appear on a cycle: the nightly batch, the weekly report, the month-end close. Keep the migration team engaged through at least one full business cycle, and keep the source recoverable until it has passed.

A rollback plan that stays viable, and the point after which it stops being

A rollback plan is only real if it is still possible at the moment you need it. What erodes it:

• Writes at the target. The moment users transact against the new system, going back means losing that data or migrating it backwards. This is usually the true point of no return — not a technical step, but the first customer transaction.
• Irreversible schema or data changes made as part of the move.
• The source being decommissioned, reconfigured, or its licences released.
• DNS TTLs that make reverting slow, per above.

So the plan must state, in writing:

• What "roll back" means at each stage. Before writes, it is repointing DNS. After writes, it is a data reconciliation, and it is a different and much more expensive operation.
• How long each rollback takes, because a rollback that takes longer than the remaining window is not an option.
• Who decides, and against what trigger. Agree the trigger in advance — "if function validation is not passing by 04:00, we roll back" — because a team that is nearly finished will always argue for pressing on.
• What is preserved: the source stays intact and untouched until formally released, which should be days or weeks after cutover, not hours.

The disciplined version is to keep the source recoverable and idle for an agreed period, then decommission it properly through the process in objective 3.1. It costs a little to keep it; it costs enormously not to have it.

What to take into the exam

• Online migration = seed, replicate, converge, cut over. Replication lag must be stable or falling before you start.
• Freeze schema changes during replication; many tools replicate data and not structure.
• Lower DNS TTL days in advance. A long TTL slows the rollback, which is when speed matters. Expect a tail of traffic that ignores TTL.
• Validate in order: function, performance, data integrity — with performance compared against the pre-migration baseline.
• The real point of no return is usually the first write at the target, not a technical step.
• Agree the rollback trigger and decision maker in advance, and keep the source recoverable for a full business cycle.