Why exit complexity matters
An estimate of the cost of leaving a system can begin with its contract: a licence figure, a notice period, an export option. A contract-only reading can, however, omit work that sits outside the contract.
The work involved in leaving can be distributed across surfaces that no single team may own: the structure of exported data, the identity that downstream systems trust, the vocabulary staff use in meetings, the rationale behind configurations no one wrote down, the renewal clock that compresses the decision window. None of these appear on an invoice.
Exit Complexity treats those surfaces as one composite property. It does not ask whether a system can be left, but what would have to change inside the organisation for the departure to be real. High complexity does not make exit impossible; it describes the scope of the work. Whether that work can be done while operations continue is the question Reversibility addresses.
"The contract describes how to leave the vendor. Exit Complexity describes how to leave the system the vendor has built inside the organisation."
The five dimensions of exit complexity
Exit Complexity is read as a composition of distinct surfaces — each examined through structural questions rather than scored on a single index.
Data & Artifacts
- —Can data be exported in a format another system can ingest?
- —Are historical records, attachments, and metadata retrievable in full?
- —What relationships between records are lost in any export path?
Identity & Access
- —Where are user accounts, groups, and permissions defined?
- —Can identity be reissued elsewhere without breaking downstream systems?
- —How many integrations authenticate through this system?
Skill & Vocabulary
- —How much of the staff's working knowledge is platform-specific?
- —Are internal terms borrowed directly from the product's interface?
- —What would have to be re-taught before equivalent work could resume?
Contracts & Commercials
- —What termination, notice, and data-retrieval clauses apply?
- —Are there bundled discounts or commitments that span other systems?
- —What renewal mechanics make the decision-to-leave window narrow?
Institutional Memory
- —Where do decisions, rationale, and history live — inside or outside the system?
- —Can the organization reconstruct why current configurations exist?
- —Is there a record of past states the new environment will need?
What exit complexity is not
Exit Complexity is regularly conflated with neighbouring ideas that describe different things. It is worth stating the distinctions plainly.
- notLicence cost
- notContractual lock-in
- notData export availability
- notMigration project budget
A system can be cheap to cancel, contractually open, and technically exportable — and still be complex to leave. Exit Complexity is the total of what would have to change inside the organisation, not the cost printed on the way out.
The exit progression
An illustrative analytical progression, not an observed or universal lifecycle. Actual trajectories depend on architecture, organisational decisions, available alternatives, documentation and controls. In this scenario, successive planning stages surface additional work; in practice, estimates can also fall as dependencies are clarified or mitigated.
Nominal Exit
Leaving is considered as a contract question. Export tools exist, accounts can be closed, and the cost is read primarily in licence terms. The fuller picture has not been examined.
Surfaced Cost
Migration planning may reveal that data, identity, and skill are entangled with the system. Estimates can expand: retraining, vocabulary translation, and integration rework may appear as line items.
Organisational Change
In this scenario, exit has become an organisational change rather than a technical project. Where institutional memory, vocabulary, and identity are deeply absorbed into the platform, leaving involves substantial organisational work — demanding, but not impossible.
Conditions worth investigating
Conditions that may add to exit complexity beyond what a contract describes. They are prompts for investigation, not empirically observed recurring patterns.
- Exports lose structureAvailable export formats are flat files that strip relationships, history, attachments, or permissions — making the dataset look complete while removing what made it useful.
- Identity is the integrationOther systems authenticate, authorise, or provision through this platform. Leaving it means re-issuing identity across an unknown number of downstream dependencies.
- Staff speak in product nounsMeetings, documentation, and onboarding use interface labels as the working vocabulary. The terms do not survive a platform change without translation.
- Rationale lives only in ticketsWhy configurations, automations, and exceptions exist is recorded inside the platform's own comment threads — and would not transfer with the data.
- Renewal compresses the decision windowContract structure concentrates the practical opportunity to leave into a short pre-renewal window, after which switching may carry additional cost for another term.
How System Drift uses this framework
Exit Complexity is one of the dependency lenses applied across System Drift's published work. It appears, in different forms, in:
- ResearchLong-form analyses of how nominal exit options can differ from the full work involved in leaving a system.
- ProfilesDependency Profiles, currently evidence-pending research shells, list exit-related surfaces to examine; no exit complexity findings are published yet.
- ObservatoryDocumented changes, traced to primary sources, to contractual, export, and identity terms that may affect exit for specific systems.
The framework is descriptive rather than prescriptive. It helps read the current shape of an organisation's dependence; it does not recommend specific migration paths or replacement vendors. Statements on this page are analytical propositions, not findings from observed organisations; examples and progressions are illustrative scenarios.
Related reading
"The full work involved in leaving a system may not become clear until exit is planned. Exit Complexity is an attempt to read that work before it is needed."
— System Drift, framework F·05