Vendor Lock-In: What It Actually Costs You

94% of IT leaders say they're worried about vendor lock-in. Almost none of them can put a number on what it's actually costing them. Here's how to think about that number — and four real cases where it was catastrophic, not hypothetical.

What vendor lock-in actually is

"Vendor lock-in" gets used loosely, but it's really four separate mechanisms, and they don't all carry the same risk:

• Contractual lock-in — a term commitment with an early-termination penalty or an auto-renewal clause you'd have to actively cancel.
• Data lock-in — your data lives in a format or system you can't easily export or reuse elsewhere.
• Integration lock-in — other tools in your stack are built to depend on this one, so removing it breaks more than the one workflow.
• Infrastructure lock-in — the product literally cannot function without this specific vendor's servers, with no offline mode or independent fallback.

Most discussions of lock-in focus on the first — the contract you signed. The other three are often the more expensive ones, and they're rarely written down anywhere you'd think to check before you're already dependent.

How worried companies actually are

Parallels' 2026 State of Cloud Computing survey, based on 540 IT professionals across the US, UK, and Germany, found that 94% of organizations are concerned about vendor lock-in — with uncertain product roadmaps (46%) and fears about future support (57%) cited as growing factors in platform decisions. A separate Zapier survey of 542 US enterprise decision-makers, conducted in early 2026, found that 81% of AI users are at least somewhat concerned about dependency on a specific AI vendor, and nearly three-quarters said losing their primary AI vendor would disrupt day-to-day operations or leave them unable to function.

What's notable across both surveys isn't just the level of concern — it's the gap between concern and action. Roughly half of enterprises now have a dedicated internal team evaluating vendor dependency, and just over a third maintain contingency plans. That means a meaningful share of organizations that say they're worried about lock-in haven't actually priced out what it would cost them if their concern turned out to be justified.

Four real cases where lock-in became catastrophic

Enterprise vendor lock-in tends to play out slowly and quietly — a renewal negotiated from a weak position, a migration that keeps getting deprioritized. Our own case library documents a more extreme, faster version of the exact same mechanism, in consumer AI products, where the failure became visible almost immediately instead of playing out over years:

• CarynAI — infrastructure lock-in taken to its limit. The product had zero technical independence from a single small vendor, Forever Voices. When that vendor's sole founder was arrested, the product didn't degrade — it simply ceased to exist, for every user, with no warning.
• Moxie — the same mechanism in hardware. A $799 physical device with no offline mode, entirely dependent on its maker's cloud servers. When the company's funding fell through, the hardware in customers' homes went silent permanently.
• Soulmate — data and continuity lock-in via ownership change. A routine acquisition led to a full shutdown roughly eleven weeks later, and users' ability to preserve anything depended entirely on whatever export options existed at that moment, which most had never checked.
• Chai AI — a different flavor: platform-distribution lock-in. Not a technical dependency on one server, but a business dependency on Apple's and Google's app-store approval, which the company doesn't control and which can change without notice.

None of these are B2B SaaS tools, but the mechanism in each is identical to what a 74% figure in an enterprise survey is actually describing in the abstract. These cases just show what it looks like when the dependency is total and the failure arrives all at once, instead of gradually.

How to measure your own lock-in exposure

1. Check your actual data-export options — not what the marketing page claims, but what format you'd actually receive, and whether it's usable in a competing tool without significant rework.
2. Map integration dependencies — list everything else in your stack that talks to this tool, and estimate what breaks if it disappears.
3. Read the termination and auto-renewal clauses in your actual contract, not the general terms of service.
4. Ask directly whether the product has any offline or vendor-independent fallback — for AI tools especially, this is often simply "no," and it's rarely disclosed unless asked.
5. Price out a forced, unplanned switch using a realistic worst-case timeline — days, not months — rather than only pricing a planned, negotiated one.

The same mechanism in AI vendor relationships specifically

If the tool in question is an AI product or an LLM integration, the lock-in mechanism above gets an extra layer. Prompts tuned to one model's behavior, fine-tunes that live inside a provider's environment, and embeddings tied to a single vector space are all forms of lock-in that don't show up in a contract at all. See our breakdown of what actually breaks when switching AI vendors for that layer specifically.

Reducing lock-in without switching yet

You don't have to be mid-decision to reduce exposure. Negotiating explicit data-export rights into a renewal, avoiding auto-renewal clauses where possible, and — increasingly common for AI tools specifically — maintaining a secondary vendor relationship even if it's lightly used, are all lower-cost ways to avoid discovering your actual lock-in level at the worst possible moment. Roughly 44% of enterprises in the Zapier survey already run multiple AI vendors simultaneously for exactly this reason.

Bottom line

Vendor lock-in isn't a single number until you calculate it, and most organizations that say they're worried about it haven't. The honest version of that calculation looks like our hidden-costs framework run in reverse: not "what would switching cost," but "what would being forced to switch, with no notice, actually cost." Our own case library shows what that number looks like when it stops being hypothetical.