Why exit complexity matters
Most organisations estimate the cost of leaving a system by reading its contract. A licence figure, a notice period, an export option — and the question is treated as answered. This is almost always an undercount.
The real cost of leaving is distributed across surfaces that no single team owns: 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 — almost any system can — but what would actually have to change inside the organisation for the departure to be real.
"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 extremely 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
Exit Complexity is rarely measured before it is needed. It tends to be discovered in phases, each one revising the previous estimate upward.
Nominal Exit
Leaving is contemplated 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 reveals that data, identity, and skill are entangled with the system. Estimates expand: retraining, vocabulary translation, and integration rework appear as real line items.
Structural Lock
Exit is no longer a project but an organisational change. Institutional memory, vocabulary, and identity have been so absorbed into the platform that leaving would reshape how the organisation knows itself.
Common indicators of high exit complexity
Patterns that recur in organisations whose exit cost is far higher than their contract suggests.
- 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 costs rise sharply for another full 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 why nominal exit options understate the real cost of leaving widely-adopted systems.
- ProfilesDependency Profiles include an Exit Complexity reading alongside Reversibility and Governance Surface.
- ObservatoryTracking of contractual, export, and identity changes that meaningfully widen or narrow the exit window 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.
Related reading
"Most organisations do not discover the true cost of leaving a system until they try. Exit Complexity is the attempt to read that cost before the attempt is made."
— System Drift, framework F·05