What Is Vendor Lock-In?

Somewhere in every large company is a contract nobody wants to open, a runtime only one person understands, and a data export that has never been tested because everyone is afraid of what it would prove. These are not separate problems. They are the same problem wearing four faces, and the name for it is vendor lock-in: the accumulated cost of leaving something your business has come to depend on.

This series is about that cost and its close relative, the maintenance bill it produces. Lock-in and maintenance are usually discussed apart — one a procurement concern, the other an engineering line item — but they are two readings of a single condition. A system you cannot leave is a system you must keep paying to maintain, on terms you no longer set. This first part defines lock-in precisely, because most arguments about it are really arguments about which face you are looking at.

Lock-in is a switching cost, not a feeling

The instinct is to describe lock-in as being “stuck” or “trapped” — emotional words that resist measurement. The precise definition is colder and more useful: lock-in is the switching cost a dependency imposes. It is the sum of everything you would have to spend — in money, time, risk, and disruption — to move off it.

That reframing matters because switching cost is a number, not a mood. Every vendor relationship has one, from near-zero for a commodity service you could replace in an afternoon to near-prohibitive for the platform your entire order flow runs through. Lock-in is not binary. It is a spectrum measured in how hard, how risky, and how expensive leaving would be — and the whole point of a vendor’s incentives is to push that number up over time while you are not watching.

Read this way, the question is never “are we locked in?” — you always are, somewhere. The question is “how high is the switching cost, is it still worth what it buys, and could we pay it if we had to?” A switching cost you have measured is a business decision. A switching cost you have never measured is a liability sitting on the books at zero.

The four dimensions

Lock-in is not one thing. It accumulates along four distinct dimensions, and an aging system usually carries all four at once.

• Contractual lock-in is the visible kind — software licenses, support contracts, and proprietary middleware whose terms you no longer control. It is the easiest to see because it arrives as an invoice, and the subject of Part 2.
• Platform lock-in is architectural. A system written to one environment’s proprietary services, assumptions, and APIs runs nowhere else without substantial rework. The application is not portable; it is welded to its substrate.
• Skills lock-in is human. When a technology depends on a skill the market is abandoning, the supply of people who can maintain it shrinks, their cost rises, and the knowledge concentrates in fewer heads. The dependency is not on a vendor at all — it is on a labor pool that is retiring.
• Data lock-in is the quietest and often the deepest. Information held in proprietary formats, undocumented schemas, or a database whose export path has never been exercised is information you do not fully own, however much you paid for it.

Dimension	What you depend on	How leaving hurts
Contractual	Licenses, support, middleware	Renegotiation, replacement, broken integrations
Platform	A specific runtime environment	Re-architecting an application welded to its substrate
Skills	A shrinking pool of specialists	Knowledge concentrates, then walks out the door
Data	Proprietary formats and schemas	Migration risk, lost fidelity, untested exports

The reason lock-in is so hard to manage is that these dimensions reinforce each other. A platform that runs only one place is maintained by people who know only that platform, storing data in that platform’s proprietary format, under that platform’s licensing terms. Each dimension raises the switching cost of the others. They do not add — they compound.

How lock-in accumulates

No one decides to be locked in. Lock-in is the byproduct of a hundred reasonable choices, each correct on the day it was made. You adopt a vendor’s proprietary feature because it solves a real problem faster than the portable alternative. You let an integration reach into internal data structures because the deadline was real. You stop hiring for the open-standards skill because the team you have already knows the proprietary one. None of these is a mistake. Their cost arrives later, as a switching cost that has quietly climbed past the point where leaving is feasible.

This is why lock-in and technical debt are siblings. Both are the deferred cost of expedient choices; both compound silently; both stay invisible because they never appear as a line item. The difference is in the denomination. Technical debt is denominated in code — the rework you owe. Lock-in is denominated in dependence — the freedom you have traded away. A system deep in both is what the industry calls a legacy system: not old for its own sake, but expensive to change and costly to leave.

Why lock-in becomes a maintenance problem

The through-line of this series is that lock-in does not stay a procurement issue. It becomes the maintenance bill. Here is the mechanism.

When the switching cost is high, you keep the system. Keeping the system means maintaining it. And because you cannot credibly leave, you maintain it on the vendor’s terms and the labor market’s terms, not your own. Price increases are absorbed because the alternative — migrating off — costs more. End-of-life notices become emergencies because there is no portable path off the platform. Specialist rates climb because the people are scarce and you have no room to negotiate. The maintenance bill is not separate from the lock-in; it is the lock-in being collected, year after year, in installments.

That is the reversal worth holding onto: lock-in is not the price of staying — it is the bill for not being able to leave. The rest of this series follows that bill across its four dimensions, prices the maintenance it produces, and lays out how to lower the switching cost without betting the business on a single cutover.

When lock-in isn’t the problem

Lock-in has a bad name it does not entirely deserve. Some of it is the reasonable price of a good decision. Standardizing on one platform buys integration, coherent support, and a team that knows one thing deeply instead of five things shallowly. For a stable system under no pressure — supported runtime, available skills, fair terms — a high switching cost can sit there harmlessly for years, and tearing it out to “avoid lock-in” would be a costly answer to a question nobody is asking.

So the first move is not to hunt for lock-in everywhere and panic. It is to find where the switching cost is high and climbing and attached to a system the business needs to change. That intersection is where lock-in turns from a fair trade into a liability. Everywhere else, naming it is enough. The discipline this series argues for is not zero lock-in, which is neither possible nor desirable — it is priced lock-in, chosen deliberately and affordable to leave.

Where this leads

We have defined lock-in as a switching cost and named its four dimensions. The natural place to start is the dimension you can already see, because it shows up on a bill. Part 2, Proprietary Middleware & Licensing Traps, examines contractual lock-in — the licensing models, proprietary middleware, and support terms that turn a system you bought into a system you rent, and the specific traps that make mainframe and middleware licensing so hard to escape.