Vendor Lock-In: A Beginners Guide

Vendor Lock-In, What Every ITAM Professional Needs to Know.

Your renewal is in three months. The supplier knows you cannot leave. That is vendor lock-in, and it is more common than most organisations want to admit.

ITAM professionals are uniquely positioned to see it coming. You sit across the contract, the asset data, the usage evidence, and the renewal calendar. The problem is that lock-in rarely gets documented as a risk until it is too late to act on it. By then, what should have been a straightforward procurement decision has grown into something that needs its own budget, resources, and timeline to shift to an alternative.

This guide gives you a framework to identify lock-in early, classify it, and manage it before it manages your budget for you.

What is Vendor Lock-in?

Lock-in exists when switching supplier stops being a procurement decision and starts requiring you to accept one of three things: losing important data or capability, paying significant exit costs, or rebuilding systems and processes from scratch.

Think about switching mobile provider and discovering your photos, purchased apps, and message history cannot come with you. The difficulty and complexity provide just enough friction to keep you staying put. Imagine the same friction in Enterprise IT, at scale.

Lock-in flavours:

• Reversible lock-in means you can leave with planning. Your data is exportable in a usable format, including history and audit trail. Integrations can be replicated with reasonable effort. The cost of leaving is mainly internal time, not contractual penalties. Switching is measured in months.
• Restrictive lock-in means you are effectively forced to stay. Complete exports are unavailable, prohibitively expensive, or slow. Contract terms make leaving commercially irrational. The product is embedded deeply enough that replacement carries real service risk. Switching is measured in years.

Most organisations have both types in their estate. The problem is they rarely know which vendors fall into which category until a renewal conversation forces the issue. This is typically next level ITAM, you are going beyond a compliance position and spend analysis and viewing the context of the vendor within the organisation.

A simple test: if you cannot describe how you would exit a vendor in a single page, including what you would lose, what it would cost, and how long it would take, you do not have enough information to negotiate confidently.

How Lock-in Happens: Deliberate, Accidental, or Mutual

Not all lock-in is engineered by the vendor. Understanding who created the dependency changes how you respond to it.

Deliberate lock-in is a commercial strategy. Vendors bundle products so that dropping one component collapses the discount across everything else, leaving you funding software you do not use to protect the price of software you cannot do without. After Broadcom acquired VMware, customers reported being pushed into larger, more expensive bundles with little room to negotiate. The EU’s investigation into Microsoft bundling Teams with Office 365 led to legally binding commitments around unbundling and data portability. These are not accidents.

Accidental lock-in is something organisations do to themselves. You buy an ITSM platform, then build two hundred workflows, integrations, and approval processes around it. Nobody planned to create a dependency. It grew one convenience decision at a time. Switching later is not a case of swapping the tool; it means rebuilding how the team works.

Mutual lock-in is a conscious trade. You standardise on one identity provider or one collaboration platform because managing five competing tools across the organisation costs more in time, risk, and support than accepting the dependency on one. That is a legitimate decision, provided it is documented, understood, and protected with the right contract terms.

The question worth asking for every significant vendor is a simple one: who created this dependency? If it is bundling, contract design, or access leverage, the vendor built it. If it is custom workflows, messy data, or fragile integrations, you built it. If it is a strategic platform choice with clear value, you chose it. Each answer points to a different response.

The Five Types of Lock-in

Most lock-in conversations get stuck at the contract level. In practice, dependency runs deeper than that. There are five types, and understanding which one you are dealing with determines what you can actually do about it.

1. Technical lock-in is where your systems only work properly because of the vendor’s specific technology. Your team has built automations, scripts, and integrations around tools and APIs unique to that platform. A replacement product might offer the same headline features, but not your workflows without a rebuild. The UK’s Competition and Markets Authority concluded in its cloud market investigation that incompatible data formats, proprietary tooling, and the difficulty of migrating workloads were significant barriers stopping customers from switching providers.
2. Data lock-in is where you can export your data but cannot take it with you in a usable state. Records come out as a flat file. The history, audit trail, approvals, attachments, and object relationships stay behind. What you get cannot be reconstructed meaningfully in the next system.
3. Commercial lock-in is where the contract makes leaving expensive even if the technology is replaceable. Multi-year commitments, auto-renewal windows, and bundle discounts that collapse if you reduce scope are the most common mechanisms. After Broadcom acquired VMware, customers across Europe reported price increases of between 800% and 1,500%, with existing contracts restructured and organisations pushed into mandatory three-year subscriptions with limited room to negotiate. Software audits are used as a switch deterrent, putting you on the back foot, defending a time consuming audit rather than exploring competitive alternatives. Similarly license metric complexity can be a form of lock-in. ULAs, processor-based licensing, named user definitions that shift depending on who you ask, these are not accidental. When you cannot state your own position with confidence, you cannot negotiate, and you certainly cannot leave. Organisations regularly stay with vendors they dislike because walking out would first require working out what they owe.
4. Operational lock-in is where your people and processes have been shaped around the vendor. Moving means retraining staff, rewriting runbooks, and changing how teams work day to day. The software is replaceable. The organisational change is not trivial. Munich spent fifteen years migrating 15,000 workstations away from Microsoft before voting to reverse the decision in 2017, at an estimated cost of up to €100 million. An Accenture report commissioned by the city found the primary problems were organisational, not technical.
5. Governance lock-in is where your compliance and audit model is built around the vendor’s ecosystem. Controls have been signed off, logs are relied upon as evidence, and security has pre-approved the supplier. A replacement means repeating that entire process. The Oracle and Rimini Street litigation, which ran for fifteen years before settling in July 2025, centred on the precise conditions under which third-party support could legally operate within Oracle’s licence terms. Organisations that had not properly documented their licence rights found themselves unable to demonstrate compliance. 

Most real lock-in is a combination of more than one type, but one usually dominates. Identifying which one gives you a much clearer picture of what you are actually trying to solve.

A Sixth Type: AI and Emerging SaaS Lock-in

AI tools are creating a new category of lock-in that most ITAM teams have not yet started to govern, and the pattern is moving quickly.

The dependency does not sit in the software licence in the way a traditional tool does. It sits in what your organisation builds on top of it. Teams develop prompt libraries, evaluation frameworks, and automated workflows around a specific model’s behaviour and outputs. Those artefacts are rarely documented, rarely portable, and rarely owned in any meaningful sense by the organisation rather than the platform.

Fine-tuning makes it worse. If you have trained a model on your own data within a vendor’s environment, that tuned model typically cannot leave. You can take your data. You cannot take the performance.

Cloud marketplace commitments add another layer. Channelling significant spend through AWS, Azure, or GCP draws down enterprise agreements that are themselves hard to exit, you can swap the SaaS tool and still be locked to the platform underneath it.

The ITAM question is a familiar one dressed in new clothes: what have we built, where does it live, and what do we lose if the vendor changes its terms, its pricing, or its model? The organisations that will manage this well are the ones that start asking those questions now, before the dependency is too deep to see clearly.

What lock-in costs you

Lock-in shows up gradually, in renewal uplifts you accept because the alternative is too disruptive, in shelfware you keep funding to protect a bundle discount, and in innovation projects that never get started because the budget is already committed.

The compounding effect is what makes it damaging. Every additional integration, workflow, and team dependency makes the eventual cost of switching larger. Organisations that delay acting on lock-in do not avoid the cost. They defer it and increase it.

The problem is particularly acute when organisations look to cut costs or drive efficiency. The instinct is to renegotiate or consolidate. But if significant spend is locked into multi-year agreements, that budget is already committed regardless of what the business needs now. The flexibility that a cost reduction programme requires simply does not exist. You cannot cut what you are contractually obliged to keep paying for.

The negotiating position weakens too. A vendor that knows you cannot credibly walk away has little commercial reason to sharpen its pricing or improve its terms. Renewal conversations become a formality rather than a negotiation. The result is that you pay more, year on year, for the same capability.

The clearest signal that lock-in is costing you is when a faster, cheaper, or more capable alternative loses out not because it is inferior, but because the cost and complexity of switching makes it impossible to justify. Newer entrants to the market, often more agile and competitively priced, are routinely blocked by the weight of existing dependency. The incumbent does not need to win on merit. It just needs switching to be hard enough that no one makes the case.

How to Counter Lock-in

• Before you buy, the question to ask is not just whether the product works but what it would take to leave. During the procurement and pilot stage, test the exit: ask the vendor to export a sample of your data and check whether it is usable, not just downloadable. This can be difficult to do during the excitement of new technology and a new vendor relationship forming, its akin to discussing a prenup before the wedding. Not romantic but incredibly practical.
• A vendor that can export records but not the history, audit trail, approvals, and object relationships attached to them is not giving you a real exit. Ask them to specify in writing what you can take with you, in what format, and within what timeframe. If they cannot answer clearly, that is information.
• During the contract, lock-in grows one convenience decision at a time. Every custom integration, bespoke workflow, and one-off configuration adds to the cost of leaving. Someone needs to maintain a live dependency register: what connects to what, who owns it, and what breaks if the vendor changes. ITAM is well placed to own that, but it requires cooperation from architecture, procurement, and the business teams building on top of the platform. Prefer configuration over custom code wherever possible. Custom code is what traps you.
• At renewal, lock-in is monetised. This is where the dependency you have allowed to grow becomes the vendor’s leverage. Gartner’s 2024 Magic Quadrant for SaaS Management Platforms found that 25% of provisioned licences go unused, with most organisations only aware of 40% of their SaaS applications. That unused spend is your starting point. Go into renewal with a clear picture of what you actually use, the cost of what you do not, and at least one credible alternative you have assessed. You do not need to be willing to switch. You need the vendor to believe you might.
• At exit, the organisations that manage this well are the ones that treated it as a planned transition rather than an emergency. When Broadcom restructured VMware’s licensing terms, the customers best placed to negotiate were those who already had documented transition requirements and could specify exactly what they needed: export timelines, support continuity, and parallel running periods. Negotiate transition assistance into the original contract.

How internal politics gets in the way

The practical guidance above is straightforward. The organisational reality is not. Most lock-in persists not because ITAM teams do not understand the problem, but because the people and politics around it make it hard to act on.

There are four patterns worth recognising.

1. The first is the champion: a senior stakeholder who has a relationship with the vendor, or who staked their reputation on the original platform decision, and who treats any lock-in conversation as a personal criticism.
2. The second is builder’s pride: the team that implemented the platform does not want to quantify the dependency cost because doing so means admitting that the implementation choices were expensive ones.
3. The third is the fear narrative: “switching will break everything” becomes a blanket veto that nobody has the appetite to challenge.
4. The fourth is the convenience coalition: users like the tool, operational teams do not want the retraining pain, and inertia becomes the default position.

The most effective way through this is to separate the facts from the decision. Run a short lock-in review, document what you find, and present it as risk information rather than a recommendation to switch. Most stakeholders will engage with a one-page summary of exit time, exit cost, and current contract exposure. Very few will engage with a proposal that feels like an attack on a decision they made.

The Enterprise IT Ecosystem Fighting Back

Lock-in is not a problem organisations have to solve alone. A number of commercial, regulatory, and market developments have shifted the balance, and ITAM teams that are aware of them are better placed to use them.

Third-party support is the most established lever. Organisations running stable on-premise products, whether ERP, database, or middleware, can move support away from the vendor and buy it elsewhere. The point is not simply to save money. It is to remove the “upgrade or lose support” pressure that vendors use to push customers onto new versions, new bundles, and new pricing models. The Oracle and Rimini Street litigation exists precisely because third-party support is a direct commercial threat to that model.

Interoperability layers reduce the cost of switching by stopping dependencies from becoming permanent. An integration platform sitting between your ITSM, HR, and procurement tools means that replacing one of them changes a connector, not an entire operating model. Standardising on identity protocols such as SAML, OIDC, and SCIM means user lifecycle management is not trapped inside a single SaaS suite.

FinOps and SaaS management give you the evidence base that makes renewal conversations credible. Lock-in thrives when you cannot demonstrate what you actually use. Usage data, cost per active user, and a clear picture of shelfware give you a legitimate basis to reduce scope, unbundle, or walk away from part of a contract. Without that data, the vendor’s position is stronger than it needs to be.

Regulation is moving in the same direction. The EU’s Right to Repair Directive, in force from July 2026, and the CMA’s cloud market investigation findings both reflect a direction of travel that supports portability, interoperability, and customer exit rights. These are not yet procurement guarantees, but they are increasingly useful reference points in contract negotiations.

Managing Lock-in as a Governance Routine

Not all lock-in is a problem to solve. Some of it is a decision to manage.

Standardising on a single identity provider, a single endpoint management platform, or a single cloud provider can be the right call. Fragmentation has its own costs: more vendors to manage, more integrations to maintain, more contracts to negotiate, more risk to govern. The goal is not to avoid dependency. It is to avoid dependency that is unpriced, undocumented, and unmanaged.
That distinction matters because it changes what ITAM is trying to do. The job is not to build a case for switching vendors. It is to make sure that when a renewal comes around, or when a vendor changes its terms, or when the business wants to cut costs, you have the information to make a clear-eyed decision rather than an enforced one.

The practical starting point is a lock-in review for your top vendors by spend and criticality. For each one, three questions: how long would it take to exit, what would it cost, and what would you lose. If you cannot answer those questions today, that is the gap to close. Document it, score it, and present it. Lock-in is a financial and operational risk. It belongs in the same conversation as any other.

Wrap-up

Vendor lock-in is not going away. The shift to SaaS, cloud, and AI is creating new dependencies faster than most organisations are tracking them, and vendors know it.

The ITAM function has the data, the contracts, and the renewal calendar. What it often lacks is a seat in the room before the decision is made, not after, when the dependency is already built and the contract is already signed.

Start with your top ten vendors by spend. For each one, work out how long it would take to exit, what it would cost, and what you would lose. Most ITAM teams find they can answer that question for two or three of them. The rest is where the work is.

Have you mapped your top vendors for lock-in risk? What did you find, and which types proved hardest to manage? Please share your experience in the comments below.