Leaving VMware: decisions to make before choosing an alternative

Contractual, budgetary or strategic pressure is prompting many organisations to reassess their VMware platform. The natural reaction is to compare Hyper-V, Azure Local, Nutanix AHV, Proxmox VE or another platform. That is precisely where the reasoning can go wrong.

Following Broadcom’s acquisition of VMware, the issue extends beyond price increases. The portfolio has been consolidated around more integrated subscription offerings, including VMware Cloud Foundation and VMware vSphere Foundation. These are not the only commercial offerings, but available products, bundles and terms depend on the contractual context and may change. Regular changes to offerings and licensing mechanisms further complicate the visibility needed to manage infrastructure over several years.

These solutions do not cover the same scope. Some are primarily hypervisors or operating system capabilities; others are integrated platforms combining compute, storage, administration and hybrid services. Hyper-V, Azure Local, Nutanix AHV, Proxmox VE and VMware therefore cannot be compared line by line without first defining the expected service. Otherwise, the comparison produces misleading conclusions.

The decision is therefore not about selecting a product. It is about defining a target infrastructure service and a roadmap the organisation can sustain. Requirements must drive the technical roadmap. The product comes afterwards.

“Leaving VMware” is not a sufficiently precise objective. IT leaders may want to reduce spending, restore contractual predictability, reduce vendor dependence, address an end-of-support deadline, simplify operations or use a hardware refresh to transform infrastructure.

These motivations lead to different choices. If cost is the priority, rationalising the VMware footprint may be more effective than a full migration. If excessive dependence is the problem, replacing one vendor with a platform dependent on another ecosystem does not necessarily solve it. If support is the urgent issue, an upgrade may be essential before an exit can even begin.

Broadcom currently documents VCF and VVF licensing based on physical cores, with a minimum of sixteen cores per processor. General support for vSphere 7 ended on 2 October 2025. These are factual constraints. Whether to migrate remains a conclusion specific to each organisation.

The first decision must therefore be expressed in one measurable sentence: which risk or cost should be reduced, by when, and which service level must be preserved?

A virtual machine relies on more than a hypervisor. It depends on a chain of services: centralised administration, high availability, storage, networking, backup, restoration, disaster recovery, monitoring, capacity management, identity, security, automation, patching, support and operating procedures.

This mapping must start with actual usage. A licensed feature that is never used does not need to be rebuilt. Conversely, an unobtrusive automation or a restoration procedure understood by only two people may be critical without appearing in a commercial feature matrix.

Platforms illustrate these differences without requiring a ranking. Azure Local can support a hybrid management approach and now supports several architecture models, including some deployments using external SAN storage. These options remain subject to specific hardware, software and pricing requirements. Disconnected operations are a separate architecture with a local control plane and their own prerequisites. Nutanix Move facilitates some VMware migration scenarios, but its existence does not remove the need to check every guest operating system, network, storage arrangement and downtime window. Proxmox VE offers subscription support; actual operability also depends on third-party tool coverage and the chosen support arrangements.

The right criterion is not “compatible”. It is “compatible with our service level, architecture and ability to diagnose incidents”.

Removing a licence does not automatically produce a net saving. The calculation must distinguish four cost categories.

Backup illustrates the trap. Veeam supports recent Proxmox VE environments, but its documentation still lists limitations, including certain storage configurations, LXC containers and VM replication. This neither disqualifies Proxmox nor represents a minor detail: it calls for checking whether the required protection service can be reproduced, adapted or replaced.

Total cost must also include exit options. A migration can reduce immediate dependence while increasing the cost of the next exit. IT leaders must therefore cost both moving to the target and the ability to leave it.

A hundred-criterion matrix creates an illusion of objectivity. An option can achieve a good average score yet remain unusable because of one issue: an unsupported guest operating system, incompatible storage architecture, missing restoration capability, uncertified hardware, a network constraint, insufficient support or unavailable skills.

The right method starts with disqualifying criteria. These must cover critical workloads, backup and restoration, high availability, disaster recovery, security, storage, networking, support and connectivity constraints. Remaining options can then be assessed against preferences: simplicity, automation, administration experience or financial outlook.

The scenarios fall into four families of roadmaps.

• Retain and rationalise

  Risk

  Total cost

  Service continuity

  Keep VMware while reducing the subscribed scope, features or resources.

  Benefit

  Limits operational disruption and preserves existing skills.

  Risk

  Retains contractual dependence and potentially high costs.

• Full migration

  Risk

  Total cost

  Service continuity

  Aim for a single target, provided every dependency can be addressed.

  Benefit

  Simplifies architecture, operations and support over time.

  Risk

  Concentrates risk in a substantial and potentially irreversible migration programme.

• Phased migration

  Risk

  Total cost

  Service continuity

  Organise temporary coexistence with migration waves, responsibilities and exit criteria.

  Benefit

  Enables target testing and risk reduction before wider rollout.

  Risk

  Temporarily requires parallel operations, additional costs and strict governance.

• Long-term segmentation

  Risk

  Total cost

  Service continuity

  Assign different workload families to multiple platforms, with explicit scope and support models.

  Benefit

  Matches each platform to genuinely relevant workloads.

  Risk

  Permanently multiplies skills, tools, procedures and support contracts.

Total cost includes licensing, migration, coexistence, operations, skills, support and exit costs.

Each scenario needs a clearly named owner, a budget and decision criteria. Temporary coexistence also requires an exit date. Without explicit governance, a technical transition quickly becomes an unwanted permanent architecture.

Long-term segmentation may be rational. It can also create permanent duplication of skills, tools and procedures. Multiple hypervisors are not inherently a strategy: they become one only when each platform has a stable scope, a justification and a support model.

A pilot that boots a few VMs demonstrates limited technical feasibility. It does not demonstrate that the platform can be operated.

The test must cover a real cycle: migration, application validation, backup, restoration, monitoring, maintenance, node failure, diagnosis, support escalation and rollback. It must include representative workloads, including a difficult one, without replicating the entire estate. The teams that will operate the target must lead the test or, at minimum, participate directly.

The pilot must also provide decision evidence: operator time, incidents encountered, dependencies discovered, procedures requiring revision, missing skills and conditions for wider rollout. Without success and stop criteria defined beforehand, it becomes a technical demonstration biased towards the preferred solution.

The organisation should not make irreversible commitments before this test. Otherwise, it turns technical and human unknowns into financial obligations.

IT leaders do not need a universal platform ranking. They need a defensible decision suited to their estate, teams, risks and financial constraints.

Before approaching the market, they must assess the existing environment, define the service to rebuild, identify disqualifying criteria and cost several possible roadmaps. Without this work, a tender risks comparing solutions before the real requirements are settled.

The procurement process can then clarify architectures, support terms and costs. However, the organisation should not make irreversible commitments or roll out the selected solution broadly before testing operations across a representative scope.

A complete VMware exit is not always the most rational answer. Rationalised retention, phased migration or long-term segmentation can offer better roadmaps, provided they are explicitly governed.

The right alternative is not the one with the highest matrix score. It is the one the organisation can migrate to, operate, support and, tomorrow, leave under controlled conditions.