Reversibility: the clause you negotiate at signature, never on the way out

Reversibility is the set of obligations that let you take a service back in house or transfer it to a third party. It is the least discussed clause at signature and the most regretted on exit.

Why it is negotiated at the start

At signature your bargaining power is at its peak: the provider wants the contract. At the moment you want to leave it is nil: they know your systems, you need them for the transfer, and you are in a hurry.

Any clause obtained at the first moment is worth ten requested at the second.

The six elements to write down

1. Notice period, both ways. One month on embedded work, two to three on maintenance. Symmetrical: if the provider can terminate on one month and you on three, you carry all the risk.

2. The contents of the handover pack, listed. Not "all useful documentation", which commits to nothing. The precise list: source code and its history, architecture documentation, operating procedures, incident runbooks, inventory of access and service accounts, licence contracts, test datasets, environment configuration.

3. The assistance period after contract end. The provider remains available to answer the successor's questions for a defined period — thirty to sixty days is common — with an included day allowance and a rate beyond it.

4. The format of the deliverables. In your tools, in your format. A handover pack delivered in a proprietary format or on the provider's own file share is not a deliverable.

5. The fate of the data. Deletion or return at your choice, with written attestation, within a fixed period. This clause overlaps the DPA and must be consistent with it.

6. The price of reversibility, capped. Exit assistance billed at whatever rate the provider decides on the day is an empty clause. Set a cap in days or in amount at signature.

The test that proves it works

The most useful clause is the one providing for a reversibility rehearsal during the contract, once a year or at mid-term.

Concretely: the provider produces the complete handover pack, and you have it read by someone outside the file — another provider, an internal team, an architect. That person must be able to say whether they could take over.

It is the only way to discover the pack is incomplete before you need it. And the mere existence of that clause changes behaviour throughout the contract: documentation stays current because it will be looked at.

The lock-in signals to watch

• Documentation lives in the provider's tools, not yours.
• Code sits in a repository you do not control.
• Environments are hosted on the provider's cloud accounts.
• Access to third-party systems goes through the provider's named accounts.
• One person on their side knows your file.

None of these is necessarily malicious: they usually settle in through convenience. They produce the same effect as a deliberate strategy, and they are easy to correct if addressed early.

What a refusal tells you

A provider who refuses to write these clauses is telling you about the relationship they have in mind. That is useful information, obtained before signature rather than after three years.