Moving from one cloud to another gets discussed as though it were the same exercise as migrating from a data centre, and it is not. The workloads are already containerised or virtualised, already defined in code, already operated by people who understand cloud. What makes it hard is different: the managed services you have built on do not have identical equivalents, the identity model is not portable, and the data has to physically move at a price the other provider sets and you do not.
Egress is the item to model first, before anything else, because it can decide the whole question. Every gigabyte leaving your current provider is charged, and for an estate with substantial storage the total can be a large fraction of the annual saving the move was supposed to produce. Get the actual number for your actual volume, including backups and snapshots you may not have counted, and check whether the destination provider offers migration credits — several do, and they are negotiable.
Then be honest about which of your dependencies are genuinely portable. Compute, object storage, managed relational databases, queues and load balancers all have close equivalents everywhere, and moving them is work rather than redesign. What does not port cleanly is anything built on a provider-specific managed service, a proprietary database, a serverless event model, or an identity and permissions structure that has grown organically over years. Inventory those separately, because they are the project.
Do not attempt a big-bang cutover. Move one workload at a time, starting with something stateless and non-critical that exercises the whole path — build, deploy, network, monitoring, on-call — so the team learns the destination on something forgiving. Expect a period of running across both providers, which means cross-cloud networking, duplicated monitoring and a bill from each. Budget for that overlap explicitly; it is the phase that always lasts longer than planned because one dependency refuses to move.
Data is where the risk concentrates. Databases move with replication and a cutover window, and the rehearsal matters more than the plan: restore into the destination, run the application against it, measure how long a real switch takes with real volume. Object storage moves with a bulk transfer followed by a delta sync, and the delta is the part people underestimate on a system still taking writes.
The question worth answering before committing is why. Cost is the usual reason and is often addressable without moving, since most cloud overspend is idle resources, oversized instances and data transfer patterns rather than the provider's rates — and rightsizing where you are is dramatically cheaper than migrating. A genuine reason looks like a regulatory requirement, a customer mandate, a commercial relationship that changes the price materially, or a capability the current provider does not offer. If the reason is a feeling that the bill is too high, measure first; the answer is usually inside your own account.
