A regulator requires a credible exit plan from a critical cloud provider. What does a genuine exit capability require, and what makes most exit plans fiction?

Why the requirement exists

Financial and other regulated sectors have become materially dependent on a small number of cloud providers. A provider failure or an abrupt commercial termination would affect many institutions simultaneously, which is a systemic rather than an individual risk — and it is why supervisors ask for exit plans rather than for assurances.

What makes most exit plans fiction

• They document intent rather than capability. A plan describing how the organisation would migrate, with no tested mechanism, is a narrative.
• The timeline is implausible. Migrating a large estate takes many months; a plan asserting a few weeks has not been costed.
• They ignore managed services. Compute and storage are portable; the managed database, the message broker, the identity service, the analytics platform and the machine-learning stack are where the real coupling is, and each has a different destination and a different effort.
• Data gravity is not modelled. Moving petabytes takes time and egress cost that is frequently larger than every other line item — and the transfer alone may exceed the plan's stated timeline.
• They assume an orderly exit. The scenarios that justify the requirement are disorderly: a provider withdrawing from a market, a regulatory prohibition, or an abrupt commercial failure.
• Never rehearsed. An untested migration path is an assumption, and this one is asserted to a regulator.

What a genuine capability requires

• A tested ability to run something meaningful elsewhere. Not the whole estate — one real workload, actually deployed and running on an alternative provider, exercised periodically. This converts the plan from narrative to evidence.
• Portable abstractions where the cost is reasonable: containers rather than proprietary runtimes, open table formats rather than proprietary storage, standard SQL behind a boundary, infrastructure as code that is not provider-specific in its structure.
• Managed-service coupling documented explicitly, per service, with the destination and the effort estimated — this inventory is the substance of the plan and is what most plans omit.
• Data portability tested: an actual export of a representative dataset in a usable format, timed, so the duration and cost are measured rather than assumed.
• A staged exit design, since a simultaneous move is not feasible — which workloads move first, what runs in both places during the transition, and how data is kept consistent.
• Contractual protections: notice periods, data return obligations, and assistance commitments.
• A realistic timeline with a cost, presented honestly to the board and the regulator.

The honest position

Full portability is expensive and frequently not worth its cost. Avoiding every managed service to preserve optionality means running everything yourself, which sacrifices the reason for using a cloud provider at all.

The defensible position is graduated: portable for the components where portability is cheap; documented, costed and accepted coupling where it is not; and a tested capability to move at least one significant workload, which is what distinguishes a plan from a document.

And the alternative risk should be stated too. Multi-cloud to reduce concentration risk introduces cross-cloud data transfer at the highest available prices, doubles the operational surface, and frequently increases total risk by adding complexity — so it is a decision to be made on evidence rather than adopted as a default answer to the question.