Most business owners think about avoiding software vendor lock-in only after they're already locked in, usually the day a vendor relationship sours and they realize nobody else can touch the system. By then it's too late to negotiate. The leverage you have to demand proper handover documentation exists at exactly one moment: before you sign the contract or before the first invoice gets paid. After that, you're asking for favors instead of enforcing terms.
I write handover documentation for a living, both for my own team's projects and when auditing what other vendors have left behind. The pattern is consistent: vendors who plan to be replaceable write clear docs from day one. Vendors who want to stay indispensable "forget" to, and it's rarely malicious, it's just that nobody asked for it explicitly, so it never got prioritized.
Why Lock-In Happens Even Without Bad Intent
Vendor lock-in isn't usually a vendor scheming to trap you. It's an absence: nobody wrote down where the code lives, nobody documented the deploy process, and the credentials for your own production servers exist only in one developer's password manager. When that developer leaves the vendor's team, or the vendor relationship ends, you discover the system is a black box even though you paid for every line of it.
This is especially common with smaller vendors and freelancers who move fast and skip documentation because "the client just wants it working." It's understandable, but it means the client, you, ends up owning a system nobody else can operate.
The Exact Artifact List to Demand
Before signing off on any development contract, or as a condition of ongoing payment for retainer work, require these five things explicitly in writing.
Full source code repository access, not just a zip export. You need commit history, branch structure, and the ability to clone and run it yourself, not a static snapshot handed over at the end. Ask for read access to the actual repo (GitHub, GitLab, or equivalent) from day one, not just at offboarding.
Environment and deployment documentation. A written runbook covering: what infrastructure it runs on, how a deploy is triggered, what environment variables exist and what they control, and what the rollback process looks like if a deploy breaks something. If this doesn't exist as a document, ask for it to be written, not verbally explained once.
A credentials inventory, stored in a vault you control. Every API key, database password, domain registrar login, and third-party service account should exist in a password manager or secrets vault that your business owns, not the vendor's personal tool. This is the single most common gap I find in vendor handovers: the client paid for the system but the vendor's personal 1Password vault is the only place the production database password exists.
Architecture documentation, even if brief. A one or two page document explaining how the major pieces fit together: which service talks to which, where the database lives, what third-party integrations exist and why. This doesn't need to be exhaustive, it needs to be enough that a new engineer can orient themselves in a day instead of two weeks of reverse engineering.
A named point of contact for handover questions, with a defined window. Vendors leaving a contract should commit to a specific period, typically 2-4 weeks, where questions from an incoming team get answered. Without this written in, you're relying on goodwill after the invoice is paid, which tends to evaporate quickly.
| Artifact | What it prevents |
|---|---|
| Repo access | Losing code history, being stuck without the actual buildable project |
| Deploy docs | Nobody being able to ship a fix or update after handover |
| Credentials vault | Being locked out of your own infrastructure |
| Architecture doc | Weeks of reverse engineering for any new team |
| Handover window | Silence the moment the contract ends |
The Annual Fire Drill
Demanding the docs at signing isn't enough on its own, because documentation rots. Environment variables change, new services get added, and six months later the "architecture doc" describes a system that no longer exists. The fix is a yearly test, not a one-time checklist.
Once a year, run this exercise: hand the existing documentation to someone who wasn't involved in building the system, ideally a different engineer or even a different vendor, and ask them one question. Could you deploy this tomorrow, using only what's written down? If the answer is no, you've found the gap before an emergency forces you to find it. This is cheap insurance compared to discovering the gap during an actual vendor transition under time pressure.
This discipline matters even more if you're estimating future work on a system you didn't build yourself. Bad or missing handover docs are one of the biggest hidden reasons why software estimates are always wrong: a quote based on incomplete visibility into the existing system will be wrong in ways nobody can predict until they're inside the code.
The Takeaway
Avoiding software vendor lock-in isn't about distrust, it's about treating documentation as a deliverable with the same weight as the code itself. Ask for the five artifacts above in writing before you sign, run the fire drill once a year, and you'll never be in a position where switching vendors feels impossible instead of merely inconvenient. If you're evaluating a new technical partner and want a second opinion on whether their handover practices hold up, that's exactly the kind of due diligence conversation worth having before signing anything, not after.