This article is part of our Cloud Contract Negotiation Guide — the complete resource for enterprise cloud contract strategy. For the full cluster including Azure, GCP, and egress negotiation, start there.
Why Cloud Exit Is Harder Than It Looks
Exiting a cloud provider looks straightforward on a napkin: stop consuming services, migrate workloads to an alternative platform or on-premises environment, and shut down your account. In practice, cloud exit is among the most commercially painful and technically complex undertakings in enterprise IT. The reasons are both structural and deliberate.
First, cloud providers engineer exit friction into their commercial and technical architectures. Committed spending terms — AWS Enterprise Discount Programmes, Azure MACC agreements, Google Cloud commitments — are financial obligations, not service subscriptions. If you commit to spend $20M over three years and exit after one year, you owe the full $20M regardless of actual consumption. This structural commitment asymmetry means that exit conversations are automatically high-stakes financial negotiations, not operational decisions.
Second, data egress costs are material. Cloud providers charge $0.02 to $0.05 per gigabyte for data leaving their network. For organisations moving 10–50TB of data, egress alone can cost $50,000 to $500,000+. These costs are non-negotiable in the standard pricing model — AWS, Azure, and Google Cloud all structure egress costs to make exit expensive.
Third, cloud architecture creates lock-in. Applications built on cloud-native services — managed databases, serverless functions, proprietary APIs — require substantial refactoring to run on-premises or on alternative clouds. Exit costs therefore include not just migration labour but often application re-architecture costs. Organisations that planned for lock-in find exits feasible but expensive. Those that didn't plan for it discover that "exit" means "rebuild."
From a negotiation perspective, this structural difficulty creates opportunity. Cloud providers want to prevent exits — both because exit represents lost revenue, and because successful exits by a customer represent a competitive threat to the vendor. This creates negotiating leverage for anyone credibly signalling exit intent. Understanding how to use exit threat as leverage — even if no real exit is planned — is the most valuable skill in cloud contract negotiation.
Understanding Your Exit Obligations
Before you can negotiate exit terms, you must understand exactly what your exit obligations are. Three categories of costs dominate: commitment obligations, data retrieval costs, and transition costs.
Committed Spend Obligations
If you have signed an AWS EDP, Azure MACC, or Google Cloud commitment, the commitment is a legally binding financial obligation. You do not own the cloud resources you have committed to — you own only the obligation to pay. This distinction is crucial. A commitment to spend $20M over three years means that AWS, Azure, or Google Cloud will bill you $20M regardless of actual service consumption. If you exit the relationship after 12 months, you owe approximately $6.7M (one-third of the commitment), plus any negotiated penalties.
The exact mechanics vary by vendor. AWS EDP contracts typically allow you to walk away from the commitment, but you owe the full committed amount due for the period. Azure MACC agreements have similar structures. Google Cloud commitments are more flexible in some cases but still binding. The key is to review your actual contract language — most organisations have only a rough understanding of their true commitment obligations.
Data Egress and Retrieval Costs
Extracting data from a cloud provider during exit incurs standard egress pricing. AWS charges $0.02 per GB for data exiting its US regions. For organisations with 1PB of data (not uncommon for data-intensive workloads), egress costs alone total $20,000+. For 10PB of data, costs reach $200,000+. These costs are applied to data extracted during the exit window, regardless of whether the data migrated successfully or not.
Cloud providers offer no standard waivers for egress during exit — it is treated as a commercial data transfer like any other. However, egress waivers and migration credits are highly negotiable for enterprise customers, particularly if positioned as part of a multi-year renegotiation. The negotiating leverage comes from the alternative: if egress cannot be waived, the organisation may choose not to retrieve all data, leaving it behind as technical debt or forfeiting the data entirely.
Transition Support and Labour Costs
Most exit scenarios involve internal and external labour — architects to design the target environment, engineers to migrate workloads, and potentially external advisors to manage the process. For a typical enterprise exiting a major cloud provider, professional services costs range from $250,000 to $2M+ depending on complexity. These costs are entirely within your control, but they are real and should be factored into exit economics.
The Three Types of Cloud Exit: Full, Partial, and Re-Platform
Not all cloud exits are the same. Understanding which type of exit you are contemplating affects your negotiating strategy.
A full exit means migrating all workloads from the incumbent provider to a fundamentally different computing model — typically on-premises. Full exits are relatively rare and typically occur when an organisation has decided that cloud economics no longer make sense for their workload profile. The 37signals/Basecamp repatriation is a well-known example, where the organisation moved most infrastructure back to owned data centres and reported saving $3.2M annually on computing costs.
A partial exit means reducing scope — exiting certain workloads or business units while maintaining cloud presence for others. This is the most common exit scenario. An organisation might decide that development and testing workloads should move on-premises while keeping production cloud infrastructure. Or it might decide to consolidate onto a second cloud provider for certain workloads while maintaining the incumbent for others.
A re-platform exit means moving from one cloud provider to another — AWS to Azure, for example, or any combination of the three major providers. Re-platforming is technically distinct from repatriation because it involves moving between cloud architectures rather than cloud to on-premises. However, from a negotiating perspective, the threat of re-platforming is often as credible and as leverage-generating as the threat of full exit.
Each exit type requires different contractual protections and different negotiating approaches. Full exits require committed-spend relief and aggressive egress waivers. Partial exits require flexibility on commitment scaling and the ability to reduce committed amounts mid-term. Re-platforms require commitment transfer provisions and compatibility with multi-cloud architectures. Understanding which exit type applies to your situation focuses your contractual negotiations on the right levers.
Using Exit Threat as Negotiating Leverage
Many organisations use threat of exit to negotiate better cloud pricing even though no real exit is planned. This is a legitimate negotiating tactic — provided the threat is credible. Cloud providers have sophisticated processes for assessing exit credibility. They distinguish between performative exit discussions (which they ignore) and genuine multi-cloud investment (which they price against aggressively).
Credibility requires demonstrable commitment. You cannot simply tell AWS that you are considering Azure — AWS assumes every customer considers alternatives. You must show evidence: architecture review and design on an alternative cloud, cost modelling on competitive platforms, technical proof-of-concept migration, and workloads actually running on an alternative provider. Organisations maintaining 20–30% of total cloud spend on a second provider report receiving 3–8 percentage points of additional discount from their incumbent in subsequent negotiations, relative to single-cloud peers at equivalent spend levels.
The threat window is important. Exit threats are most credible and most valuable 18–24 months before a major contract renewal. This timeline allows you to demonstrate genuine technical progress on an alternative while approaching the vendor's renewal discussions with leverage. Starting exit conversations too early (3+ years before renewal) signals negotiating theatre. Starting too late (within 3 months of renewal) is tactically weak.
Exit leverage timing: For a three-year AWS EDP expiring in March 2027, begin your competitive positioning and multi-cloud technical work in Q3 2025. By Q4 2025 / Q1 2026, present your renewal discussion to AWS with demonstrable competitive work — cost models, architectural reviews, maybe a pilot workload. AWS's pricing committees meet in November/December for calendar-year closures, giving you maximum leverage during this window.
Negotiating Migration Assistance and Credits from Incumbents
A counterintuitive but extremely valuable negotiating move is to ask your incumbent cloud provider for migration credits and support as a condition of staying. This requires some care, but it works. Incumbents offer migration credits and support to attract new customers from competitors. These same credits and support can be negotiated as retention tools to prevent departing customers.
AWS offers Migration Acceleration Program (MAP) credits to AWS customers moving from other providers to AWS. Azure offers similar programmes. Google Cloud offers migration credits for customers moving to GCP. These programmes are flexible and can be negotiated. If your incumbent provider (say, AWS) fears you might move to Azure, AWS can offer you internal migration credits — credits that effectively reduce your committed spend or provide free professional services for cloud optimisation projects.
The negotiating pitch is: "We are evaluating multi-cloud and considering moving significant workloads to Azure. To justify staying with AWS for our primary commitment, we would need migration support equivalent to what we'd receive if we were moving TO AWS from another provider." Most vendors can and will accommodate this, particularly for customers with meaningful spend and genuine competitive alternatives.
The Cloud Repatriation Trend: On-Premises Economics in 2026
Since 2023, a significant trend has emerged toward cloud repatriation — moving workloads from cloud back to on-premises infrastructure. The driver is economics. Andreessen Horowitz published analysis in 2023 showing that for organisations with stable, mature workloads at scale, on-premises infrastructure costs 2–3 times less than equivalent cloud compute when total cost of ownership is calculated properly.
This trend matters for exit negotiations because it creates new leverage. Cloud providers now understand that buyers have more realistic options for on-premises repatriation than existed even three years ago. This generates willingness to offer more aggressive pricing to prevent repatriation discussions from becoming real.
High-profile repatriations include 37signals/Basecamp ($3.2M annual savings), Apple's iCloud partial repatriation, and numerous financial services organisations moving from cloud back to owned infrastructure for stateful, batch workloads. Each repatriation signals to vendors that the repatriation option is real, not theoretical. From a negotiation perspective, this strengthens your exit threat even if you have no intention of repatriating — the mere fact that repatriation is economically possible creates vendor vulnerability.
Building an Exit Clause Into Your Next Cloud Contract
The most important moment to negotiate exit protection is before you sign a multi-year commitment. Six exit-related clauses should be in every enterprise cloud contract:
Data Portability Window: Negotiate a 90–180 day window after contract termination during which you can extract data at reduced or zero egress cost. This window prevents the situation where egress costs exceed exit savings.
Egress Waivers for Migration: Request waiver of egress charges for data transferred specifically for migration purposes during the exit window. This typically applies to a defined volume threshold (50TB or 500TB).
Transition Support Commitment: Lock in the vendor's obligation to provide 30–60 days of technical support during the exit process — assistance with data extraction, API documentation, troubleshooting. This should be documented contractually, not left as an informal commitment.
Early Termination Rights: Negotiate conditions under which you can exit early without full penalty — price increases beyond negotiated thresholds, service availability below negotiated SLAs, or material change in the vendor's product roadmap. These are rare but valuable.
No Commitment Acceleration: Standard clauses accelerate remaining committed amounts if you terminate early. Push back against this. Your commitment obligation should be assessed based on time elapsed, not triggered instantly upon termination notice.
Competitive Pricing Match: Negotiate language that allows you to match a competitive offer from Azure or GCP if you receive lower pricing from either. This creates a negotiating lever throughout the term, not just at renewal.
Frequently Asked Questions
Can you exit a cloud provider before the committed term ends?
Yes, but typically with financial penalties. If you commit to a spend level over three years and exit early, you generally owe the full committed amount regardless of actual consumption. However, exit provisions — data retrieval assistance windows, egress waivers, early termination conditions, and transition support — are negotiable contractual elements. The key is to structure these exit protections before signing the commitment, not after.
How much does it cost to exit a cloud provider?
Exit costs typically include: (1) Commitment shortfall penalties — you owe any unmet committed spend, often $5M–$50M+ for large enterprises; (2) Data egress costs — typically $0.02–$0.05 per GB, which can total $50,000–$500,000+ for data-intensive workloads; (3) Migration labour and infrastructure costs — building the on-premises or alternative cloud environment; (4) Application refactoring costs — rewriting cloud-native code for on-premises or alternative platforms. The commitment penalty is typically the largest component. Using exit negotiation leverage — competitive bids, migration credits, egress waivers — can reduce these costs substantially.
Is using exit threat as leverage effective if you don't plan to actually leave?
Yes, but only if credible. Cloud providers can distinguish genuine multi-cloud investment from negotiating theatre. Credibility requires demonstrable technical investment in an alternative provider — proof of workload testing, architecture reviews, cost modelling on a second cloud platform. Organisations with 20–30% of total cloud spend genuinely deployed on a second provider can use competitive pressure effectively even without plans to migrate entirely. The key is making the alternative real enough to register on the vendor's risk assessment.
What exit provisions should we negotiate into a new cloud contract?
Critical exit clauses to negotiate: (1) Data portability window — 90–180 days after termination to retrieve data at reduced or zero egress cost; (2) Egress waivers — waiving data transfer charges for migration purposes; (3) Transition support — vendor commits 30–60 days of technical assistance during exit; (4) Early termination conditions — ability to exit early if pricing increases beyond negotiated thresholds, if service availability falls below negotiated SLAs, or in M&A scenarios; (5) No commitment acceleration — terminating the contract doesn't force immediate payment of remaining committed amounts; (6) Competitive price match — matching competitor pricing if you receive a lower offer from Azure or GCP. These clauses are negotiable and should be addressed before signing multi-year commitments.