Exit clauses – your insurance for a vendor switch
Exit clauses govern what happens when an IT partnership ends: handover of code and documentation, knowledge transfer, notice periods, and data release in a machine-readable format. Written correctly, they make a future vendor switch undramatic. The best time to negotiate them is before the partnership begins, while you still hold the negotiating position.
No one signs a development contract thinking about switching vendors. Yet that’s exactly when, at signing, a future switch gets decided – because it’s the only time you hold the negotiating position to make it painless. Without exit clauses, a switch can become expensive, drawn out, and dependent on the goodwill of a vendor you might be leaving on bad terms. This guide covers the clauses that turn a switch into an orderly process instead of a conflict.
Handover: code, documentation, and knowledge
The core of an exit clause is what the vendor actually has to hand over. It’s not enough for the contract to say you “own the code” – it also has to require that it’s handed over in usable condition.
A complete handover covers four parts:
- The source code, complete and in buildable condition, so a new vendor can pick up without missing pieces.
- The documentation, up to date and sufficient to understand how the system is built and operated.
- Access to accounts and environments – servers, domains, third-party services – with an orderly transfer of ownership.
- Knowledge transfer to the new team, ideally through an agreed number of consulting hours where the departing vendor answers questions.
The last point is the one most often forgotten. Code without knowledge is like a building without blueprints: everything is there, but no one knows where the wiring runs. A couple of weeks of overlap where the old vendor remains available can save the new one months of guesswork – but only if it’s written into the contract, since goodwill is rarely there to lean on once a partnership has ended.
Notice period and data release
Two terms determine how smoothly the actual disconnection goes: how much time you have, and in what condition you get your data.
The notice period should be long enough to procure a new vendor and carry out a handover, but not so long that you’re stuck in a partnership that isn’t working. It should also be mutual and clear, so neither party can drag out the process.
Data release matters just as much and is often overlooked. Your data is yours, but it doesn’t matter if you get it in a format you can’t use. The contract should establish that data is released in a machine-readable, documented standard format that can be imported elsewhere – not as an unreadable database dump or a pile of PDFs. A classic lock-in trick is making the release so impractical that staying feels easier. A clear clause closes that door.
What’s allowed to cost extra – and what should be included
A reasonable exit isn’t free, but it also shouldn’t be a penalty that makes switching unprofitable. The line runs between actual extra work and things that should have existed all along.
| Item at exit | Reasonable handling |
|---|---|
| Your own data | Included – released in a usable format at no extra charge |
| Source code you've paid for | Included – handed over complete at no extra charge |
| Basic documentation | Included – kept up to date on an ongoing basis |
| Consulting hours during handover | Billable – actual work performed at the agreed rate |
| Extensive custom export | Billable – if it goes beyond a standard format |
The principle is simple: what you’ve already paid for you should get without a ransom, while new work during the transition can reasonably be billed. When the line is written into the contract, the exit cost can’t be used to lock you in.
A concrete scenario
An organization wanted to switch vendors after a few years, since the partnership had cooled and the price had risen. The contract included a well-thought-out exit clause: three months’ notice, source code and documentation to be handed over complete, data release in a standard format, and twenty consulting hours for knowledge transfer.
The switch was undramatic. The new vendor received the code in buildable condition, could ask the departing team questions during the transition, and imported the data without trouble. What could have become a month-long conflict over who owned what, without the clauses, instead became a planned handover over a few weeks. The insurance taken out at signing turned out to be worth far more than it cost to negotiate.
Negotiate the safety net before you sign
Exit clauses feel unnecessary in the optimistic phase when a new contract is being written – and that’s exactly why they get forgotten. But they cost almost nothing to negotiate at that point and become impossible to secure once they’re actually needed. Think of them as insurance: you hope never to use it, but you don’t want to buy it after the fire.
At Weapp, we work to make sure our clients never feel locked in, and we’re happy to help buyers assess exit terms as part of our services. Facing a development contract to sign? Get in touch and we’ll go through which clauses are worth having in place before pen meets paper.
Frequently asked questions
What is an exit clause in an IT contract?
A part of the contract that governs how the partnership winds down and what the vendor must hand over when it ends. It covers handover of code and documentation, knowledge transfer, notice periods, and how your data is released. The purpose is for a switch to happen in an orderly way, whether the reason is dissatisfaction, a price change, or that you've outgrown the vendor.
Why negotiate exit terms before the partnership even starts?
Because that's when you hold the negotiating position. Before the contract is signed, the vendor is competing for your business and willing to agree to reasonable terms. Once the partnership is underway, and you depend on the vendor, those same terms are much harder to secure. Settling exit terms early is the cheapest and safest option – much like buying insurance before the fire starts.
What should a handover include at a vendor switch?
The source code in complete, buildable condition, up-to-date documentation, access to accounts and environments, and knowledge transfer to the new vendor. The contract should often also specify a number of consulting hours where the departing vendor answers questions during the transition. Without regulated knowledge transfer, the code can be complete yet still hard for the next team to take over.
In what format should data be released at exit?
In a machine-readable, documented standard format that can be imported into a new system. A PDF dump or a locked database you can't interpret isn't a real data release. The contract should establish that your data is yours, that it's released in usable condition, and that nothing is held hostage to pressure you into continuing the partnership or paying extra.
What's reasonable for exit to cost extra?
Actual work performed during the handover itself can reasonably be billed, such as consulting hours and a larger data export. What shouldn't cost extra is anything that should have existed all along: your own data, the code you've paid for, and basic documentation. The contract should draw that line clearly, so the exit cost doesn't become a way to lock you in.