--- id: SOV11 pillar: sovereignty title: SOV 11. How do you know your exit plan works? description: An exit plan nobody has executed is a document rather than a capability. The difference matters at exactly the moment it is least convenient to discover. status: draft services: [] tiers: [1, 2] sidebar: order: 20 label: Exit plan source_url: "https://framework.stackit.cloud/architecture/pillars/sovereignty/sov-11-exit-plan/" source_file: "docs/architecture/pillars/sovereignty/sov-11-exit-plan.mdx" --- Exit plans exist in most regulated organizations because a framework asks for one. They are written once, filed, and never executed, which makes them documents rather than capabilities. The distinction is the same one [`REL 8.3`](/architecture/pillars/reliability/rel-08-backup-and-restore/#rel-83-restore-on-a-cadence-into-a-clean-environment-and-time-it) draws about backups. A backup nobody has restored is a hope. An exit plan nobody has rehearsed is an assumption about a migration involving data volumes nobody has moved, dependencies nobody has enumerated, and a timeline nobody has measured. This is the last question in the pillar because it tests everything before it. If the placement is recorded, the dependencies inventoried, the data portable and the interfaces open, an exit is a project. If any of those is missing, it is a discovery exercise conducted under time pressure. ## Best practices - [`SOV 11.1`](/architecture/pillars/sovereignty/sov-11-exit-plan/#sov-111-write-the-plan-as-steps-somebody-could-follow) Write the plan as steps somebody could follow - [`SOV 11.2`](/architecture/pillars/sovereignty/sov-11-exit-plan/#sov-112-rehearse-the-parts-that-can-be-rehearsed) Rehearse the parts that can be rehearsed - [`SOV 11.3`](/architecture/pillars/sovereignty/sov-11-exit-plan/#sov-113-know-the-timeline-and-what-dominates-it) Know the timeline and what dominates it - [`SOV 11.4`](/architecture/pillars/sovereignty/sov-11-exit-plan/#sov-114-keep-the-plan-current-or-accept-that-it-expired) Keep the plan current, or accept that it expired --- ## SOV 11.1 Write the plan as steps somebody could follow **Risk if not established:** Medium Most exit plans describe an intention. A usable one describes a sequence, with the same specificity a runbook needs, because it will be executed by people under pressure who did not write it. Six things it has to contain. **What moves**, meaning every component and data set from the inventory in [`SOV 6.1`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/#sov-61-maintain-a-current-inventory-of-every-party-that-processes-your-data). **Where it goes**, at least as a class of target rather than a specific one. **In what order**, since dependencies constrain the sequence. **How the data gets there**, which is [`SOV 10.2`](/architecture/pillars/sovereignty/sov-10-open-interfaces/#sov-102-keep-data-in-portable-formats-and-know-how-to-get-it-out). **How correctness is verified** at the destination. **What happens to the original**, including the retention obligations that survive the migration. Include the parts that are not technical: contract termination, notification periods, licence transfers, the people who need to know, and the obligations that continue after the workload has moved. Write it for the reader who was not there. The author's knowledge is what makes an ambiguous plan look complete, and the author is frequently the person who has left. **On STACKIT.** The infrastructure side of the plan is largely enumerable from the Terraform definitions and the resource hierarchy, which is one of the underappreciated benefits of [`OPS 3`](/architecture/pillars/operational-excellence/ops-03-everything-as-code/): a declaratively defined estate has an inventory by construction, and an imperatively built one has to be reconstructed by hand. **Tradeoffs.** **Operational Excellence.** Writing a detailed plan takes real time for something you hope never to use, which is why it tends to be written badly once rather than well. **Verify.** Could somebody who did not write your exit plan execute it? Give it to them and find out. --- ## SOV 11.2 Rehearse the parts that can be rehearsed **Risk if not established:** High A full exit rehearsal is impractical for most organizations, and this is the practice most often skipped for that reason. The useful move is to rehearse the components rather than the whole, because the components are where the plan actually fails. What can be tested at reasonable cost. **Data export** at real volume, which finds the timing and the tooling problems. **Import into an alternative**, which finds the format and schema problems. **Deploying the workload elsewhere**, even in a minimal form, which finds the hidden provider dependencies. **The dependency inventory**, by attempting a deployment and noting what is missing. The last is the highest-value test in this question. An attempt to run the workload somewhere else finds the dependencies nobody documented, and it finds them in an afternoon rather than during a migration. Test the components separately and combine the results. A verified export path, a verified import and a verified deployment together give a much better estimate of the whole than an untested plan does, at a fraction of the cost of a full rehearsal. Record what the test found. A rehearsal that produces a list of surprises is a successful rehearsal, and the list is the reason to have done it. **On STACKIT.** Portability at the interface level is what makes partial rehearsal cheap. A Kubernetes deployment can be applied to another conformant cluster, an S3-compatible export can be read by any S3 client, and a PostgreSQL dump restores into PostgreSQL. That means the test is usually a day of work rather than a project, which removes the main reason it does not happen. **Tradeoffs.** **Cost Optimization** and **Operational Excellence.** A rehearsal consumes engineering time and target infrastructure for no product outcome. It is the only thing that converts the plan into knowledge. **Verify.** Which parts of your exit plan have actually been executed? When, and what did they reveal? --- ## SOV 11.3 Know the timeline and what dominates it **Risk if not established:** Medium An exit plan without a timeline cannot be assessed against a requirement, and requirements are frequently expressed in time: a regulator asking whether the workload could be moved within a period, or a contract specifying a transition window. Estimate per phase rather than in total: preparation, data migration, application deployment, verification, cutover, and decommissioning. The total is less useful than knowing which phase dominates, because that is the one worth improving. Data migration dominates for most workloads, and its duration is a property of volume and bandwidth rather than of effort. Adding people does not make it faster, which makes it the phase that has to be planned around rather than compressed. State what the estimate assumes. A timeline assuming full team availability, a cooperative target environment and no data growth is a best case, and the difference between it and a realistic case is worth writing down. Compare it against the requirement. Where the plan takes longer than the obligation allows, that is a finding now, when there is time to change the architecture, rather than during the assessment. **On STACKIT.** The measurable part is the export, which [`SOV 10.2`](/architecture/pillars/sovereignty/sov-10-open-interfaces/#sov-102-keep-data-in-portable-formats-and-know-how-to-get-it-out) asks you to measure at real volume. Everything else in the timeline is an estimate; that one can be a number, and it is usually the dominant term. **Tradeoffs.** None beyond the effort of estimating. A timeline that is uncomfortable is information rather than a problem with the estimate. **Verify.** How long would a full exit take, and which phase dominates? How does that compare with what your obligations require? --- ## SOV 11.4 Keep the plan current, or accept that it expired **Risk if not established:** Medium Exit plans decay faster than most documents, because they describe an architecture that changes weekly while the plan is reviewed annually at best. Attach it to the same triggers as [`SOV 2.4`](/architecture/pillars/sovereignty/sov-02-placement-and-residency/#sov-24-re-establish-residency-when-the-architecture-changes) and [`SOV 6.4`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/#sov-64-re-establish-the-chain-when-it-changes). A new dependency, a new data store or a new integration changes what has to move, and the plan is one line longer. Review the rehearsal results as well as the document. A test performed two years ago described the data volume of two years ago, and if the data has doubled the timeline has too. Be honest about the status. A plan marked as last verified on a date, with what has changed since, is more useful than one that reads as current and is not. A document that claims a capability the organization no longer has is worse than an acknowledged gap, because it prevents the gap from being noticed. Where maintaining it properly is not going to happen, say so and reduce the scope to what will be maintained. A plan covering the critical data path and honestly excluding the rest is worth more than a comprehensive one that has quietly stopped being true. **On STACKIT.** No platform feature maintains this. What the platform supplies is the current state: the resource hierarchy, the audit log in [`SOV 7`](/architecture/pillars/sovereignty/sov-07-auditability/), and the infrastructure definitions, which together make it possible to diff the plan against reality rather than to rewrite it from memory. **Tradeoffs.** **Operational Excellence.** Continuing maintenance for a document with no operational value until the day it has all of it. **Verify.** When was your exit plan last updated, and how many significant architecture changes have shipped since? Does it still list every data store you have? --- ## Related - [`SOV 10`](/architecture/pillars/sovereignty/sov-10-open-interfaces/) Open interfaces, which decides how much of this is feasible - [`SOV 6.1`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/#sov-61-maintain-a-current-inventory-of-every-party-that-processes-your-data) Processor inventory, which supplies what has to move - [`REL 8.3`](/architecture/pillars/reliability/rel-08-backup-and-restore/#rel-83-restore-on-a-cadence-into-a-clean-environment-and-time-it) Restore testing, the same argument applied to backups - [`OPS 3`](/architecture/pillars/operational-excellence/ops-03-everything-as-code/) Infrastructure as code, which makes the inventory exist by construction - [`SOV 1`](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/) Tier, which decides whether this question binds at all