The market is shrinking its VMware footprint, not leaving
CloudBolt's survey is the starting point. It covered 302 IT decision-makers at director level or higher, at North American companies with 1,000+ employees. Data was collected in January 2026. 88% were concerned about future price increases, and 86% said they were actively reducing their VMware footprint.
The headline needs context. Only 4% said they had fully migrated away. 54% said they were staying with VMware while actively reducing dependence, which points to phased, partial transitions. That matches Spiceworks' framing: most shops want room to maneuver, not an overnight departure.
Two caveats apply:
- The sponsor sells related products. Ars Technica noted that CloudBolt is a hybrid cloud management provider that aims to identify VMware customers' pain points so it can sell them relevant solutions. Treat the numbers as a snapshot of respondents, not of every VMware customer.
- Destination figures are not shares of VMs. Among migrated workloads, 72% of respondents moved to public cloud IaaS, followed by Microsoft's Hyper-V/Azure stack at 43%. These are respondent selections. The VMblog write-up of the release gives a different Hyper-V/Azure Stack figure of 38%, plus 34% for SaaS replacements. Quote these numbers cautiously.
The survey also shows that price shock was more modest than many feared. Only 5% reported cost increases of 100% or more, while 57% reported hikes above 25%. Ars reported a slightly different split for the top bracket, so the exact bands vary by write-up. The renewal worry is about the next quote, not only the last one.
Start with the workloads, not the replacement
The article's central idea is to replace "What replaces VMware?" with "Where should each workload go?" A typical estate has legacy Windows applications, Linux servers, VDI, strictly supported databases, dev systems and branch infrastructure. Each can land somewhere different:
- Stay on VMware where the migration risk outweighs the expected savings.
- Move to another hypervisor with a planned outage, testing and cleanup.
- Go to public cloud, SaaS or the bin.
CloudBolt's respondents point the same way. One described unwinding a decade of process dependencies as taking 18-24 months. Ars reported that multi-platform complexity (52%) and skills gaps (33%) topped the list of migration challenges. More platforms means more operational models to run.
Inventory first, and count cores
The first practical step is an inventory. The Spiceworks article lists hosts, physical cores, clusters and storage. It also lists powered-off VMs, abandoned templates, and dependencies on vSAN, NSX, Horizon, backup, DR, monitoring and automation.
Core counts matter because of how Broadcom licenses. Broadcom's knowledge base says VCF and VVF core licensing is based on the total number of physical CPU cores across all ESXi hosts you intend to license. The minimum is the part that catches people. The KB's own example is a host with one 8-core CPU: customers must still buy 16 cores for that CPU, so three such hosts need 48 cores. Two more details from the KB:
- vSAN is licensed separately by capacity. It is counted in TiB of raw physical storage, not by what the vSAN Capacity Overview shows. The KB says manual calculation from the UI is not recommended or accurate.
- A PowerCLI tool exists for vCenter-managed estates. The KB describes a License Counting PowerCLI tool that needs PowerCLI 13.3 or later. It warns that results can be inaccurate if physical cores are disabled in the BIOS.
This is a licensing rule to check against your own products and contract, not a quote. But a VM count alone will not give you a defensible renewal model, or a fair comparison with an alternative.
The alternatives, and where their documentation draws lines
Nutanix AHV
Spiceworks calls AHV an established commercial option that is part of Nutanix Cloud Infrastructure and managed through Prism. Nutanix Move handles ESXi migrations. The tooling reduces some plumbing. It does not settle application support, networking, backup, DR or the cost of the full stack. You swap one dependency for another, so choose it deliberately.
Azure Local
For Microsoft-centric teams, Azure Local is the natural candidate. Microsoft describes it as full-stack infrastructure software running on validated hardware in your own facilities, running VMs, containers and select Azure services with management through Azure Arc. The FAQ adds practical constraints:
- Billing. Azure Local software is billed as a cloud service on your Azure subscription, based on the number of physical cores deployed.
- Hardware reuse. Existing hardware can be reused only if it matches a supported configuration in the catalog. Otherwise it needs upgrades or replacement.
- Connectivity. Hyperconverged deployments must sync with Azure at least once every 30 consecutive days. After that the cluster shows "Out of policy" and enters reduced functionality. Existing VMs keep running, but new VMs can't be created until it syncs again.
Microsoft's Azure Migrate path for VMware VMs applies to Azure Local 2503 and later. It uses a source appliance on VMware and a target appliance on Azure Local. The documented phases are prepare, discover, replicate, then migrate and verify. Microsoft says the VM disks and data are not stored in the associated Azure Storage account, only metadata and replication data. It also describes the flow as requiring no agents on the VMs and keeping data local. Windows Server and PowerShell familiarity helps. It does not guarantee lower cost or simpler operations, and exact source-version requirements should be checked before planning.
Red Hat OpenShift Virtualization
Red Hat's Migration Toolkit for Virtualization moves VMs from vSphere using migration plans, network mappings and storage mappings. Its docs list prerequisites that read like a project plan:
- Guest OS support. The guest OS must be certified for OpenShift Virtualization and for conversion with virt-v2v.
- Disk transfer. The VMware Virtual Disk Development Kit is used to transfer disks.
- Migration network. Choosing a migration network matters, because the default pod network may be poor for disk transfer.
- Warm versus cold migration. Warm migration keeps source VMs running while data is copied incrementally, then a cutover stops them. Cold migration stops the VMs during the copy.
This is a Kubernetes operating model. As Spiceworks says, treating it as a cheap vSphere clone swaps a licensing problem for a skills problem. Note that the Red Hat documentation reviewed here is the 2.1 release, so check the current release for your target.
Proxmox VE
Proxmox suits cost-conscious Linux shops. Its migration documentation describes an integrated importer for ESXi and OVA/OVF sources, tested from ESXi 6.5 through 8.0. It is also candid about limits worth knowing before a pilot:
- vTPM state can't be migrated. If full-disk encryption keys live in a virtual TPM, have manual recovery keys ready.
- Firmware mode must match. Set SeaBIOS for legacy BIOS VMs and OVMF for UEFI VMs. Some operating systems register only a custom UEFI boot path and won't boot without a manual boot entry.
- Live import still means downtime. The source VM on ESXi is still switched off.
- Keep imports modest. The documentation advises no more than four VM disks imported at once.
- Test first. Proxmox says to test with one or more test VMs before touching production.
A successful lab import proves little about backup integration, monitoring, HA or support coverage at 2 a.m.
Public cloud and SaaS
Public cloud was the most-cited destination in the survey. Moving a steady VM to cloud infrastructure doesn't automatically improve its economics. Retiring or replacing an application with SaaS may remove more operational baggage than changing the hypervisor.
Hardware flexibility has limits
The Spiceworks webinar featured Lenovo ThinkAgile. Lenovo's own ThinkAgile FX V4 paper describes an appliance that runs VMware, Nutanix, or Microsoft hyperconverged stacks. Lenovo Professional Services converts the existing FX V4 hardware to the new stack rather than replacing it. The paper says Lenovo recommends a single conversion, performed within three years of the original purchase. Workload migration before and after conversion is an optional scoped service. Lenovo also says it has not published benchmark or TCO figures for the series as a whole.
This is a vendor document. It supports the narrow point that hardware may be reusable. It does not make virtual disks, network policy, backups, automation or application certifications portable.
A practical sequence
The article's planning framework holds up. The nine-to-twelve-month lead time is the author's advice, not a documented requirement.
- Inventory hosts, cores, clusters, storage, dead VMs and dependencies.
- Classify each workload as retain, rehost, modernize or retire.
- Pilot a representative stack with a database, identity dependency, backup job and recovery requirement. Not an idle utility VM. Measure performance, downtime, admin effort and restore time, and test rollback.
- Build a repeatable wave: discovery, owner approval, replication, test boot, cutover, validation, rollback window and source retirement. Migration tools can't judge whether payroll ran correctly, so application owners sign off.
- Negotiate with evidence. Renewing a smaller footprint, running two platforms for a while, or leaving over several cycles can each be rational. The weak position is no inventory, no tested alternative and three weeks left on the contract.
- Plan the exit from the replacement. Ask every vendor how configuration and data are exported, which features create dependency, what happens when the subscription ends, and whether the hardware can run another stack.
Bottom line
No evidence supports a dependency-free platform. The sound advice is to know your core counts, prove one destination with a real service, and make dependencies a choice. Do that and the next renewal quote is a negotiation, not an ambush.