This is the multi-page printable view of this section. .
Cloud Exit Playbook
-
1: The exit drill
-
2: Data first
-
3: Dependency inventory
-
4: Staged migration
-
5: Negotiate with an exit option
The playbook supports an operational conclusion: cloud exit is a staged, reversible engineering capability, not a leap into the dark. Begin by measuring recovery somewhere else; decide whether to migrate only after the constraints are visible.
Five practices
- Exit drill — restore a complete critical dataset elsewhere and time it.
- Data first — separate custody and recoverability from application migration.
- Inventory — map dependencies, semantics, contracts, and owners.
- Staging — move through replay, shadow, partial traffic, and reversible cutover.
- Negotiation — turn measured exit options into better contract terms.
The call to action is the first drill. It is useful even when the final decision is to stay with the current provider.
1 - The exit drill
The exit drill is the smallest useful measure of cloud exit capability. It does not change production traffic and should not require a migration project.
Objective
Produce a verified, usable copy of one critical dataset in an environment that does not depend on the original service’s control plane. Record elapsed time, human effort, cost, missing semantics, and every dependency that prevented a clean restore.
One-afternoon version
- Choose one dataset. Prefer important, bounded, and already backed up.
- Declare success. Counts, checksums, schema, permissions, recovery point, and one application query.
- Choose elsewhere. Another provider, a local host, colocation, or an independent open implementation.
- Start the clock. Include export preparation, transfer, restore, and verification.
- Do not improvise silently. Log missing credentials, undocumented steps, rate limits, and manual support.
- Verify independently. Use checksums plus semantic checks; “the command exited zero” is insufficient.
- Record the number. Report elapsed time, hands-on time, data age, total cost, and blockers.
- Clean up safely. Confirm retention and deletion requirements before removing the drill copy.
Scorecard
| Field | Record |
|---|---|
| Dataset and size | What was actually included |
| Recovery point | Age of the restored data |
| Elapsed time | Start to verified usable copy |
| Hands-on time | Human effort, by role |
| Direct cost | Export, transfer, compute, storage, support |
| Missing semantics | Roles, versions, policies, jobs, logs, keys |
| Blocking dependencies | Provider-only services, identities, approvals, tools |
| Repeatability | Scripted, documented, or one-off |
Safety boundary
Use non-production credentials and an isolated target. Do not weaken retention, encryption, privacy, or access controls to make the drill pass. A failed drill is a useful result; it identifies the next capability to build.
2 - Data first
Data is usually the slowest, heaviest, and least replaceable part of an exit. Separate its custody from the application cutover.
Sequence
- Define ownership, retention, recovery point, and deletion requirements.
- Maintain a documented export or replica outside the original control plane.
- Verify completeness with checksums and semantic tests.
- Rehearse restore on an independent implementation.
- Measure lag, throughput, cost, and the largest bounded recovery window.
- Only then design application replay or cutover.
“Data first” does not mean copying bytes while losing roles, schemas, versions, policies, keys, or audit context. C2 defines the completeness test.
3 - Dependency inventory
An exit plan is only as complete as its dependency map.
Inventory layers
- Data: stores, size, growth, versions, retention, backup, keys, owners.
- Interfaces: protocols, SDK calls, provider extensions, quotas, events.
- Identity: users, roles, policies, federation, secrets, break-glass access.
- Control plane: provisioning, deployment, observability, DNS, certificates, billing.
- Operations: on-call, runbooks, support paths, recovery objectives, drills.
- Commercial: contracts, credits, commitments, notice periods, termination, licenses.
- People: accountable owner, domain expert, approver, and replacement skill.
Mark each dependency portable, adaptable, replaceable, retained, or unknown. Unknowns are the first work queue, not a reason to invent certainty.
4 - Staged migration
Do not make the first real test a full production cutover.
Gates
- Offline restore: data and configuration rebuild successfully elsewhere.
- Replay: recorded or synthetic workload verifies semantics and performance.
- Shadow: target receives a copy of live changes without serving users.
- Partial traffic: a bounded cohort uses the target with measurable rollback.
- Cutover: recovery point, freeze window, decision owner, and abort threshold are explicit.
- Stabilize: run both observability and recovery procedures for the agreed window.
- Decommission: remove old dependencies only after retention, rollback, and contract gates close.
Every gate has success evidence, an owner, an abort threshold, and a tested path back. A hybrid end state can be a deliberate architecture, not a failed exit.
5 - Negotiate with an exit option
Negotiating power comes from a credible alternative, not an angry threat.
Bring evidence
- A current dependency inventory and the scope that can actually move.
- Exit-drill elapsed time, blockers, and independently verified data copy.
- Like-for-like cost model with sensitivity rather than one headline ratio.
- Commitment value remaining at each decision date.
- Required export, incident, support, and contract remedies stated as testable terms.
Ask for capabilities, not favors
Prefer automatic egress waivers, documented bulk export, transferable credits, shorter commitments, portable interfaces, incident-report deadlines, and usable SLA remedies over one-time discretionary discounts. A concession that disappears with the account team is not exit capability.