What is vendor lock-in?

Vendor lock-in is when switching away from a vendor costs so much — in money, engineering time, or business disruption — that you stay with them even if a better option exists. It builds up through proprietary formats, contract terms, and day-to-day dependencies that make leaving slow or expensive. The risk is concrete: a locked-in customer has little leverage if a vendor raises prices, lets quality slip, or changes its terms. Most of it is avoidable with decisions made before signing, not after.

‍

Vendor lock-ins can be reversible or reversible. Reversible lock-in is where data is exportable and switching is measured in months, and restrictive lock-in is where exports are incomplete or prohibitively expensive and switching is measured in years. Most organizations carry both types across their vendor list without having sorted out which is which.

The five (and a half) ways vendor lock-in happens

Lock-in rarely comes from one decision, it accumulates. ITAM Review's taxonomy breaks it into five distinct types, each requiring a different response:

‍

• Technical lock-in when systems, scripts, and integrations are built around a vendor's specific APIs or architecture that a competing product can't run without a rebuild. The UK Competition and Markets Authority's cloud market investigation found incompatible data formats and proprietary tooling to be a significant barrier stopping customers from switching cloud providers. 
• Data lock-in when youcan export your records, but not in a usable state. History, audit trails, approvals, and object relationships often stay behind, so what comes out can't be reconstructed meaningfully elsewhere.
• Commercial lock-in when the contract, not the technology, makes leaving expensive: multi-year commitments, auto-renewal windows, and bundle discounts that collapse if you reduce scope. 
• Operational lock-in when people and processes are shaped around a vendor, so switching means retraining staff and rewriting how teams work, independent of whether the software itself is replaceable. Munich's attempt to move roughly 15,000 workstations off Microsoft took fifteen years and an estimated cost of up to €100 million] before the city voted to reverse the decision in 2017.
• Governance lock-in when compliance and audit processes are built around a vendor's ecosystem, where a switch means re-doing sign-offs and evidence trails, not just swapping software. The Oracle and Rimini Street litigation, which ran for fifteen years before settling in July 2025, centered on exactly this: the legal terms under which third-party support could operate within Oracle's licensing.

‍

On the cloud side specifically, Zesty's breakdown points to the same pattern playing out through named, everyday mechanisms: proprietary services like Amazon S3, Azure Cosmos DB, and Google BigQuery that don't have direct equivalents elsewhere; data egress fees charged specifically for moving data out of a cloud environment; and reserved-instance or enterprise-agreement discounts that carry financial penalties for early termination.

‍

The taxonomy above is a solid map of how lock-in gets classified after the fact, but in our experience scoping build-vs-buy decisions for clients, the more useful question is earlier and simpler: who decided this, and were they weighing the exit cost at the time? Most of the lock-in we see forming isn't dramatic. It's a team picking the fastest path to ship, adopting a vendor's SDK or fine-tuning pipeline because it works today, without anyone owning the question of what it costs to leave later. That's functionally the same outcome as ITAM Review's "accidental" lock-in, but it happens faster with AI tooling specifically, because the switching cost (a prompt library, an evaluation harness, a fine-tuned model) can be built up in weeks rather than the years it takes to entrench an ERP system. 

‍

What are the risks and real costs of vendor lock-in?

‍

Some of the risks associated with vendor lock-ins are:

‍

• Reduced bargaining power. Once a vendor knows switching isn't realistic, they have little incentive to hold pricing or improve the product.
• Costs that compound the longer you wait. Every additional integration built on a vendor increases the eventual cost of leaving. Delaying action doesn't avoid the cost, it defers and grows it.
• Price shocks after a change of control. VMware’s acquisition price increases of 800–1,500% once existing contracts were restructured.
• Operational costs that dwarf the software cost. Munich's attempt to move roughly 15,000 workstations off Microsoft ran fifteen years and cost an estimated €100 million before being reversed which is a reminder that the software itself is rarely the expensive part to replace.
• Sudden vendor decisions you don't control. myITforum documents cases of companies building entire infrastructure around a niche cloud service, only for the vendor to sunset it and force a rushed, costly migration.
• Exit fees that only appear when you try to leave. Data-egress fees run into the hundreds of thousands of dollars for companies attempting to move to a cheaper provider, a cost that's invisible until the migration is already underway.
• Unmanaged sprawl that hides the scale of the problem. Gartner's 2024 Magic Quadrant for SaaS Management Platforms found that 25% of provisioned software licenses go unused, and most organizations are only aware of about 40% of the SaaS running inside their own business, both symptoms of vendor relationships nobody is actively managing.

‍

Is vendor lock-in always a bad thing?

‍

Not automatically. AWS's prescriptive guidance makes the case directly: "adopting Kubernetes could be perceived as a potential lock-in to an ecosystem but actually creates rapid business value by standardizing deployments." ITAM Review's framework backs this with a category of its own: Mutual lock-in, where an organization consciously standardizes on one identity provider or collaboration platform because managing several competing tools costs more in time and risk than accepting the dependency. That's a legitimate tradeoff, provided it's a documented decision rather than something that happened by accident.

‍

The practical filter is that almost every vendor relationship creates some lock-in. The real question is whether it's proportional to the value received, and whether a workable exit exists if you needed one.

‍

Vendor lock-in in AI tools and platforms

‍

AI is producing what ITAM Review calls a sixth category of vendor lock-in, and most organizations aren't tracking it yet. The dependency doesn't sit in a software license the way it traditionally has. It sits in what a team builds on top of the platform: prompt libraries, evaluation frameworks, and automated workflows tuned to one model's specific behavior, none of which are typically documented or portable. Fine-tuning compounds it as a model trained on your own data inside a vendor's environment usually can't leave with you (you can take your data back out, but not the performance you built on it). Cloud marketplace spend adds another layer on top: routing significant budget through AWS, Azure, or GCP to draw down an enterprise agreement means you can swap the AI tool itself and still be locked into the infrastructure underneath it.

‍

This tracks with how HatchWorks's build-vs-buy framework for AI treats the issue: vendor lock-in is one of ten scored dimensions in its enterprise decision framework, evaluated alongside cost predictability and integration complexity rather than treated as an afterthought. Teams that own more of their AI system, instead of building entirely inside one vendor's proprietary tooling, keep the option to swap model providers, self-host, or change orchestration approaches as the technology moves. That's a structural way to manage AI-specific lock-in, independent of which vendor is being evaluated at any given moment.

‍

Note: independent, benchmarked data on AI-specific switching costs isn't well established yet the above reflects current patterns in how AI systems get built and documented, not a cited industry statistic.

‍

How to avoid or reduce vendor lock-in?

‍

The ways to reduce vendor lock-in includes:

‍

• Test the exit before you sign. Ask a vendor to export a sample of your data during the pilot stage and check whether it's actually usable, not just downloadable and to get in writing what you can take with you, in what format, and on what timeline.
• Design for portability from day one. Build on standard APIs and data formats (generic SQL, REST) rather than proprietary ones, and abstracting vendor-specific functionality behind an internal interface layer so a future switch means updating one internal API instead of every application that touches it.
• Favor open standards and open-source components where the tradeoff is close. Modular, interoperable systems and open-source tooling are structurally harder to get locked into, since no single vendor controls the roadmap.
• Use containerization for workload portability. Docker and Kubernetes are ways to keep the same workload deployable across AWS, Azure, Google Cloud, or on-prem without a rewrite.
• Negotiate contract terms, not just price. Push for shorter terms, defined exit clauses, and transition assistance written into the original contract, not negotiated for the first time at renewal when leverage is weaker.
• Build infrastructure as code. AWS ties this directly to lock-in prevention: treating infrastructure like software (Terraform, AWS CDK, Pulumi) shifts an organization from long-term procurement toward rapid testing and replacement.
• Keep a live dependency register. Track what connects to what, who owns each integration, and what breaks if a given vendor changes — because lock-in typically grows one convenience decision at a time, not in one big commitment.

‍

All of the above are real mitigations, but they're mitigations for a dependency that's already been created. Based on how we build systems, as a client-owned code and infrastructure rather than inside our own proprietary platform, the highest-leverage decision is made earlier than any contract clause: deciding upfront who owns the code, the data, and the model artifacts a system produces. A shorter contract term or a clean export clause helps you leave a vendor faster; owning the system in the first place means there's less to leave.

‍

A vendor lock-in checklist before you sign

‍

You can follow the checklist below before you sign with your next vendor: 

‍

• Can you describe, in one page, how you'd exit this vendor: what you'd lose, what it would cost, and how long it would take?
• Can you export all of your data — including history, audit trail, and relationships between records — without the vendor's help?
• Does the contract include a defined exit clause, a maximum notice period, and transition assistance?
• Are you relying on any proprietary format, API, or protocol with no viable substitute?
• Have you actually tested an export and a partial migration, or are you taking the vendor's claims at face value?
• If this vendor doubled its price next year, or sunset the specific feature you depend on, what's the real recovery plan?

‍

‍