Vendor lock-in: how to keep control of software you paid for

Most companies do not find out they have a vendor lock-in problem until they try to leave. For years everything runs smoothly: the vendor delivers, the system works, the invoices arrive. Then comes the moment — a price change, a key person leaving the vendor's side, development slowing down, or simply a routine tender — and the company discovers that the source code repository sits under the vendor's account, the domain is registered to the vendor's company, production runs on the vendor's cloud account, and the only person who knows how the application is deployed works on the other side. The software is paid for. Control over it is not.

We are writing this as a vendor, which is a mildly uncomfortable position — everything we recommend here also reduces our own bargaining power. We do it because the difference between a client who has these things in order and one who does not never shows up during the engagement, only at its end. And by then it is too late to negotiate anything.

Not every dependence on a vendor is a problem. A team that has spent three years building your internal system knows things about your processes that are not, and never will be, written in any documentation — why one type of order is approved differently, which customer has an exception, what happened during the migration two years ago. That knowledge is value you are paying for, and moving it elsewhere will be expensive no matter how well your contracts are drafted.

Vendor lock-in is something else: an artificially inflated cost of leaving that comes not from knowledge but from access and artefacts. The test is simple. Imagine the engagement ends tomorrow, amicably. How many weeks would another competent team need to ship its first non-trivial change to production?

If the answer is "weeks", you have healthy dependence. If the answer is "no idea" or "we would have to rewrite it", you have lock-in — and it does not matter how good the current relationship is.

This is the core of the whole topic and also the only part that can be fixed in a single afternoon. The difference between "the vendor promised us the code is ours" and "the code is in a repository where I own the organisation" is the difference between trust and control. Trust is a good thing, but it is not a safeguard.

The most underrated item is the database export. "We back up daily" is a claim, not evidence. A backup nobody has ever restored into a clean environment is just a file with unknown contents. A tested restore is also the single best step you can take to reduce dependence — because data is the one thing that genuinely cannot be produced again.

A contract does not replace access, but it covers what cannot be held technically. When choosing a partner it pays to work through these systematically — they belong to the same family of questions as a checklist for choosing a software vendor, except people usually get to them too late.

IP assignment tied to payment. The phrase "we grant a licence to use the work" is not the same as an assignment of rights. The assignment should cover intermediate outputs too: designs, migration scripts, infrastructure code, tests. Tying it to payment is fair to both sides — the vendor does not hand over rights to unpaid work, and the client receives them automatically once the invoice is settled, with no further signatures.

A handover obligation (exit clause). Without it, handover is goodwill. The clause should define what (the list of artefacts in the table above), by when (a number of calendar days from termination), in what form (a handover protocol, access transferred rather than passwords forwarded) and how many consulting hours are included.

Post-handover rates. Agree them while you still have bargaining power — at signature, not at exit. Even a decent vendor has other priorities once the engagement ends, and an hourly rate negotiated then tends to differ from the project rate.

Notice period, symmetrical. If the client owes three months and the vendor owes thirty days, that is not a partnership agreement.

Source code escrow. Depositing code with a third party makes sense for packaged products where source is not normally delivered. For custom development it is usually unnecessary — a repository held directly by the client solves the same problem more cheaply. And beware: escrow without a tested build procedure is an illusion of safety. An archive nobody can turn into a running application is not insurance.

Subcontractors and commercial licences. If the project uses a paid library, component or template bought in the vendor's name, that licence does not move with you. You want a list of every such item and, ideally, purchases made in your own company's name.

A contract will not stop your vendor from leaving. It will only stop you from losing the software when they do.

Part of lock-in is created at design time, long before any conflict, and nobody means any harm by it.

A mainstream stack instead of an exotic one. This is not about fashion, it is about the labour market. An application built on widely used technology has hundreds of people who can take it over; an application on a niche framework has dozens, half of them at the original vendor. This is one of the quieter arguments in the choice between custom software and an off-the-shelf SaaS product — with SaaS, lock-in is effectively part of the product, it just goes by another name.

Architecture documented well enough that "a new developer can run it locally in half a day". It does not have to be an extensive document. A README with setup steps, a data flow diagram and a page describing where the application is deployed and what happens during deployment will do.

No undocumented proprietary layer. A vendor's internal libraries and generators are legitimate — they speed up the work and the client benefits. The problem starts when they are not covered by the assignment of rights, or when they have no documentation. Ask directly: "Which parts of the system are your internal components, and what happens to them when we part ways?"

Infrastructure as code and separation of data from the application. An environment that can be recreated from a file in the repository is portable. An environment somebody clicked together in a console years ago is not. The same goes for data: a standard relational database with an exportable schema keeps the door open, while data locked in one service's proprietary format closes it.

Automated tests as a form of documentation. For an incoming team a test suite is often more valuable than prose — it states what the system is supposed to do, and it can be run.

Here is the honest counterargument that articles on this topic usually omit. Every layer added "for portability" costs something. A database-agnostic abstraction means giving up half the capabilities of the database you actually use. An architecture prepared for three clouds gets written, in practice, to the lowest common denominator of all three. Software deliberately designed to be easy to replace tends to be more generic, more boring and worse fitted to what your company actually does — and fit is precisely why you commissioned custom software in the first place.

The same applies to the relationship. A vendor who knows they can be swapped out at any moment behaves like a commodity supplier: they do exactly what the specification says and never propose the idea that would save you three months of development. Part of the value of a long-term engagement comes from both sides investing beyond the current order. That cannot be had for free.

So the goal is not a zero switching cost. The goal is a cost you know in advance and can afford to pay. The difference between "switching will cost us roughly two to three months of overlap and some lost momentum" and "we have no idea whether it is even possible" is the entire difference between making a decision and being held hostage.

If the system has been running for years, you do not need to rewrite the contract immediately. An honest inventory is enough — it can even be a joint exercise with the vendor; a decent partner will have no problem with it.

1. Walk through the artefact table and, for every row, write down the actual account name and owner, not "we have it".
2. Have a change deployed to production in front of you and note everything that happens along the way.
3. Request a restore of the latest backup into an empty environment and verify record counts.
4. Give one independent developer two days to run the project locally from the documentation. Whatever they end up missing is your real lock-in.
5. Feed the results into a contract amendment and into your plan for software maintenance and development after launch, so the situation does not deteriorate again.

If the inventory shows the system is technologically at the end of its life, the lock-in question merges with the renewal question — in that case read this alongside the approach to migrating a legacy system to a modern platform, because a migration is also the best opportunity to put ownership in order.

Vendor lock-in is not a question of trust and it rarely comes from bad intentions. It comes from small decisions that make sense on the day they are made: the vendor creates the repository because it is faster, the domain is registered on their account because it takes five minutes, production runs where they already have access. Three years later this adds up to a situation that cannot be unwound in a week.

Hold artefacts, not promises. Cover contractually what cannot be held technically. Choose technology someone else can take over. And at the same time, do not overdo it — a certain amount of entanglement with a good partner is the price of software that genuinely fits your processes, and it is a price worth paying knowingly. At INTERFASE we treat it as normal that the client owns the repository and the infrastructure from day one; it is the only way an engagement can stay voluntary on both sides. If you would like to run an ownership inventory on an existing project, or set up custom software development so that you hold everything essential from the start, get in touch with us and we will go through it point by point.