Vendor lock-in has become a hot topic since Broadcom. Some teams talk about it with a sense of principled urgency, as if depending on a vendor were inherently a governance failure. It's not that simple.
Every infrastructure depends on something: a hypervisor, an OS, a network protocol, a backup solution. Zero lock-in is an illusion. The real question is: what do you depend on, to what degree, and what does changing cost?
Understanding your real dependency before wanting to reduce it
The first step isn't a migration plan. It's an honest inventory.
VMware dependency is not uniform. An environment limited to vSphere, external NFS storage and Linux VMs has relatively contained dependency: the hypervisor can evolve without a major application or network redesign.
An environment using NSX for microsegmentation, vSAN for distributed storage, Aria for automation and custom PowerCLI scripts has deeper dependency and a higher exit cost.
The inventory covers:
- "Pure" hypervisor dependencies (VMs running on vSphere)
- Network dependencies (NSX, vDS, custom port groups)
- Storage dependencies (vSAN, VMDK-linked processes)
- Tooling dependencies (scripts, APIs, ITSM/monitoring integrations)
- Human dependencies (certifications, reflexes, internal documentation)
Progressive reduction: by component, not by revolution
The best lock-in reduction trajectory isn't "migrate everything now." It's reducing dependency component by component, starting with the least risky migrations where the gain is measurable.
Typical priority order in a mixed environment:
1. New workloads first on the target: do not deploy new VMs on VMware if the goal is exit. Every new VMware VM becomes another VM to migrate.
2. Non-critical workloads first: development, test and staging refine the procedure before critical production is engaged.
3. Tools and scripts: replace PowerCLI scripts with equivalent solutions on the target. This can progress alongside migration waves and reduce dependency before the final VM batch.
4. Critical production last: engage these workloads with validated rollback, defined GO/NO-GO criteria and an organisation able to absorb the operation.
What you can preserve from VMware during the transition
Just because you're reducing VMware dependency doesn't mean you need to migrate everything simultaneously.
Keeping some VMware components temporarily can be rational:
- vCenter as a hybrid management interface during coexistence
- Application components deeply integrated with NSX, until the network redesign is planned and separately budgeted
- Some critical workloads where migration timing cannot be constrained by the overall program pace
Coexistence is a deliberate architectural posture: transformations take time, and production must not be endangered in the name of architectural consistency.
Change governance: the forgotten dimension
Lock-in reduction is a transformation program. It needs a clear sponsor, a calendar, dedicated resources, and a decision process for exceptions.
Without formal governance, lock-in naturally reconstitutes itself. Teams revert to familiar tools. New workloads are deployed on the platform they know. Architectural debt accumulates.
What must be formalized:
- The target platform by workload type, documented and validated by IT leadership
- The exception process, including the constraints that permit a deviation
- Programme completion criteria, defining the acceptable residual dependency
Mistakes to avoid
Confusing lock-in reduction with cost reduction. The two can coincide, but they are not the same objective. A VMware → Proxmox migration can reduce vendor dependency while costing more in year one once coexistence, training and residual incidents are included.
Migrating without maintaining rollback capability. Reducing VMware lock-in while removing any route back creates uncontrolled risk.
Forgetting human dependency. Replacing VMware with Proxmox changes the lock-in profile, not its nature. If all Proxmox expertise rests on one engineer, dependency shifts from a vendor to a person.
What it looks like when done well
The organization that has managed its lock-in reduction well doesn't miss maintenance windows waiting for an architecture decision. It operates its platform with its own tools, its own tested procedures, and a team that understands what it operates.
It can also evaluate a future proposal on its technical and economic merits without being forced to stay or leave for uncontrolled reasons.
That's what sovereign architecture looks like.