Cloud migration without a big bang

Migrations fail in a recognisable way. Months of preparation lead to a cutover weekend, the weekend goes badly, and the rollback either does not exist or has never been tested. By Monday the team is firefighting a system it has run for two days against one it ran for five years.

Almost everything that makes this survivable comes down to one decision: move in slices that can each be reversed on their own.

Measure before you plan

Most migration plans are built from the architecture diagram, which describes the system somebody intended. Traffic data, cost attribution and dependency traces describe the one you have. The gap between them is usually where the migration goes wrong.

A week of measurement routinely changes the plan more than a month of design. It also finds the services nobody remembered, which is the single most common cause of a failed cutover.

Move the boring thing first

The instinct is to start with the service causing the most pain. Start with the least important one instead. The first move is not really about the service; it is about proving the pipeline, the monitoring, the DNS strategy and the rollback while the consequences of getting it wrong are small.

You will get something wrong on the first one. It is much better for that to happen on an internal tool than on checkout.

Do not rewrite while you migrate

Migration is a change of environment. Rewriting is a change of behaviour. Doing both at once means that when something breaks, you cannot tell which change caused it, and debugging that costs more than both projects saved.

Move it as it is, even where it is ugly. Improve it afterwards, when the variable has been isolated.

Make rollback real

An untested rollback is a hope. Before each slice moves, somebody should have actually performed the reversal in a lower environment and timed it. If reversing takes four hours, that is a fact the plan needs, not a detail to discover during an incident.

Expect the long tail

The last ten per cent takes a disproportionate share of the time: the scheduled job on someone’s forgotten instance, the hardcoded IP in a partner integration, the certificate nobody owns. Budget for it explicitly rather than treating it as overrun.

A migration that takes two quarters in reversible slices is a better outcome than one that takes one quarter and a weekend everybody remembers.