Migrating between clouds means paying egress to move data out of the source, refactoring workloads to fit the target platform's native services, and absorbing the stranded value of any Savings Plans, Reservations, Committed Use Discounts, or enterprise agreement commitments you still owe on the cloud you are leaving. Because those one time and sunk costs are large, a cloud to cloud migration pays only when the steady state run rate gap is wide or there is a strategic driver such as consolidation, a licensing advantage, or resilience that justifies it.
Here is what egress really costs when you leave, why refactoring for the target is the hidden labour, how stranded commitments change the math, and a worked example of when the move pays.
What does it cost to move the data out?
Leaving a cloud means egress, the per gigabyte charge to send data out, and for a large estate that bill can be substantial. There is an important recent shift: in response to regulation, AWS, Microsoft, and Google now waive egress fees when a customer fully exits their platform, so a complete departure can avoid the charge if you follow the provider's process. A partial migration, moving some workloads while keeping others, still incurs standard egress on the data you move, and OCI prices egress materially lower than the hyperscalers either way. Beyond the charge itself, moving large datasets takes real time and coordination, and the transfer window is part of the cost because it usually means a period of dual running across both clouds.
Why is refactoring the hidden labour?
A workload built around one cloud's native services rarely lifts cleanly onto another. Managed databases, identity, networking, queuing, and especially the AI and data platforms differ enough that a real move means rebuilding the integration, not copying a virtual machine. The more a workload uses the source cloud's managed services, the more refactoring it takes to land on the target, which is the same lift and shift against rearchitecting tradeoff as a first migration but with less upside, because you already paid to build it once. This is why portable, container based, and open standard workloads move far more cheaply than ones deeply wired into a specific provider, and why avoiding lock in has a real option value when a move becomes attractive.
How do stranded commitments change the math?
Commitments are the cost buyers most often forget when they model a move. A Savings Plan, a set of Reservations, Committed Use Discounts, or an enterprise agreement such as an EDP or a MACC are obligations you owe regardless of whether the workload still runs there. Move the workload off early and you keep paying for capacity you no longer use, or owe the shortfall on an unmet enterprise commitment.
| Commitment on the cloud you leave | What happens when you move early | Buyer implication |
|---|---|---|
| Savings Plans and Reserved Instances (AWS) | Continue billing for the term; limited resale or exchange | Time the move to the term, or absorb stranded cost |
| Reservations and Azure Savings Plan | Some exchange flexibility; term still owed | Check exchange options before moving |
| Committed Use Discounts (GCP) | Use it or lose it for the committed term | Run out the commitment or strand it |
| EDP or MACC enterprise commitments | Shortfall on unmet spend is still owed | Model the shortfall as a real exit cost |
The practical answer is to align a cloud to cloud move with the expiry of major commitments wherever possible, and where it cannot wait, to count the stranded commitment as a one time exit cost in the business case rather than discovering it after the decision.
A worked example
A software company considered moving a workload to a second cloud for a lower run rate. The run rate was indeed lower, but the full picture changed the decision: the workload leaned heavily on the source cloud's managed data services, so refactoring was substantial, and an enterprise commitment with two years left meant a real shortfall if usage left early. Modelling egress, refactoring labour, and the stranded commitment showed the move would not pay back inside the commitment term. Waiting to align the move with the commitment expiry, and refactoring toward portable services in the meantime, turned a losing move into a sound one. Figures are verified against billing data and anonymised; commitment terms are indicative.
Frequently asked questions
Does it cost money to move between clouds?
Why are stranded commitments a problem when changing clouds?
When does migrating between clouds actually pay?
Model the move before you commit to it
We model cloud to cloud moves on the full picture, egress, refactoring, and stranded commitments, so the decision rests on economics rather than optimism, as an independent advisory that takes zero provider commissions and answers only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis. Download the cloud cost optimization playbook, read the cross cloud cost optimization guide, and on leaving costs see egress costs of leaving a cloud. For monthly buyer side analysis, subscribe to The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.