Vendor lock-in – how to keep the door open
Vendor lock-in rarely comes from contract terms but from practice – undocumented code, accounts and keys owned by the vendor, and solutions built on proprietary platforms. Protect yourself by owning your own repo and accounts, requiring documentation, and avoiding unnecessary dependencies. Test your position yearly with one question: could we switch vendors within six months if we had to?
Vendor lock-in is the unpleasant discovery that you can’t leave a vendor even if you want to – that switching would be so expensive, slow, or risky that you’d rather put up with it. Many believe the protection lies in the contract, in a termination clause. But lock-in rarely arises in the legal text. It builds up in practice, one convenience at a time, until the door is closed without anyone deciding to close it. Here are the most common mechanisms and how you keep the door open.
Lock-in is built in practice, not in the contract
The crucial thing to understand is that most contracts can actually be terminated. Yet companies get stuck. The explanation is that the real dependency is technical and practical, not legal.
If the code is undocumented and only the vendor’s team understands it, if the cloud account and the domain are in the vendor’s name, if the solution rests on their own tools – then no right of termination in the world helps. You have the right to leave but not the ability. That’s why lock-in isn’t fought primarily with better contract language, but with practical countermeasures that give you the ability to move.
The five most common mechanisms
Five forms of lock-in recur, and they often reinforce each other. Recognize them and you can counter each one.
| Mechanism | Countermeasure |
|---|---|
| Undocumented code | Require ongoing documentation, written into the Definition of Done |
| Vendor-owned accounts | Own the repo, cloud account, and domain yourselves – invite the vendor in |
| Proprietary platforms | Avoid unnecessary dependencies on the vendor's own tools |
| Knowledge in individual heads | Require handover-ready documentation and spread the knowledge |
| Locked-in data | Make sure data can be exported in open, usable formats |
The most insidious one is vendor-owned infrastructure, because it often arises “for simplicity’s sake” early in a project. Letting the vendor set everything up in their own account saves an hour at the start and costs a negotiation from a position of weakness later. The rule is simple: anything that would be painful to lose should be in your name from the start, with the vendor invited in as a guest.
Healthy continuity versus unhealthy dependence
The point isn’t to avoid long vendor relationships – they’re often valuable. The point is to distinguish two things that look alike from the outside but are completely different inside.
- Healthy continuity is when you’re happy to keep working with a vendor that delivers well. You stay because you choose to, and you could leave if you wanted to.
- Unhealthy dependence is when you stay because you can’t leave. The choice is gone, and the vendor knows it.
The difference shows up the day something starts to chafe. A good relationship can withstand you having the ability to switch – it rests on the collaboration working, not on you being stuck. So the goal isn’t to switch often, but to always retain the option.
A scenario: two companies, the same vendor
Two companies hired the same agency. One let the agency own the repo, the accounts, and all the knowledge, “because it was convenient.” The other insisted on owning the infrastructure themselves, required ongoing documentation, and avoided the agency’s most proprietary tools.
When both considered a switch a few years later, the experience was completely different. The first company was told that a move would take months and cost significantly, and stayed reluctantly. The second determined that a switch would have taken a few weeks – and chose to stay anyway, but now because they wanted to, not because they had to. Same agency, same time, opposite freedom.
The annual lock-in check
Lock-in creeps up on you, so check it regularly. Once a year, ask the simple question: could we switch vendors within six months if we had to?
To answer, go through three things. Do you own the repo, cloud account, and domain yourselves? Is the documentation enough for a new team to take over without the current vendor? Can the solution and the data be moved without unreasonable effort? If you can answer yes with reasonable confidence, the door is open. If you can’t, you now know where the work needs to go – while it’s still a planned action and not a crisis.
If you want an independent assessment of your lock-in level, or want to build your next project so the door stays open from the start, we at Weapp are glad to help – and a technical review quickly answers how free you actually are today.
Frequently asked questions
Doesn't lock-in mainly arise from the contract?
Rarely. Most contracts can be terminated – the real dependency is practical. If the code is undocumented, the accounts are owned by the vendor, and the solution rests on their own tools, the right to terminate matters little, because you still can't move. Lock-in is usually a technical and practical condition, not a legal clause. That's why it's fought with practical countermeasures.
What are the most common lock-in mechanisms?
Five recur: undocumented code only the vendor understands, accounts and infrastructure owned by the vendor, dependence on their own proprietary platforms, knowledge that only exists in their heads, and data in formats that are hard to extract. Each binds you in its own way, and they often reinforce each other. The countermeasure for all of them is transparency and ownership from the start.
Is all dependence on a vendor a bad thing?
No. The distinction is between healthy continuity and unhealthy dependence. Wanting to keep working with a vendor that performs well is continuity – you stay because you choose to. Unhealthy dependence is when you stay because you can't leave. The goal isn't to avoid long relationships, but to always keep the ability to switch if you need to.
How do we check our lock-in level?
Ask once a year the simple question: could we switch vendors within six months if we had to? Review whether you own the repo and accounts, whether the documentation is enough for someone else to take over, and whether the solution can be moved. If you can't answer yes with reasonable confidence, you now know where the work needs to go before the need becomes urgent.