Cloud exit plan: contract, migration, and the exit test
While everything is working, nobody calculates the cost of leaving. That is exactly why it needs to be calculated before it becomes urgent.
When a company moves to the cloud, the conversation almost always centres on the entry. Cost, speed to launch, scaling flexibility, reduced operational overhead. These are legitimate arguments and often correct ones.
The conversation about exit almost never happens at the same time. Not because it is deliberately avoided - exit just feels like a hypothetical scenario that does not need planning while everything is working well. But thinking about vendor lock-in before entering the cloud changes the negotiating position from the start.
That is a mistake. The cost of exit needs to be calculated at the moment of entry, when there are still negotiating positions, architectural clarity, and time.
What makes up the cost of exit
The cost of leaving a cloud provider is not only money. It consists of several components, each of which needs to be assessed separately.
Technical lock-in debt. How much does the code and architecture depend on the specifics of this provider? If the system uses proprietary message queues, databases, serverless functions, or management-specific APIs - each of those elements will need to be replaced or rewritten during migration.
Data transfer costs. Most cloud providers charge for outbound traffic. At small volumes this is invisible. At terabytes of historical data it can be a significant line item. Before migrating a large database, calculate what exporting it will actually cost.
Operational dependency. If a team has worked with a specific provider's tooling for three years - monitoring, logging, deployment - moving to a different platform means retraining, reconfiguration, and an inevitable period of instability.
Contract terms. Are there minimum consumption commitments? How is pricing structured when load decreases? What happens to data thirty days after the contract ends?
Where architectural decisions create or remove lock-in
Most decisions that create tight lock-in are not made as strategic choices. They are made because they are convenient.
Using a proprietary queue instead of Kafka is more convenient - nothing to deploy and maintain. Using a managed NoSQL instead of PostgreSQL is more convenient - less operational burden. These are reasonable decisions individually. In aggregate they create a system that is very expensive to move.
A few practices that reduce lock-in without sacrificing convenience:
- Abstract over cloud services at the application level. If code works with a queue interface rather than a provider-specific SDK, swapping the implementation takes days rather than months.
- Store data in open formats. Data in Parquet, CSV, or standard SQL schemas migrates incomparably more easily than data in proprietary formats.
- Infrastructure as code not tied to a specific provider. Configuration that needs to be rewritten from scratch when changing platforms is hidden debt.
How to run an exit test
An exit test is not a full migration simulation. It is a structured assessment that takes a few days and gives an honest answer to the question: "what would this cost us?"
The process is straightforward:
- List all cloud services currently in use - divided into "standard" (equivalents exist at other providers) and "proprietary" (specific to this provider).
- For each proprietary service, estimate the effort required to replace or rewrite it.
- Estimate data volumes and the cost of transferring them on export.
- Review the contract terms - penalties, minimum commitments, notice periods.
- Record the result as "current exit cost" and schedule a review in one year.
The exercise itself usually affects subsequent architectural decisions. When a developer knows that "using proprietary X adds three months of work on exit" - the choice between a standard and a convenient solution becomes more conscious.
Why this needs to be done now, not later
The reason is not that exit is inevitable. Many companies work with a single cloud provider for years and are satisfied.
The reason is that the decision to exit is usually made under pressure - contract terms change, service outages occur, prices shift, strategic considerations arise. At that moment there is no time for calm assessment and gradual migration.
A company that knows the cost of its exit and has even a rough plan is in a fundamentally different negotiating position than one for which exit is a catastrophe of unknown scale.