Dependence on a cloud provider is not decided the day you want to leave: it is decided the day you sign, and in every architectural decision afterwards. Thinking about the exit from the start is not distrust, it is the only way to keep negotiating power.
What follows: what actually makes leaving expensive, what is worth negotiating, what requires judgement, and how the option is kept open.
Almost no organisation changes cloud provider. That leads to the conclusion that the exit clause is a formality, and it is precisely that conclusion which makes it expensive.
The value of being able to leave is not in exercising it: it is in the possibility existing when renewal arrives, because a negotiation without a credible alternative is not a negotiation.
What actually makes leaving expensive
The first factor is the volume of data and the cost of extracting it. Moving information out is usually priced differently from moving it in, and at petabyte scale that asymmetry stops being a detail.
The second, and the most decisive, is the provider’s own services. A virtual machine moves; a managed service with its own interface, its own data model and its own behaviour has to be rebuilt.
The third is the team’s knowledge. After three years operating on a platform the accumulated experience is real, and changing means going back down the curve, with the operational risk that implies.
What is worth negotiating before signing
Data extraction terms. What it costs to take the information out, in which formats and with what assistance. It is the clause most often omitted and the one that weighs most when it is needed.
An assisted transition period. A window after termination during which the service remains available while the move happens. Without it, leaving becomes a migration against the clock.
Reversibility of commitments. What happens to committed capacity if the business changes. A three-year volume discount is attractive, and it is also the mechanism that pins the organisation in place.
Ownership and location of the data. Who is responsible, where it resides and what happens to copies on termination. Better written down than assumed.
What requires judgement
Avoiding every provider-specific service as a precaution has a cost: you give up capabilities that deliver real value and end up operating the cloud as if it were a rented data centre, which is the most expensive way to use it.
The sensible decision is graduated. Use managed services where the benefit is clear and the substitute is known; keep what constitutes the core of the business on standard components.
And it is worth distinguishing acceptable dependence from critical dependence. Depending on the provider for an ancillary service is one decision; depending on it for the system the organisation lives from is another, and deserves an explicit conversation.
What changes with a multi-cloud approach
Operating across several providers is often proposed as the answer, and it only is one when it answers a real need. Multiplying platforms also multiplies the surface that has to be secured, monitored and sustained with trained people.
The version that tends to work is more modest: keep portability where it matters — open formats, containers, infrastructure described as code — without operating in two places at once.
That preserves the option to move without paying every month for a duplicated architecture that, in practice, is almost never exercised.
How the option is kept open
Document specific dependencies as they are adopted, not at the end. A living list of which provider-specific services are in use and what would replace them turns an anxious question into an inventory.
Keep infrastructure described as code. Rebuilding an environment from a versioned description is a bounded problem; rebuilding it from what the team remembers is not.
And review the position before each renewal, not after. Arriving at the table knowing what leaving would cost is what turns the conversation into a negotiation.
What has to exist first
An inventory of services in use with their degree of specificity, an estimate of data volume and its extraction cost, and clarity about which workloads are critical to the business.
With those, the decision about how much dependence to accept is taken with information. Without them it is taken by default, which in practice means accepting all of it.
A practical signal of how much dependence exists
There is a simple test that requires no study: ask the team to estimate, without preparation, how long it would take to stand up the most critical service with another provider.
If the answer comes in minutes with a reasoned range, the organisation knows its position. If the answer is that it would have to be studied, that is the answer: the dependence is not measured, and what is not measured cannot be negotiated.
The question is worth repeating once a year. The result changes on its own, because every architectural decision moves it one way or the other without anyone declaring it.
Should provider-specific services be avoided?
Not as a rule. Avoiding them all leads to operating the cloud as a rented data centre, which is the most expensive way to use it. Decide case by case on benefit and ease of substitution.
Does multi-cloud solve dependence?
Only if it answers a real need. Operating across two providers multiplies what has to be secured and sustained. Keeping portability where it matters usually buys more option for less cost.
Which clause is most often omitted?
Data extraction terms and the assisted transition period. They weigh most on the day they are needed and are discussed least at signing.
When is it worth reviewing the position?
Before each renewal. Arriving at the table knowing what leaving would cost is what separates a negotiation from an acceptance.
