Moving Off a Cloud Provider Without Drama

What actually makes it difficult

The pattern: standard technologies move easily, proprietary ones do not. That is the practical meaning of lock-in, and it is a spectrum rather than a state.

Plan the exit

1. Inventory everything, including the services you forgot you enabled.
2. Classify each dependency by how hard it is to replace.
3. Price the destination properly — compute, storage, egress, managed services, support.
4. Estimate the data transfer volume and cost.
5. Decide what moves, what gets replaced with something else, and what gets retired.
6. Sequence it: least coupled first, data last.
7. Set a realistic timeline, then extend it.

Data transfer

For large datasets, egress is both a cost and a duration problem.

• Ask about egress waivers for a full migration — several providers now offer them following regulatory change in Europe.
• Compress before transferring; it reduces both cost and time.
• For very large volumes, physical transfer appliances exist and are sometimes faster than the network.
• Transfer incrementally over time rather than in one burst, spreading cost and reducing risk.
• Verify integrity with checksums on arrival, not just successful completion.
• Keep the source data until the destination is verified and running.

Replacing managed services

1. Managed database to managed database at the new provider, same engine, using replication.
2. Object storage to S3-compatible storage, using a sync tool that verifies as it goes.
3. Serverless functions to containers on a managed container platform, which usually simplifies as well as moves them.
4. Provider-specific messaging to a standard broker you run or a managed equivalent.
5. Identity integration to a standalone identity provider, which is usually the largest single piece of work.
6. Monitoring and logging to a provider-neutral stack, ideally before the move so you retain visibility throughout.

Moving observability first is a small effort that pays off, because you keep the ability to see what is happening during every subsequent step.

Decommission properly

The step that gets abandoned once the new environment works, and then bills for months:

• Keep the old environment running for an agreed period — typically two to four weeks after full cutover.
• Take a final backup of everything and store it independently.
• Delete resources in dependency order, so nothing fails unexpectedly.
• Check every region, not only the ones you used deliberately.
• Remove reserved addresses, snapshots and volumes, which persist after instances are gone.
• Cancel support plans and any commitments you can exit.
• Close the account formally once everything is verified, and export the audit log first if you need it for compliance.

Commitments — reserved instances and savings plans — generally continue billing after you stop using the resources. Check the remaining term before assuming the bill ends with the last instance.

Common questions

Where to go next

See multi-cloud and the account handover checklist.