Reversibility: the clause you sign and never test.

All CIOs want a reversibility clause. Few confront one with a real export. The subject is not primarily legal. It is technical, documentary, and budgetary.

On the day of exit, a written promise is not enough. If the extraction fails, the clause does not protect. If the format is unreadable, migration stalls. If cost escalates, exit becomes theoretical.

The clause reassures — the test protects

A reversibility clause gives a feeling of control. It proves nothing about execution. It does not say which objects come out, in what order, or with what dependencies. It does not say whether attachments, logs, histories, routing rules, and metadata actually follow.

The trap is simple. A promise is signed, then the matter is considered closed. That is a governance weakness. An untested reversibility remains a hypothesis. On the day of departure, teams often discover that the export repository does not cover the usage repository. The data exists, but the links between objects do not.

Ask: "Can you give me the exhaustive list of exportable objects, with their exact format and functional dependencies?" Ask also: "Are attachments, tags, processing rules, and histories included without transformation?" The verifiable criterion is simple: an export must be readable by your teams without manual schema interpretation.

Require an annual test on a real perimeter. Not a test dataset. Not a demo PDF. A complete export, timestamped, verified by your teams, checking readability, completeness, and object coherence. The symptom of a false test is easy to spot: the file opens, but the business relationships have disappeared.

The real trap is the proprietary format

An export often exists on paper. The trap starts when the format remains vendor-dependent. Truncated CSV, half-documented JSON, compressed archive without a data dictionary, unpublished schema: the export becomes an elegant trap. You extract bytes, not a reusable asset.

The real question is not just "can we get out?" It is "can we reimport or exploit without rebuilding the model blindly?" If field semantics disappear, you lose operational value. The file is there, but nobody knows if an identifier is technical, functional, or historical.

Ask: "What is the export data dictionary, and in what form do you deliver it?" Ask also: "What is the schema version, and how do you manage breaking changes?" The contractual criterion to require is clear: published schema, versioned, documented, with change history and backwards compatibility for the duration of the contract.

Exit cost is never just the extraction

Reversibility has a budget. Teams often discover it only at the moment of decision. The extraction is rarely free. Configuration, transformation, validation, business verification — each step consumes time and skills. Without a prior estimate, exit budget is improvised at the worst moment.

Ask for a reversibility cost estimate before signing the main contract. Ask: "If we decided to migrate in twelve months, what would the exit cost be — in days of effort, technical prerequisites, and delay between decision and data availability?" If the vendor cannot answer, the cost is unknown, which means it is probably high. Require the estimate to be part of the contractual appendix.

An untested reversibility does not exist

The only reversibility that exists is a tested reversibility. Not a theoretical clause, not a vendor demonstration, not a past customer reference. A test carried out on your own data, your own format, your own business rules.

The annual extraction exercise does not have to be a full migration. It is a sampling: take a representative subset of objects, export them following the documented procedure, verify that the result is complete, coherent, and exploitable by an external system. This exercise typically takes two to three days. It is the only way to know whether the clause protects you — or decorates your contract.