Migrations that happen on a Tuesday

The migration plan we usually get shown has a recognisable shape: six months of preparation, a cutover window on a Saturday night, thirty people on a call, and an eighty-step checklist. That plan has one enormous single point of failure, and its rollback consists of doing everything backwards under pressure, with the data already changed.

We design migrations with the opposite property: each step is small, ships during working hours, and its rollback fits in one command. If it goes wrong at eleven on a Tuesday morning, the whole team is awake and available. That is the entire idea.

Inventory first, and it is always incomplete

The risk in a migration is not in what you know is there, it is in what gets discovered halfway. Before moving anything we spend time building an inventory that does not rely on documentation, because documentation describes the architecture somebody designed, not the one that runs.

• Real network flows over a full month, to capture what only happens at month-end close.
• DNS queries, which reveal integrations nobody remembered and third-party dependencies.
• Scheduled jobs, the classic omission, and usually what breaks in the first week after cutover.
• Hard-coded IP addresses in third-party configurations, firewalls and allowlists, which you cannot change unilaterally.
• Real data volume and growth, because the transfer plan depends on a number almost nobody measures beforehand.

From that inventory comes the only classification that matters at first: what moves as-is, what moves with minor changes, what gets replaced by a managed service, and what gets switched off. That last category is always larger than the organisation expects, and it is the most profitable part of the project.

Networking gets solved before anything else

Almost every migration gets stuck in the same place: during the transition, some systems live at the source and others at the destination, and they have to talk to each other as if nothing had changed. If that is not solved, the plan automatically degenerates into a single cutover, because no intermediate state is possible.

What has to be solved before the first workload moves: stable private connectivity between source and destination with enough bandwidth, address ranges that do not overlap, consistent name resolution in both directions, and federated identity so a migrated service can still authenticate against what has not moved yet.

Overlapping ranges cause the most delay and get discovered latest. They are fixed with address translation, but translation breaks everything that depends on source IP, including audit logs and third-party allowlists. Finding that out in week one costs a meeting; finding out in week fourteen costs the quarter.

Data: replicate, verify, and only then flip the switch

Data is the irreversible part, so that is where almost all the design effort goes. The pattern we use nearly always has four phases, and the key is that writes move much later than reads.

1. Initial load plus continuous replication from source to destination, letting replication lag settle to seconds.
2. Continuous verification: row counts and block checksums compared as a scheduled job, not as a one-off check right before cutover.
3. Shadow reads: a fraction of read traffic is served from the destination and compared against the source response, without the user ever seeing the destination result.
4. Write cutover, the only genuinely delicate moment, reduced to seconds if the previous three phases are clean.

On dual writes it is worth being honest: they are tempting and a source of subtle bugs. Writing to two systems without a distributed transaction means sometimes one succeeds and the other does not, and you need reconciliation anyway. When the business tolerates a few seconds of read-only, a short cutover with replication caught up is far simpler and far safer than weeks of dual writes.

# write cutover: timed, and rehearsed in pre-production
1. enable read-only mode in the application     (~2 s)
2. wait for replication lag = 0                 (~5 s)
3. verify checksums of the last block           (~10 s)
4. switch the write endpoint in configuration   (~3 s)
5. disable read-only mode                       (~2 s)
# rollback available until step 4: just revert step 1

Reverse replication is the insurance policy almost nobody sets up and which turns an irreversible cutover into a reversible one. If after the switch the destination replicates back to the source for a few days, going back remains possible without losing new writes. It costs a bit of work and removes the frightening part of the plan.

Move first, improve second

The eternal debate is whether to redesign while migrating. Our position is firm for a practical reason: if you change both the location and the design at once, when something breaks you will not know which change broke it, and diagnosis multiplies.

We move first with the minimum necessary changes, stabilise, and only then improve. With two reasonable exceptions: whatever cannot run at the destination without changing, and whatever is so cheap to replace with a managed service that keeping it would be more work than replacing it.

For large applications that cannot move in one piece we use the strangler pattern: a proxy in front of the old system, and route by route traffic gets diverted to the new one. Each migrated route is a small deploy with immediate rollback, and the old system is switched off the day its traffic share reaches zero, without ceremony.

Cutover: abort criteria, not courage

A cutover plan without abort criteria written in advance always ends in the same scene: it is two in the morning, something is wrong, everybody is tired, and the decision to continue or roll back is made by whoever sounds most confident.

Criteria are agreed beforehand, in the cold, and they are checkable: which error rate or latency forces a rollback, how long may be spent debugging before aborting, and who has authority to call it without consulting. One named person, not a committee.

It gets rehearsed too. A full dress rehearsal in pre-production with realistically sized data, timed, is what turns a list of steps into a reliable estimate. The rehearsal almost always reveals that one step takes four times longer than assumed, and it is much better to find that in the rehearsal.

After the cutover

A migration does not end when traffic moves. It ends when the old system is off and its bill is gone, and that last stretch is where most projects stall, paying for two estates for months because nobody dares flip the switch.

What we do to close it: a committed decommission date from day one, an observation period with the old system stopped but recoverable, and an explicit check that nothing writes to it any more. Plus a final backup archived with whatever retention compliance requires, so switching off does not depend on somebody feeling brave.

And a warning about cost: the first bill after migrating is almost always worse than promised, because lifted-and-shifted workloads reproduce the source sizing and because cross-zone traffic is billed. It gets tuned in the following weeks with real data, but it is better said in advance than discovered on the invoice.

If you have a migration stalled by fear of the cutover weekend, send us two lines about what moves your data today. You get an initial read and a ballpark quote within 24h.