Stressed Exit

Most exit plans describe a planned exit: a two-year programme, provider engineers helping, migration credits, a negotiated end date. Supervisors ask about the other one. The provider has failed, been sanctioned, suffered a sustained outage, or terminated the contract at short notice, and nobody on the other side is helping. That is a stressed exit, and it is a different engineering problem rather than the same one compressed.

The distinction matters because the binding constraints swap places. In a planned exit the cost driver is engineering effort over time. In a stressed exit it is what you can do without the provider's cooperation, inside a window you did not choose.

Why it matters

Exit plans are graded on credibility, and the quickest way to fail that test is to lead with the egress bill. 220 TB at a sustained 10 Gbps moves in a little over two days; at egress list prices of five to nine US cents per GB in 2025 the transfer costs roughly 11,000 to 20,000 dollars. The EU Data Act removes switching charges for in-scope switching from 12 January 2027. The bytes and the money were never the constraint, and a plan built around them tells an examiner that nobody has tried.

What binds is the count of provider-specific control-plane dependencies on the critical path, and the parts of the change that belong to other organisations.

Implementation patterns

• Count and publish the provider-specific managed services on the critical path. Identity first, then queueing semantics, then the secrets store. That count is the most honest number in the plan.
• Rehearse one critical service a year, for real, to a second footprint, and record elapsed time. A measured partial exit beats a complete document.
• Keep a data copy outside the provider, in an open format, restorable without provider-specific tooling, and test the restore rather than the backup.
• Put the third-party work on the critical path explicitly: partner IP allowlists, bank and network registrations, certificate pinning in shipped mobile apps. Those move on other people's change control, measured in weeks.
• Define the degraded mode in advance. A 30-day answer is one critical business service, reduced, with a written list of what is switched off, approved by the business before the day.

Industry example

The regulatory framing is explicit. The EU's Digital Operational Resilience Act has applied to financial entities since 17 January 2025 and requires exit strategies for arrangements supporting critical or important functions, along with a maintained register of ICT third-party arrangements. Supervisory reviews in practice probe the same two things: what has actually been rehearsed, and what the firm can do when the provider is not participating. Firms that can show one rehearsed partial migration with elapsed times are treated differently from firms with a sixty-page document, and the difference is measurement.

Failure scenarios

• The egress-first plan, which costs the one line that does not matter and omits identity.
• A rehearsal in a sandbox where the provider's identity service is still available, so the hardest dependency is never exercised.
• Backups inside the provider, in the provider's snapshot format, restorable only by the provider.
• The analytics estate unowned, usually larger than the transactional one and absent from the plan entirely.
• A plan that claims 30 days for the whole estate, which fails the first examination question because the examiner can count your managed services too.

Trade-offs

The honest position for most firms is the middle one, with a rehearsal for the services a supervisor would name. The estimate for a genuine full exit is 6 to 18 months, and saying so with the managed-service count attached is stronger than a shorter number nobody tested.

When not to use it

Not every workload earns this treatment. For a non-critical system the proportionate answer is portable data formats, an exportable copy held outside the provider, and no rehearsal at all. Multi-cloud as a standing answer to concentration risk is usually the wrong trade: it doubles the operational surface, holds the architecture to the lowest common denominator of both providers, and still leaves identity and networking provider-specific. Buy the second footprint for the critical service, not for the estate.

Interview question

Q: Your regulator asks how long a stressed exit from your primary cloud would take: no provider help, 30 days. You have 220 TB, about 600 services, a managed Kubernetes cluster and the provider's identity, queueing and secrets services. What number do you give and what do you attach to it?

What a strong answer covers: the egress arithmetic, shown and then dismissed as non-binding; identity as the dependency that touches every service; third-party change control as work you cannot accelerate; a 6-to-18-month range for the full estate with a 30-day degraded scope for one critical service and a written list of what is dropped; and the annual rehearsal that converts the estimate from an assertion into a measurement.

Quick check

Quiz: In a stressed exit, which quantity dominates the error in your estimate? The number of provider-specific managed services on the critical path, not the data volume.

Flashcard: What distinguishes a stressed exit from a planned one? No provider cooperation and a window you did not choose, which moves the constraint from engineering effort to what can be done without the provider and without waiting on third parties.