Most technology exit plans begin with sensible things: an inventory, named owners, architectural diagrams, contractual notice periods and a proposed destination. Every one of those artefacts matters. None of them, alone, proves that a workload can move.
A plan is intent. An exit proof is evidence from an executed, scoped and repeatable test.
The missing unit is the workload
An account, subscription or provider contract is usually too broad to assess as one thing. A workload has a boundary: compute, data, messaging, identity, delivery and operational dependencies that together provide a business capability. Readiness has to attach to that boundary and to a specific revision of it.
That changes the question from “Could we leave AWS?” to “Can this version of this workload satisfy these mandatory checks for this target, with evidence that is still current?” The latter can be answered without turning a narrow result into a sweeping promise.
What a defensible result needs
- Scope: the exact resources and dependencies included—and excluded.
- Target: the alternative being evaluated, or the options assessment being performed.
- Checks: deterministic pass, fail, unsupported and incomplete semantics.
- Evidence: outputs tied to the test, tool and workload versions.
- Freshness: a policy for when changes make that evidence stale.
- Limitations: known gaps that remain visible rather than being averaged away.
Why we avoid a magic score
A single percentage can be useful for portfolio navigation, but it can also hide the denominator and imply precision the evidence cannot support. PortabilityLabs uses categorical outcomes at workload level and keeps evidence completeness separate from test outcome.
A passed test means that every mandatory check passed for the declared workload revision, target and test version. It does not certify the whole organisation or promise that a future, changed workload will behave identically.
The operational habit
The aim is not to run a one-off migration rehearsal for every workload every day. It is to maintain a change-aware assurance loop: discover what changed, determine which evidence may be affected, apply cheap deterministic checks first, and reserve expensive execution for material uncertainty.