F-001 Reversibility — System Drift

§ 02

Why reversibility matters

Organizations typically evaluate software based on adoption cost: how quickly a tool can be deployed, learned, and made productive. That framing tells us a great deal about onboarding and very little about long-term dependency.

System Drift evaluates software partly through exit cost. The difficulty of leaving a platform often reveals more about dependency than the ease of joining it. A system that is trivial to adopt and impossible to leave is not a neutral piece of infrastructure; it is a structural commitment.

Reversibility reframes the question. Instead of asking what a system enables, it asks what continues to function — and at what cost — if the system is withdrawn.

“The easiest systems to adopt are not always the easiest systems to leave.”

§ 03

The five dimensions of reversibility

Reversibility is not a single measurement. It is the composition of several distinct surfaces, each evaluated through structural questions rather than scores.

D·01

Data Portability

—Can information be exported?
—Is the format usable elsewhere?
—Is metadata preserved?

D·02

Workflow Portability

—Can workflows be recreated elsewhere?
—Are automations platform-specific?
—Does the process depend on unique platform features?

D·03

Identity Dependence

—How much access control runs through the platform?
—What breaks if identity is removed?

D·04

Organizational Memory

—Where do decisions live?
—What knowledge exists only inside the system?

D·05

Political & Operational Cost

—How much retraining is required?
—How many teams are affected?
—How much organizational resistance exists?

§ 04

What reversibility is not

Reversibility is frequently confused with adjacent properties that look similar but describe something else entirely. It is worth stating the distinctions plainly.

notContract length
notSoftware quality
notVendor reputation
notCustomer satisfaction

A system can be well-liked, well-built, and faithfully supported, and still be difficult to leave. Reversibility is a structural property of how the system sits inside an organization — not a judgment of the system itself.

§ 05 · Framework view

The reversibility curve

Reversibility is not static. It changes over time as systems move from adoption into deep operational embedding.

Phase 01

Adoption

Low dependency. The system sits alongside existing operations. Exit, if required, remains a largely technical exercise: export data, disable accounts, decommission integrations.

Phase 02

Integration

Dependencies accumulate. Automations, identity bindings, and cross-team workflows begin to settle around the platform. Exit becomes progressively more complex and requires coordination across functions.

Phase 03

Embedded Operation

Workflows, identity, and institutional memory become intertwined with the platform. Exit is no longer a technical project. It is an organizational one — touching governance, training, vocabulary, and decision history.

Reversibility decreases →Organizational cost increases →

§ 06

Common indicators of low reversibility

Patterns that frequently appear together inside organizations where exit has become structurally expensive.

Large automation footprint
Significant volumes of business logic encoded inside the platform's automation surface, with limited documentation outside it.
Proprietary workflow logic
Processes expressed in platform-specific constructs that have no clean equivalent in neutral tools or competing systems.
Extensive identity integration
Authentication, authorization, and group membership routed through the platform for systems well beyond its original scope.
Platform-specific training
Internal enablement, onboarding, and certifications oriented around one product's interface and terminology.
Deep cross-department adoption
Use spans functions that rarely coordinate directly, making any change a multi-stakeholder negotiation rather than a tooling decision.

§ 07

How System Drift uses this framework

Reversibility is one of the primary lenses used across System Drift's published work. It appears, in different forms, in:

ResearchLong-form publications describing how operational dependency forms and stabilizes over time.
ProfilesDependency Profiles describing the structural posture of individual platforms and the organizations that rely on them.
ObservatoryTracking of pricing, policy, and architectural changes that quietly alter the reversibility of widely-used systems.

The framework is descriptive rather than predictive. It helps interpret dependency as it exists today; it does not forecast vendor behavior or recommend procurement decisions.

§ 08