Provider Exit Plan
A documented and tested plan for moving a workload off a provider, whose credibility is measured by what has actually been rehearsed rather than described.
Exit plans are commonly written to satisfy a requirement and never exercised, which makes them a description of an intention. What makes one credible is evidence.
The plan needs four things. What would move, at the level of individual services and datasets, with their dependencies on provider-specific capabilities made explicit — a workload using a proprietary database, a managed identity service and a serverless runtime is not portable in the way a containerised application on open components is. How long it would take, derived from something more than an estimate. What it would cost, including egress charges, which are frequently the largest single line and are routinely omitted. What has been tested — even restoring one dataset into another environment and running against it establishes far more than a document does.
The related exposure is concentration: not only dependence on one provider, but a whole sector depending on the same few, which supervisors have begun to treat as a systemic concern rather than a firm-level one.
The design lever is deliberate rather than absolute. Full portability is expensive and forgoes the managed services that make cloud worth using. The defensible position is a conscious decision per component about how much lock-in is being accepted and why, recorded rather than accumulated by default.