--- title: "Evaluating the alternatives to VMware without assuming migration wins" description: "What Broadcom changed commercially, what each candidate platform is genuinely good and bad at, and the dependencies that only surface during planning." url: "https://nixit.io/resources/vmware-broadcom-alternatives/" lang: "en" --- # Evaluating the alternatives to VMware without assuming migration wins Most organisations start this conversation from a renewal quote rather than from a technical problem, which is the wrong end of it. The quote tells you that the commercial terms changed. It does not tell you whether moving is cheaper once the work is priced, whether your applications remain supported afterwards, or whether your team can operate the result at three in the morning. Those are separate questions, and a migration decision that skips them tends to be revisited eighteen months later. ## The commercial model, not the product Nothing about the hypervisor got worse. What changed is how it is sold, and four changes compound. Perpetual licences were retired in favour of subscription. A licence you bought once, with support renewed at your discretion, became an entitlement that lapses when you stop paying. The financial effect matters, but the structural effect matters more: deferring a renewal through a difficult year is no longer available as a lever. Individual products were consolidated into larger suites. Buyers who used a narrow slice of the portfolio now purchase a bundle sized for organisations with much broader requirements. For an estate running vSphere and nothing else, this is usually the most visible component of the increase. Billing carries a minimum core commitment per processor. Hosts with modest core counts are charged as though they were larger, which makes the change regressive: it lands hardest on small clusters, and hardest of all on estates built from many small hosts rather than a few dense ones. The partner programme was rebuilt on invitation. Resellers who previously handled licensing and first-line support may no longer transact, so the commercial relationship and the escalation path can change independently of anything the customer decided. Deliberately, no figures appear above. The outcome depends on edition, host topology and negotiation, and quoted percentages from elsewhere rarely transfer. The mechanisms are the constant part. ## Candidate platforms, and where each one hurts **Proxmox VE** is the most common destination for small and mid-sized estates. KVM-based, clustered, with live migration, HA and replicated storage through Ceph or ZFS, and commercial support by subscription. The weaknesses are real rather than theoretical: a narrower third-party ecosystem, and troubleshooting that assumes genuine Linux competence. Teams whose operational muscle memory is entirely GUI-driven need time and training budget, not just a cluster. **Nutanix** is the integrated option, with its own hypervisor and distributed storage, and an operational model that feels familiar to people arriving from vSphere. It costs more than open platforms and it reintroduces single-vendor dependency, which for some organisations is precisely the exposure they set out to remove. **Hyper-V, optionally with Azure Stack HCI, now branded Azure Local**, fits organisations with existing Microsoft agreements and Windows-centric teams. Two caveats. Windows Server licensing has to be modelled separately and can absorb the saving. And the Azure-connected variants assume a billing and connectivity relationship with Azure that not every estate wants. **XCP-ng** is the Xen-based alternative, with commercial support available and its own management stack. Technically credible, with a smaller community than Proxmox and fewer ready-made integrations, which shows up when you go looking for a supported backup product or a monitoring integration. **OpenShift Virtualization and KubeVirt** put virtual machines under a Kubernetes control plane. This is a strong fit when Kubernetes is already in production and the goal is one platform for both containers and the VMs that will never be containerised. For an estate that is purely virtual machines, it adds a substantial operational layer that has to be justified by something other than the licensing question. **Staying on VMware** belongs on the shortlist as an option, not as a failure of nerve. Where the advanced feature set is genuinely in use, where critical applications are certified only there, or where the team has no capacity for a transition this year, the increase can still be the cheaper path. ## Support arrangements deserve more weight than they get The comparison people build is usually licence cost against licence cost. The line that determines how the platform feels in year three is support. Ask, for each candidate: who answers at two in the morning, under what response commitment, and in which language and time zone. Whether support is bought from the vendor or from an integrator, and what each covers. Whether the subscription is per host, per socket or per cluster, and how that scales as the estate grows. Whether firmware, storage and hypervisor issues can be escalated to one party or land you between three vendors pointing at each other. For multi-site estates the question extends further. Cross-site replication, orchestrated failover and centralised management across locations are areas where vSphere has mature, well-documented answers and where alternatives vary considerably. A platform that runs one cluster well is not automatically a platform that runs six sites well. ## Dependencies that surface during planning Migration planning is mostly discovery. The recurring findings: **DRS.** Automatic load balancing across hosts. Alternatives offer simpler versions or none, and where it is absent, balancing becomes a manual practice somebody has to own. **Live migration.** Every serious platform has it. Behaviour under large memory footprints, sustained load, or between hosts with different CPU generations varies, and the equivalent of enhanced compatibility modes is not identical anywhere. Test it, do not assume it. **Distributed switches.** Cluster-wide network configuration rebuilds as Linux bridges or Open vSwitch. VLAN trunks, link aggregation, MTU and any port mirroring get reconstructed by hand, per node. **Storage policies.** Declarative per-VM service classes have no direct equivalent on most alternatives. The same requirements become separate pools and explicit placement decisions. **Backup integration.** vSphere backup tooling relies on dedicated APIs and changed block tracking. Equivalents exist elsewhere in different forms and at different maturity levels, and several commercial products added support relatively recently. Establish what "supported" means for your specific product: full backups, efficient incrementals, application-aware quiescing and granular restore do not always arrive together. **Third-party tooling.** Monitoring platforms, DR orchestration, and vendor appliances shipped as pre-built virtual machines may declare support for vSphere only. Some work regardless, unsupported, which is a decision to take knowingly rather than discover afterwards. ## Vendor support statements for guests and applications Before any technical trial, collect the support positions. Microsoft's stance on Windows guests is anchored to its server virtualisation validation programme, and whether a specific platform and version appears there is something to verify rather than infer from the fact that it uses KVM. ERP and business application vendors typically certify a short list of hypervisors. At least one major database vendor has held a restrictive position on third-party virtualisation for many years, and that discussion is contractual rather than technical. "It works but is not certified" is an acceptable answer for an internal tool and an unacceptable one for the system the business runs on. ## Rebuild in place or build alongside Two shapes. Rebuilding in place recycles existing hosts as they are drained, needs no additional hardware, and narrows your options: once the first nodes are reinstalled, rollback is expensive. Building alongside requires spare or rented capacity and keeps the old environment intact until the new one is validated. Where budget allows, the second is materially safer. Conversion tooling handles the disks. The difficult part is the guest. Windows machines need drivers for the new storage controller installed before the switch, or they will not boot. VMware agents come out and platform equivalents go in. MAC addresses change, which affects DHCP reservations, address-based firewall rules and any application licence tied to hardware identity. Network cutover is planned separately: VLANs, aggregation and MTU must exist on the new hosts before the first workload moves. Testing runs on a pilot wave of non-critical systems, verified under real load rather than at boot. ## When staying is the honest answer Stay when the advanced features are genuinely in use, when critical applications are certified only on vSphere, when the estate spans sites in ways the alternatives handle awkwardly, or when the team has no capacity this year to do the work properly. A rushed migration costs more than the renewal it was meant to avoid, and it fails in ways that are harder to explain. The defensible position is a documented comparison over five years that prices the migration effort, the backup rework, the retraining and the rollback, with staying costed in the same units as moving. We run that assessment and the migration itself as part of [virtualisation and containers](/services/virtualization-containers/), and where the decision reaches beyond the hypervisor into storage, network and site topology it belongs to [infrastructure architecture](/services/infrastructure-architecture/).