A staged plan for moving to another cloud provider

Moving a workload between cloud providers is treated as a large, risky project, and attempted as a single cutover it certainly is. Staged properly, most of the risk is retired early and the final step is small.

The organising principle is to move the things that are easy to reverse first, and to leave the data until you have proven everything else.

Stage zero: decide whether to

Migrations consume months and produce no new features. Before committing, be clear about what you are buying.

Good reasons: costs that are materially and durably lower, a capability you need that is genuinely absent, a regulatory or sovereignty requirement, a strategic need to reduce dependence on one supplier, or persistent capacity or service problems.

Weaker reasons: a general sense that another provider is better, a single frustrating support experience, or a headline price comparison that has not accounted for data transfer and managed service equivalents.

Cost the migration honestly, including engineering time, the period of running both environments in parallel, and the egress charges for moving your data out, which are frequently substantial and always underestimated.

Stage one: inventory and dependency map

You cannot move what you have not enumerated. List every resource, every managed service, every scheduled job, every integration, and every credential.

Then classify each one:

• Portable. Standard software running on virtual machines, container images, object storage with a compatible interface. Moves with configuration changes.
• Equivalent available. A managed database, a load balancer, a DNS service. Moves with configuration changes plus a data migration.
• Proprietary. A specific serverless event ecosystem, a proprietary data warehouse, a managed service with no counterpart. Requires rebuilding or replacing.

The proprietary list determines the size of the project. If it is short, this is a configuration exercise. If it is long, it is a re-architecture, and it should be scoped and approved as one.

Stage two: build the target environment

Define the new environment in code from the start. This is the point where infrastructure as code repays itself completely, because you will build the environment several times before you finish.

Recreate networking, security rules, identity and the compute layer. Do not migrate anything real yet. The goal is an empty but complete environment you can create and destroy repeatedly.

Stage three: move what nobody notices

Start with workloads whose failure is invisible to customers, in this order:

Development and test environments. Everything is exercised, nothing is at risk, and the team learns the new platform while the stakes are low.

CI and build infrastructure. Self-contained, easy to run in parallel, and a genuine test of the new environment’s capability.

Batch and background processing. Can often run in either place, and can be moved back easily.

Internal tools. Real users, forgiving ones.

By the end of this stage the team knows the platform, the tooling is proven, and a large share of the surprises have been found.

Stage four: replicate the data

Data is the part that cannot be rushed. Set up continuous replication from the old environment to the new, and let it run until the lag is small and stable.

Verify the replica properly: row counts, checksums where feasible, and application-level sanity checks. Then run your test suite against the replica and, if you can, run a read-only copy of the application against it.

This stage should run for days or weeks, not hours. It is also entirely reversible, since nothing has moved.

Stage five: move read traffic

If the application can be split, serve reads from the new environment while writes continue against the old. This exercises the new environment under real load with a limited failure mode: if something is wrong, route reads back.

Not every application can do this. Where it can, it is the most valuable de-risking step available.

Stage six: cut over

By now the environment is proven, the data is replicated, and the team is familiar. The remaining work is genuinely small.

Lower DNS TTLs well in advance. Choose a low-traffic window. Stop writes to the old environment, allow replication to drain fully, promote the new database to primary, switch DNS, and verify.

Have a rollback decision written down beforehand, including who makes it and by what deadline, because in the moment nobody wants to be the person who calls it.

Stage seven: run in parallel, then decommission

Keep the old environment intact for a defined period. Two to four weeks is typical, long enough that any monthly process has run once on the new platform.

Then decommission deliberately: take a final backup, document what existed, and remove resources in a considered order. Leaving an old environment running indefinitely because nobody wants to be responsible for deleting it is a common and expensive ending.

What people get wrong

Attempting it as one event. The single largest cause of failure.

Underestimating egress. Moving many terabytes out of a cloud is billed, and it can be a genuinely large number. Model it before committing.

Forgetting the peripheral things. DNS, certificates, monitoring, alerting destinations, log retention, backup schedules, IP allowlists held by partners, and webhook URLs registered with third parties. Each is small; collectively they are where the last two weeks go.

Not deciding the rollback criteria in advance. Without them, a struggling cutover continues too long because reversing feels like failure.

If you are weighing providers rather than techniques, our cloud account catalogue lists what each one is strongest at, alongside the configurations available.

For the vendor’s own reference on the services involved here, see the OVHcloud documentation.

If you would rather test this than read about it, our OVHcloud accounts come in four configurations across a wide product range, and the cloud account catalogue lists every provider we carry.

Questions people ask