Moving a workload between cloud providers without a rewrite

Migrations rarely fail on the compute. Servers are servers, and moving a container from one provider to another is a well understood problem. They fail on the things nobody put on the list: the managed queue with no equivalent, the secret hard coded in an old deployment script, the DNS record with a 24 hour time to live, and an egress bill nobody forecast.

This is the order of work that avoids most of that.

1. Inventory what you actually have

Not what the architecture diagram says. What is running.

• Every compute resource, with its size and its actual utilisation.
• Every managed service, with the specific features you depend on.
• Every data store, with its size and its growth rate.
• Every scheduled job, including the ones on a machine somebody set up two years ago.
• Every external integration, in both directions.
• Every DNS record, certificate and their renewal mechanisms.
• Every credential and where it is stored.

The last three are where migrations quietly break. A webhook pointed at a static IP address, a certificate renewed by a cron job on a server you are about to delete, a database password only present in an environment variable on a running instance.

2. Find the managed services with no equivalent

This determines the size of the project. Sort your dependencies into three groups:

Portable. Virtual machines, containers, object storage behind an S3 compatible API, PostgreSQL, MySQL, Redis compatible caches. These exist everywhere and move with configuration changes rather than code changes.

Replaceable with effort. Managed Kubernetes, load balancers, DNS, CDN, monitoring. Every provider has these; they differ in configuration, and moving means rewriting infrastructure code but not application code.

Genuinely proprietary. Serverless functions with provider specific triggers, managed data warehouses, provider specific queues and event buses, identity services, machine learning platforms. These require either an application change or a decision to leave them where they are.

A hybrid outcome is legitimate. Plenty of teams run compute at a cheap provider and keep one proprietary service where it is, connected over the internet. That is a design choice, not a failure.

3. Set up the destination properly

Resist the temptation to click through it. Build the target with infrastructure as code from the start, even if the source environment was built by hand. You are going to build this environment more than once during testing, and the second build should be free.

Then do the account setup work before anything else: identity, multi factor authentication, budget alerts, and a check on quotas in the destination region. New accounts start with conservative limits, and finding that out during cutover is avoidable. The checklist is in securing a cloud account.

4. Move the data first, and keep it moving

Data is the slow part and the risky part.

• Object storage. Sync in bulk, then run incremental syncs until cutover. S3 compatible APIs make this straightforward between most providers.
• Databases. Set up replication from the source to the destination rather than doing a dump and restore at cutover. A replica that has been in sync for a week reduces the cutover to a promotion.
• File systems. Incremental sync tools, run repeatedly, with a final pass during the window.

Verify by comparison rather than by assumption. Row counts, checksums, object counts. A migration that silently loses five percent of a table is worse than one that fails loudly.

5. Run both, then shift traffic

The safe cutover sequence:

1. Lower DNS time to live values to a few minutes, at least 48 hours in advance.
2. Deploy the application to the destination and test it against the replicated data.
3. Move a small share of traffic, either by weighted DNS or at the load balancer.
4. Watch error rates and latency for long enough to see a pattern, not just a moment.
5. Increase the share gradually.
6. Once traffic is fully shifted and stable, promote the destination database to primary and stop writing to the source.
7. Keep the source environment running, and paid for, for at least a week.

That last point is the one people skip to save money, and it is the one that saves the project when something surfaces on day three.

6. Decommission deliberately

Take a final backup and store it somewhere unrelated to either environment. Then remove resources in an order that leaves you able to reverse: application servers first, load balancers next, data stores last. Cancel commitments and reservations that no longer apply, and check for the orphans that always remain, unattached volumes, idle addresses, forgotten snapshots.

Making the next move easier

If portability matters to you, the choices are known and none of them are exotic: containers over provider specific runtimes, PostgreSQL over proprietary databases, S3 compatible object storage, infrastructure as code for everything, and configuration in the environment rather than in the platform.

That does not mean avoiding managed services. It means knowing which ones you are choosing to depend on, and what it would cost to leave. The comparison articles are useful here: Hetzner vs DigitalOcean and AWS vs Google Cloud both discuss where the lock in actually lives.