Nobody signs a contract expecting to be trapped. Vendor lock-in never arrives as a warning. It arrives two years later, when you want to switch tools and discover that your data is hostage, your custom features belong to someone else, and the cost of leaving is higher than the pain of staying. By then the vendor knows it, and their renewal price reflects it.
I have watched capable companies stay with software they had outgrown, paying more each year, because the exit was too expensive to contemplate. That is what vendor lock-in actually costs. Not a bad product, but a lost ability to choose.
The good news is that lock-in is almost always visible before you sign, if you know which questions to ask. This is not about distrusting your vendor. Think of it as insurance. You buy it hoping never to use it, and you are grateful it exists the day you need it.
When does vendor dependence become lock-in?
Vendor dependence crosses into lock-in at one specific point: when the switching cost is high and the vendor, not you, controls how high it goes. Some dependence, on the other hand, is normal and fine. You are always going to invest time learning a tool, importing data, training staff. The question is never "is there any lock-in." It is "how expensive would leaving be, and who controls that price."
Lock-in gets dangerous when the switching cost is high and the vendor, not you, decides how high. That combination is what turns a supplier relationship into leverage against you. Your job before signing is to find where that leverage lives and defang it while you still have negotiating power, which is before the ink dries and never after.
What should you check before you sign?
Five checks determine most of what happens if you ever need to leave a vendor: data export rights, ownership of custom work, a real migration path, reliance on proprietary formats, and renewal pricing terms. Run through them with any vendor holding meaningful data or process for your business, and ask for the answers in writing.
1. Can you export all your data, in an open format, on demand?
Not a report. Not a PDF. Your actual data, complete, in a format another system can read, like CSV, JSON, or a standard database dump. Ask specifically: "If we leave, can we export every record ourselves, without paying you, at any time?" A vendor confident in their product says yes easily. A vendor who hesitates, charges an "export fee," or only offers a locked proprietary format is telling you something. Data you cannot take with you is data you do not really own.
2. Who owns custom development?
If you pay a vendor to build custom features, screens, or integrations, who owns that code? Read the contract, not the sales pitch. In too many agreements, you fund the work and the vendor keeps the intellectual property, which means you cannot take it elsewhere and they can resell it. If you are paying to build something specific to your business, the contract should say you own it or at least hold a perpetual license to use and move it.
3. What does migration actually take?
Ask the uncomfortable question directly: "If we decided to leave in year three, what would the process look like?" A reasonable vendor can describe it. Evasiveness here is the answer. Also ask yourself the honest version: how much of your process, your staff's habits, and your integrations are wrapped around this one tool. The deeper that goes, the more the vendor knows you cannot easily walk.
4. Are you standing on proprietary formats or open standards?
A vendor whose product speaks common standards, standard databases, standard APIs, standard file types, is a vendor you can leave. One that invents its own formats and its own way of doing everything is building walls, whether they intend to or not. Proprietary is not automatically bad, but it always raises the exit cost, so price that in.
5. What are the renewal and price-increase terms?
Lock-in gets monetized at renewal. If the contract lets the vendor raise prices freely once you are dependent, you have handed them a loaded position. Look for caps on annual increases and clear notice periods. The time to negotiate your renewal terms is in the first contract, while they are still trying to win you.
A short story about the invoice
A wholesale trader I know ran their whole operation on a bespoke system a local vendor had built. It worked. Then the vendor raised the annual maintenance fee sharply, and when the trader pushed back, the answer was essentially "find someone else who understands this system." Nobody could, because the vendor had never handed over documentation and the data sat in a structure only they understood. The trader paid the increase. That is vendor lock-in in one sentence: paying more not because the product got better, but because leaving got impossible.
Contrast that with a company that had insisted, in writing, on full data exports and owned source code from day one. When their vendor's price crept up, they got quotes from two others, showed them the exports, and used the credible threat of leaving to hold the price flat. Same situation, opposite outcome, decided entirely by clauses signed years earlier.
I have seen this exact split decide the outcome of a vendor negotiation: the company that had already exported its data walked in with leverage, and the company that hadn't paid whatever the vendor asked.
The practical takeaway
Vendor lock-in is not a reason to fear buying software. It is a reason to buy it deliberately. Before you sign anything that will hold your data or run your operations, get four things in writing: you can export all your data in an open format any time, you own or perpetually license any custom work, the vendor can describe a real exit path, and price increases are capped.
None of this is hostile to a good vendor. A confident partner agrees to all of it, because they plan to keep you by being good, not by making you stuck. The ones who resist are showing you exactly why you needed the insurance.
If you are evaluating a major vendor or platform decision and want a second set of eyes on where the lock-in hides, this is the kind of review I do as a technical partner. It also connects to a broader point I make often, that your business needs a real technology strategy, not just a website.
