Nobody signs a software development contract planning for the breakup. Everyone should. A vendor exit plan is the one piece of documentation that only matters on the day you did not expect to need it, which is exactly why almost nobody writes one while the relationship is healthy and every reason nobody wants to write one after it sours.
I have been on both sides of this. I have taken over systems from vendors who vanished, and I have handed systems back to clients who wanted to bring development in-house. The difference between a clean transition and a six-week forensic scramble is not legal leverage or goodwill. It is whether someone verified, in advance, that the client actually held what they thought they held: the code, the credentials, the documentation, the data.
This is not a distrust exercise aimed at any specific vendor. It is basic continuity planning, the same instinct that makes you keep a spare key, applied to the systems your business actually runs on.
What "Owning Your Code" Actually Means
Paying for software does not automatically mean you have access to it. I have seen businesses discover, mid-dispute, that their "custom system" lived entirely on a repository they had never been given credentials to, deployed to a server only the vendor could reach, built on a stack only one contractor understood.
A working vendor exit plan starts with three concrete checks, done now, not during a dispute:
- Repository access. Do you, or someone on your side, have an active account with at least read access to the actual source repository, not a zip file promised "on request"?
- Environment credentials. Do you know, and have logged somewhere secure, the credentials for your hosting provider, domain registrar, database, and any third-party API keys the system depends on?
- Deployment documentation. Is there a written record of how the system is actually deployed, which environment variables matter, and what the build and release process looks like, or does that knowledge live only in one person's head?
If the answer to any of these is "I assume so" rather than "I verified it last quarter," you do not have a vendor exit plan. You have an assumption, and assumptions are exactly what fail under pressure.
The Quarterly Fifteen-Minute Verification Ritual
You do not need a legal department to maintain this. You need a recurring fifteen-minute check, ideally tied to something you already do quarterly, like a board update or a budget review.
Each quarter, confirm:
- You (or your internal technical contact) can log into the repository and see a recent commit.
- You can log into hosting, domain, and DNS management directly, not through the vendor's account.
- Database credentials on file still work, and you know who else holds them.
- The documentation folder has been touched in the last quarter, or you know why not.
This ritual matters more the longer a vendor relationship runs well, because comfort is exactly when this kind of verification stops happening. The businesses that get burned are almost never burned by a vendor who was malicious from day one. They are burned by drift: an employee who left, a credential that was never rotated, a repository that quietly moved to a personal account two years ago and nobody noticed.
What to Put in the Contract From the Start
If you are engaging a new vendor now, this is the moment to negotiate exit terms while you have the most leverage, before the contract is signed and the relationship has begun.
Ask for, in writing:
- A named repository under your organization's account, not the vendor's, with the vendor added as a collaborator.
- A defined handover deliverable at contract end or termination: current codebase, environment configuration, database schema and export, and a written runbook.
- A reasonable transition window, typically two to four weeks depending on system complexity, during which the outgoing vendor remains available for questions.
- Explicit language on data ownership and portability, particularly relevant given the PDP law compliance obligations that now apply to how customer data is handled and transferred between parties.
None of this is adversarial to propose. A vendor confident in their own work has no reason to resist reasonable exit terms. The vendors who push back hardest on this clause are usually telling you something.
What a Bad Exit Actually Costs
I have walked into two very different versions of this. One was a multifinance company that had verified access quarterly as routine practice; when they switched development partners, the handover took eleven days, mostly spent on knowledge transfer rather than recovery. The other was a business that discovered, only after the relationship broke down, that their vendor held the only copy of the production database credentials and the only account with deployment access. That recovery took closer to two months, involved a forensic rebuild of parts of the system, and cost more in emergency engineering time than the entire original project had.
The difference was not the vendors. It was whether anyone had checked, while things were calm, that the client actually held what they thought they held. This is the same discipline that shows up in the hidden cost of legacy systems: the bill for neglect does not arrive on a predictable schedule, it arrives all at once, at the worst possible time, and it is always larger than the maintenance would have cost.
Do This Before You Need It
A vendor exit plan is cheap when the relationship is good and expensive to reconstruct when it is not. Spend the fifteen minutes this quarter. Confirm you can log into your own repository, your own hosting, your own domain registrar, independent of the vendor's goodwill. If you cannot, that gap is worth closing this month, not after the next dispute makes it urgent.
If you are bringing a system in-house or switching partners and want a second set of eyes on what a clean handover should actually include, reach out through partner and we can put together a proper transition checklist before you need one.