The exit clause you negotiate before you need it
An exit clause is only obtainable while you can still walk away. The five things it must name, the three parameters that decide whether it works, and a clause you can reuse.
By Laurent TulpanPublished 9 min read
An exit clause is a contract term you use once, and by the time you use it, it is almost always too late to negotiate.
The mechanism is always the same. At signature the end looks distant and theoretical, and nobody wants to open a relationship by discussing its termination. By the time it matters, the vendor holds the system, the data and the credentials, and the discussion is no longer a negotiation.
What it must name, because nothing is implied
A general clause of the kind “the vendor shall ensure reversibility” commits to nothing executable. Five items have to be named separately, because the absence of any one is enough to block an exit.
The data, in an open and documented format. Not “an export”: the format, and its description. An export in a proprietary format only the original tool can read is not a return, it is an unusable copy. The useful wording names the expected format, or failing that requires a widely supported standard together with a description of the fields.
The source code, where the software is yours. With the repository, the history and the build instructions. Code delivered as an archive without its history or its build procedure takes weeks to bring back into working order. Whether it is yours at all is a separate question with a surprising answer in some jurisdictions, and it is worth settling before you assume it.
The operating documentation. How the system is deployed, where the data live, what it depends on externally, how to restart it. This is the document nobody thinks to ask for and without which a successor spends weeks reverse-engineering before they can help you.
The credentials. Hosting, domain names, certificates, third-party service accounts. A hosting account in the vendor’s own name is the most effective blocking point that exists, and it is discovered only at the moment of leaving. Better still: have those contracts in your name from day one, so there is nothing to recover.
Assistance to the successor. A number of days, at a rate fixed at signature. Without that, assistance becomes a service to be negotiated at a moment when you are in a hurry and the vendor has no reason left to accommodate you.
The three parameters that separate a useful clause from a decorative one
The deadline. Counted from your request, not from the end of the contract. A clause providing for return “at the end of the contract” authorizes waiting until the last day, which leaves you no margin to discover something missing. Thirty days from written request is common and workable.
Who pays. The question that creates friction, so better to create it now. A return billed by the hour, uncapped, by a vendor whose relationship with you is ending badly, is a clause that does not protect you. Two wordings hold: the return is included, or it is capped at an amount fixed at signature.
What triggers it. The clause must apply whatever the reason for the ending, including termination for the vendor’s own breach. A reversibility clause that does not apply in a dispute does not apply in the one case where you genuinely need it.
A clause you can reuse
A compact wording, to be adapted, covering the five items and the three parameters.
“On termination of this agreement for any reason, including termination for breach by either party, the vendor shall return to the client, within thirty days of written request: (1) all data in an open and documented format, (2) the source code produced for the client together with its history and build instructions, (3) up-to-date operating documentation, and (4) all credentials for hosting, domain names, certificates and third-party services used. This return is included in the price of the agreement. The vendor shall further provide up to N days of assistance to a successor designated by the client, at the daily rate set out in the annex. The vendor may not condition the return on payment of disputed sums.”
That last sentence is the one people forget and it is decisive. Without it, a disagreement over one invoice can hold your data hostage, which turns an ordinary commercial dispute into an operational shutdown.
The annual test, which is worth more than the clause
A written clause that has never been exercised is a hypothesis.
The test takes half a day, once a year. You request the export the contract provides for. You open it. You check that it contains what it should and is readable without the original tool.
Three possible outcomes, and all three are useful.
The export works: you know the clause is executable, which beats assuming it.
The export exists but is unusable, incomplete, in an impossible format: you learn it at a point where you can still demand a correction, rather than on the day you leave.
The vendor provides nothing, or stalls: that is the most valuable of the three, and it arrives early enough to act on.
This check has a side effect that matters as much as the result. A vendor who knows you test the exit behaves differently from a vendor who believes you are captive.
What it changes even when you never leave
This is the least intuitive point and the most important.
An exit clause is not only for leaving. It is what allows you to stay on good terms.
A contract you can leave gets renegotiated. Rates stay discussable, service commitments get tightened when they are missed, requests get answers. A contract you cannot leave gets endured, and that shows up in service quality long before it shows up on the invoice. It is the same mechanism as the renewal window on a tacit rollover, and it is why the moment of signature is worth an uncomfortable extra week.
That is also why we transfer source code, documentation and credentials as a matter of course, including where nobody asks. Not out of generosity: a client who can leave is a client who stays for good reasons, and a system built to be handed over is a simpler system whether or not anyone ever takes it over.
Further reading
- Who owns the code your contractor writes: whether there is even anything to hand back
- Changing vendors without losing the system: what the clause looks like when exercised
- When one person is your only backup: the same exposure, inside the organization
- Modernize or renegotiate: pricing the exit as part of the decision
- Post-launch support: a light watch that can be stopped with one month’s notice
The questions this raises, answered straight.
What is an exit clause supposed to cover?
The vendor's commitment to hand back, at the end of the contract, everything needed to continue without them:
- the data in a usable format
- the source code where it is yours
- the operating documentation
- the credentials to hosting and third-party services
It also sets the deadline and says who pays. Without it, the end of the relationship is negotiated at the moment you have the least leverage you will ever have.
When should it be negotiated?
Before signature, and only then. While nothing is signed you can go elsewhere, and that possibility is your entire leverage.
Once the system is in production the vendor is the only party who knows it, and asking for an exit clause becomes a renegotiation whose outcome depends on their goodwill. The moment it costs least to obtain is the moment it appears least necessary.
Can a vendor refuse it?
They can argue about scope and deadlines, which is legitimate. A refusal on principle tells you something: the only reason to decline committing to return a client's own data is to keep the option of not returning it. That is an answer worth hearing before signature rather than after.
Is the clause enough on its own?
No, and this is the most common mistake. A written clause that has never been exercised is a hypothesis.
What guarantees the exit is testing once, mid-contract, that the export actually runs and that the resulting file opens. An annual check turns a contractual promise into a verified fact, and it costs almost nothing.
Recognize your situation? 20 minutes is enough to tell.
Describe what is happening on your side, and where your data and customers are. You get a plain answer on whether we can help, and a better route if there is one.