01 Insights · Vendor lock-in
Vendor lock-in: how to spot it and how to undo it
A lock-in goes unnoticed for as long as the price is right. It becomes visible when the vendor changes the terms and nobody can say what a switch would cost. This piece sets out the forms of vendor lock-in, the warning signs, Broadcom and VMware as the object lesson, and the one criterion that can actually be tested: exit capability.
02 Summary
The short version
- Vendor lock-in is dependence on a supplier whose replacement would be so expensive technically, contractually or organisationally that a switch is effectively off the table.
- Lock-in is not a technology topic. It is a risk with an owner and an assessment, and it belongs in the risk register rather than in an architecture debate.
- Broadcom and VMware show how quickly a position that was stable for twenty years turns into a negotiation with an open outcome: no perpetual licences since November 2023, and price rises of 800 to 1,500 per cent on renewals according to CISPE.
- Open source does not remove lock-in by itself. It shifts the cost from the licence into operations, and an organisation that names no operational owner trades licence cost for maintenance debt.
- Independence can only be measured as exit capability: how long it would take and what it would cost to replace a core component. A paper exit test gives you more clarity in a few days than a debate about principles.
- Documented, reproducible configuration pays twice. It makes a switch possible and at the same time serves the NIS2 requirement on configuration documentation and recovery.
What vendor lock-in is and the forms it takes
Vendor lock-in describes a dependence that can no longer be undone without the switch costing more than staying put. What matters is not whether a supplier dominates its market, but whether it can change its terms unilaterally while the other side has nowhere to go.
In IT the effect appears in four forms, and they rarely arrive alone:
- Technical lock-in. Proprietary interfaces, vendor-specific formats and features with no equivalent elsewhere. Changing supplier in the virtualisation layer amounts in practice to a re-architecture.
- Contractual lock-in. Minimum terms, bundling and committed volumes. You pay for a scope you do not need, and the negotiation comes round again every three years.
- Data lock-in. Data sits in a format, or behind an interface, that only this supplier serves. With hyperscalers, egress charges are added on top, and they only become visible on the way out. This is the form most people mean when they say cloud lock-in.
- Knowledge lock-in. Operating processes only work with one vendor’s tooling. Changing the licence is cheap; changing the routines is the real investment.
The fourth form is the underrated one. It explains why organisations stay with a supplier whose pricing they have long considered unreasonable. It is not the software that holds them, it is the way they work with it.
A useful distinction sits underneath all four. Dependence is normal and unavoidable: every platform decision creates some. Lock-in is what you get when that dependence stops being priced, reviewed and owned by anyone.
How to spot a lock-in before the contract runs out
A lock-in does not announce itself. It shows up in no monitoring system and, in most organisations, in no risk register either: no assessment, no owner, no date. It becomes visible when the renewal comes round and the question about alternatives is asked seriously for the first time. By then the answer is part of the problem.
There are earlier warning signs. The cost of the coming contract period cannot be stated, because the other side sets the frame. For the three most critical components, nobody can say what a switch would cost in time and money. Operating processes are tied to one vendor’s tooling, and the configuration exists as a grown state on running systems rather than as code in a repository. The platform could not be rebuilt from the documentation.
Five questions for the next round in the leadership team
- Does supplier dependence appear in our risk register, with an owner and an assessment?
- What would it cost to replace our three most critical components, in weeks and in euros?
- Which of our operating processes only work with one particular vendor’s tooling?
- Could our platform be rebuilt from the documentation alone?
- When did we last test a switch in practice, even if only on paper?
If more than one of these cannot be answered with confidence, the organisation does not have a technology problem. It has an open position in the risk register.
Broadcom and VMware: the object lesson where all of it shows
No case in recent years explains vendor lock-in better. VMware was a stable position for twenty years: one licence, one price, one plan. The acquisition by Broadcom in November 2023 moved that. Perpetual licences are gone, and new agreements are three-year subscriptions in substance.
The consequences are documented rather than asserted. The European cloud association CISPE recorded price rises of 800 to 1,500 per cent on contract renewals and filed a competition complaint with the European Commission in March 2026. The German IT user association VOICE filed a complaint over abuse of market power on the back of the same licensing policy. Gartner expects around 70 per cent of VMware enterprise customers to move at least half their workloads by 2028.
Why the VMware price increase is the smaller story
The remarkable part is not the increase. The remarkable part is that it was possible. A component at the centre of the data centre had become so self-evident over the years that nobody was checking whether it could still be replaced. That is the mechanism in full: a supplier gains market power or is acquired, and a risk that had been carried quietly for years materialises all at once. Questions about VMware pricing and the VMware licensing price are the symptom; the missing alternative is the cause.
The second lesson is about waiting
The proceedings before the European Commission will bring no short-term relief. An organisation waiting for a regulatory answer gives up control of its own timetable and ends up negotiating with nothing in hand. One that has prepared a VMware alternative negotiates differently, even if it decides to stay.
Free whitepaper · 7 pages
Open Source for Operations
By Andreas Hankel, CTO onehundred. Download in exchange for your e-mail address, no sales call.
Proxmox vs VMware: what the open alternative actually covers
In classic virtualisation, the search for an alternative to VMware leads to KVM and Proxmox VE. KVM is part of the Linux kernel, so it is not one vendor’s add-on but a component of the operating system. Proxmox VE is the management layer on top of it.
What the platform brings
Proxmox VE provides clustering, high availability, live migration of running machines, role-based access and an integrated backup chain. Storage runs on Ceph or ZFS, and network segmentation is handled by Proxmox SDN. For backup there is a dedicated component, Proxmox Backup Server, with deduplication and incremental backups. An import wizard takes virtual machines out of existing ESXi environments.
Where translation is needed
Micro-segmentation from NSX cannot be carried over one to one; it is transferred conceptually. Older guest systems need the right drivers, and special cases such as GPU passthrough or hardware dongles belong in the stocktake, not in the first migration wave. That is the heart of the matter: this is not a lift and shift, it is a translation.
The licence model
Proxmox VE is fully open source. The software is not tied to a minimum core count and not coupled to a bundle; the subscription governs access to the enterprise repository and the support tier. So the question of Proxmox cost has a different character from the same question about a proprietary hypervisor: you are buying support, not the right to run the software.
None of this makes Proxmox the automatic answer. It makes it a real option, which is precisely what a negotiating position requires.
Open source in operations: where licences fall away and work appears
Virtualisation is only one of four layers in which dependence settles. The picture is complete only when you look at the whole operating stack.
- Monitoring and observability. Dashboards, alerting rules and data models are bound to the supplier in proprietary tools. Anyone looking for an open source alternative to a closed monitoring product should ask first whether the rules are portable, not whether the interface is pleasant.
- Automation and CI/CD. A closed platform with its own pipeline format builds migration debt with every new pipeline. With open tools, pipelines, playbooks and infrastructure as code sit as text artefacts in your own repository: versionable, auditable, portable.
- Virtualisation and containers. This is where the most expensive dependence sits, because a change touches the architecture.
- Databases. An organisation on standard protocols can change supplier without rewriting its applications.
The sentence that matters most here: open source shifts costs, it does not remove them. The licence goes away; version maintenance, security updates and on-call cover stay. In practice an open source adoption does not fail on the software, it fails on the absence of an operational owner. The project had a team, and afterwards operations run on the side. After the first year the version landscape has drifted apart, and liberation from lock-in has turned into maintenance debt.
So every component needs a named owner, and the business case has to carry operating and staff cost, not just the licence that was saved.
What a lock-in costs beyond the licence invoice
The licence invoice is the part everyone sees. It is not the expensive part.
Forced costs. Price rises, bundle changes and contracts cancelled at short notice can only be declined if an alternative exists. Without one they are not offers, they are invoices. The amount appears in no business case, because it only arises once the dependence is already there.
Negotiating position. An organisation that could migrate negotiates differently, including with the suppliers it intends to keep. This is the most underrated return on being able to switch: it pays even if you never do.
Predictability. Open projects publish their roadmap, and development is carried by a community rather than by one owner’s product strategy. What will hold in three years can be estimated. With a proprietary supplier the same question hangs on an acquisition nobody forecasts.
Reuse. An open toolchain carries across several initiatives. The monitoring for virtualisation is the monitoring for databases, and the automation built for one project carries the next. Operational knowledge turns into economies of scale instead of isolated solutions.
Extensibility. Open automation and database layers can be attached to new workloads, AI included. Closed platforms can do that too, but on the supplier’s terms and to the supplier’s timetable.
Against those five items sits one number that is easy to calculate and therefore tends to stand alone: the licence saved. An honest calculation puts next to it what open operations tie up in people, version maintenance and on-call cover. Only then can you see whether a replacement is worth it. In some cases it is not, and that result is just as useful.
Exit capability is the only criterion you can actually test
Independence as a self-description cannot be disproved. Every supplier writes it on its website. It becomes testable only as a question about exit capability: how long would it take and what would it cost to replace this component, and who last did that sum?
An exit test needs no project. It can be played through on paper and gives more clarity in a few days than a debate about the merits of open source. The practical advice: run it on the least important of your critical components. Nobody has to defend the outcome there, which is exactly why an honest one comes out.
The exercise produces a second criterion, this time for choosing a service provider. Do not ask whether they use open source. Ask what happens on the day after termination. Do the configurations sit with you as Git repositories, or in a portal you lose access to when the contract ends? Is the stack chosen so that another competent provider could take it over, or is there a home-grown orchestration layer only this supplier can operate? Is there a verifiable exit commitment in the contract, or only a statement of intent on a website?
The side benefit is substantial. Documented, reproducible configuration also serves the requirement in Article 21(2)(c) of the NIS2 directive on configuration documentation and recovery, which each member state transposes into national law; in Germany, for example, as Section 30(2) no. 3 of the BSI Act. An organisation that could switch can also recover.
How to unwind a dependence without walking into the next one
Replacing a platform is an architecture and organisation project, not a licensing exercise. In this order it works:
- Stocktake. A complete inventory of the workloads and their dependencies. Regularly the most laborious part, and the one nobody should skip. Along the way, the systems that only still run out of caution become visible.
- Assessment and target picture. What migrates without difficulty, where does adaptation effort arise, and what stays for now because the switch does not pay? A replacement that does not pay is not a replacement.
- Test environment. A pilot on the target platform, loaded and checked, while the existing estate keeps running untouched. Backup and recovery are tested here, not later.
- Migration in waves. By criticality, with a fallback path per service. Moving an entire data centre over one weekend is rarely sensible and has no way back.
- Operations. Monitoring, backup, access rights and recovery have to run as reliably on the new platform as they did before. Only then is the replacement finished.
A go/no-go decision belongs at every transition. That is the real protection: for as long as nothing in production has been moved, stepping out of the project remains possible. And the timing decides the negotiating position. An early, planned transition is cheaper and lower risk than a forced migration under cost pressure.
Five mistakes that make a replacement expensive
Treating the replacement as a licensing topic. The price comparison is quick, the operating routines are the real investment. Compare only the licence and you have failed to plan half the project.
Booking the licence saving as a pure saving. The operating and staff cost of the open toolchain has to be set against it. Otherwise you produce a number that does not survive the first year in production.
Starting without an operational owner. A project team introduces the platform, and afterwards operations run on the side. A year later the version landscape has drifted and security updates are a backlog rather than a routine.
Mistaking the move for the finish. The work shifts into operations with the last workload, without anyone having planned capacity there. The critical moment arrives months later, at the first serious incident.
Waiting for someone else to solve it. A pending competition case, a market rumour, the hope of a better offer at the next renewal: every one of these expectations pushes the date back, and the technical backlog grows with each month. More systems, more integrations, more habit.
The common thread: a lock-in is not created by a decision, it is created by the absence of decisions. It is undone the same way, one step at a time.
04 Solution · VMware replacement and open operations
When the dependence sits with VMware
We replace vSphere estates with Proxmox VE or KVM, service by service with a fallback path, and then run the platform 24/7 with on-call cover. Existing Proxmox clusters we take over while everything stays live. Your configurations sit with you as Git repositories: no lock-in, not even to us.
05 Read on
Further reading
Coming up
- VMware alternatives compared
- Broadcom and VMware licensing
- Proxmox vs VMware
- Proxmox licensing and cost
- Proxmox Backup Server
- Open source alternatives for operations
06 Frequently asked questions