Cloud Exit Plan
A documented, costed assessment of what leaving a provider or service would require — increasingly a regulatory expectation and a better lock-in control than portability itself.
Lock-in is usually discussed as something to avoid through abstraction, which is expensive and frequently ineffective. An exit plan reframes it as something to price and manage.
The plan states, per major service: what the data is and in what format, how it would be extracted and how long that takes, what the egress cost would be, what would have to be rewritten, what the equivalent elsewhere is, and how long the whole move would take. That produces a number, and a number can be compared against the benefit of using the service.
The reframing is valuable because it usually shows the intuition is wrong in both directions. Managed Postgres has a low exit cost — it is still Postgres — so the lock-in concern is modest. A proprietary workflow engine with its own DSL, or an ML platform with its own model format, has a high one. Teams frequently avoid the first and adopt the second.
In regulated sectors this is no longer optional: financial services regimes including the EU's DORA require documented exit strategies for critical outsourced services, with testing.
The related discipline that costs little: keep data in open formats, keep the proprietary surface at the boundary rather than through the codebase, and re-price the exit annually. That buys most of the portability benefit without the cost of writing to a lowest common denominator.