Cloud to cloud migration

The work has five stages, shown in the diagram below. The first three are described here. First we build a dependency map from observed network traffic and API calls, because the architecture diagram is rarely current. Then we classify each workload as re-host, re-platform, re-architect, replace, retire or retain according to what it depends on, including the workloads that will cost more than the plan assumed. Then we move the estate in waves, each with a period of parallel running and a rollback that has been run before the cutover.

A plan that counts virtual machines moves the stateless workloads and then stalls on the ones that depend on identity, managed databases, key management, private circuits to partners, and partner allowlists tied to fixed addresses. We classify those first, because they set the order of the waves. The wave plan also states how audit logs and control evidence are kept continuous across the move, and what the recovery position of each service is while the estate is split between two providers.

A service and the datastore it writes to move in the same wave. Where that is not possible, we count the round trips between providers for each request and the egress they generate before the wave is drawn, and the wave plan states the response time it adds.

For a stateless service, DNS answers are divided by weight between a source record and a target record, so traffic follows the weights approximately, and it is returned by setting the target weight to zero. Cached answers and open connections drain over the record lifetime and the connection lifetime, and the rollback test measures that drain time.

For a stateful service the source stays the only writer while it replicates to the target. At cutover we 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, and only then move write authority to the target in one step. 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 engine differs from the source engine and no tested reverse mapping exists, the point of no return is the cutover itself, and the wave plan says so.

The wave plan comes with a cost model for the move itself. It covers the cost of running both estates in parallel for each wave, data egress, and any committed spend that remains on the source. It also gives the month, if there is one, in which total spend falls below what you pay today.

Migration into a sovereign or private cloud carries its own constraints: residency, audit, and the absence of several managed services you may have been depending on. Those gaps are listed in the assessment, each with the replacement we propose.

On a large estate we build the dependency map, the wave tooling and the rollback tests, and we run the first waves ourselves. Your engineers then run later waves to the same pattern while ours review each one. For a wave your engineers run, we are accountable for the wave plan, the tooling and the rollback test, one of our engineers is present for the cutover, and your engineers are accountable for following the runbook.