A migration plan that counts virtual machines moves quickly at first. The stateless services go across, the dashboard shows steady progress, and then the programme slows down on the services that hold data or depend on something the plan did not count.
Those services are usually the ones that depend on identity, managed databases, key management, private circuits to partners, and partner allowlists tied to fixed addresses. They are also the ones that set the order of the whole move, so they have to be planned first.
Build the dependency map from traffic
The architecture diagram is rarely current. The map that a migration needs is built from what the estate is observed to do: network flow logs, load balancer logs, DNS query logs, the provider's API audit log and distributed traces.
The observation has to cover a month end and the batch cycles, because some dependencies appear only then. Where the logs you already keep cover those periods, the history can be read. Where they do not, the plan should state which cycles were not observed.
Classify before drawing the waves
Each workload is classified as re-host, re-platform, re-architect, replace, retire or retain, according to what it depends on. The workloads that will cost more than the plan assumed are classified first, because they decide the order of the waves.
One rule saves a great deal of trouble: a service and the datastore it writes to move in the same wave. Where that is not possible, count the round trips between the two providers for each request, and the data egress they generate, before the wave is drawn. The wave plan should state the response time that the split adds.
Stateless services: a traffic change that can be undone
For a stateless service the move is a change to where traffic goes. DNS answers are divided by weight between a source record and a target record, so traffic follows the weights approximately. The service is returned by setting the target weight to zero.
The return is not instant. Cached answers and open connections drain over the record lifetime and the connection lifetime. A rollback test should measure that drain time, so that the figure in the runbook is one that has been observed.
Stateful services: a data operation with a point of no return
A stateful service is different, because once it has taken writes on the target, returning it to the source is a data operation and no longer a traffic change.
While the service replicates to the target, the source stays the only writer. At cutover the sequence is:
- Stop writes.
- Wait until the target has applied the source's final position.
- Recheck the chunks that changed since the last full parity run.
- Start the reverse stream from that position.
- Move write authority to the target in one step.
The order of the last two steps matters. If the target takes a write before the reverse stream is in place, that write is lost to any rollback.
Until sign-off, the service can be returned to the source by the same procedure in the other direction. At sign-off the reverse stream is removed, and from then the service can only be corrected forwards. Where the target database engine differs from the source engine and no tested reverse mapping exists, the point of no return is the cutover itself. The wave plan should say so in plain words, with the name of the person who signs it.
Count the cost of running two estates
A migration has its own cost, separate from the cost of either cloud. It includes the cost of running both estates in parallel for each wave, the data egress, and any committed spend that remains on the source.
A cost model for the move should give the month, if there is one, in which total spend falls below what you pay today. A plan without that month risks stopping halfway, with two estates to pay for.
What we would check first
If a migration has stalled part way, three questions usually show why:
- Which services write to a managed database, and which of those have a tested way back?
- Which dependencies were found only at a month end or in a batch cycle?
- What does each remaining wave cost in parallel running, and who has agreed to that cost?
Our cloud to cloud migration practice starts with an assessment of a named slice of the estate and produces the dependency map, the classification and the wave plan for that slice. The checks we use to show that a move is safe to continue are set out under how we verify a move.
