Still Running VMware ESXi? Don't Assume You Should Keep It

Work through these questions in order. The answers will narrow the field of sensible options for each host.

1. 1What licence type are you running? (Free/discontinued, perpetual, subscription) — Verify in writing with Broadcom or your reseller before proceeding.
2. 2Is your ESXi version currently within VMware's general support period? — Check against VMware's official lifecycle documentation for your specific version.
3. 3Is the physical host hardware within its manufacturer's supported and warranted lifecycle? — Check purchase date and warranty status.
4. 4Does your backup allow recovery to an alternative host or platform? — Test, do not assume.
5. 5How many VMs are running, and what do they do? — This determines how much migration complexity exists.
6. 6Does every VM workload actually need to stay on-premises on a hypervisor? — Some may be better candidates for SaaS, cloud or application replacement.
7. 7What skills and support resource exists to maintain the platform? — Match platform choice to available competence.
8. 8What is the total three-year cost of the current or replacement VMware licence vs a Hyper-V migration on a hardware refresh? — Both require honest cost modelling.

If you reach the end of this tree and VMware still makes sense on cost, skills and support grounds, that is a legitimate outcome. If the answers reveal problems — an unsupported version, discontinued licence, ageing hardware, or a backup that cannot recover to an alternative host — those are the items to resolve first.

Use this framework to identify where attention is needed. This is a qualitative guide — do not convert it to a score. Its purpose is to surface specific gaps.

For every red area, identify the single most important next action. For amber areas, set a review date. Green areas should be verified periodically — they do not stay green without continued attention.

Current VMware ESXi releases under an active Broadcom subscription remain supported and continue to receive updates. ESXi versions follow their own support lifecycle, so older releases eventually reach end of general support. The support status of any specific version and licence should be verified directly against VMware's official product lifecycle documentation and confirmed with Broadcom or an authorised partner — not assumed.

No. VMware ESXi and the broader vSphere product family continue to be developed and sold by Broadcom following its acquisition of VMware in late 2023. What changed was the licensing and commercial model, not the existence of the product. The free vSphere Hypervisor tier was discontinued, perpetual licences were replaced with subscriptions, and some commercial terms changed materially — but VMware ESXi itself remains an active, supported enterprise hypervisor.

Yes, where the commercial terms are appropriate and the skills to manage it are available. VMware ESXi is an enterprise-grade hypervisor with a long track record. It is most straightforwardly suited to organisations with IT teams or managed service providers who have active VMware experience, environments where its advanced clustering and management features provide genuine value, and deployments where an active support subscription has been established. For a small business running a handful of VMs, the question is whether the subscription cost is proportionate to what the environment needs.

Broadcom completed its acquisition of VMware in late 2023. The changes that most commonly affect SME environments are: the free ESXi hypervisor licence was discontinued; perpetual licences were replaced with subscription-based offerings as the primary go-forward portfolio; support and update access now generally requires an active subscription; and some existing perpetual licence holders with legacy support contracts needed to reassess their position. The product itself continues to be developed. Licence and support terms should be verified directly with Broadcom or an authorised partner.

Broadcom's current go-forward portfolio is subscription-based. Perpetual licences purchased before the acquisition may continue to allow the installed software to run, but ongoing access to patches, updates and support generally requires an active subscription under the current model. If you hold a perpetual licence, verify directly with Broadcom or your reseller exactly what support and update entitlement remains, and for how long. Do not assume that a perpetual licence continues to provide update access indefinitely.

Yes. Following Broadcom's acquisition, VMware's primary commercial offerings — including vSphere Foundation and VMware Cloud Foundation — are subscription-based. This is a significant change from the perpetual licence model that many businesses were accustomed to. The practical effect is that the cost of maintaining VMware is now an ongoing annual commitment rather than a one-time purchase with optional support renewal. Businesses comparing VMware against alternatives should model the recurring subscription cost over a three- to five-year horizon.

No, not any more. The free VMware vSphere Hypervisor (ESXi Free) was discontinued by Broadcom. Businesses that had been running ESXi under the free licence no longer have access to patches and updates through that route. If your deployment relies on the former free tier, you need to confirm your current position with Broadcom and establish whether a paid subscription is required, or whether another platform is more appropriate for your scale.

The ESXi version is visible in the vSphere Client web interface on the host summary page, in the Direct Console User Interface (DCUI) on the host console, and via the vSphere API or command line when management access is available. The version string includes the major release number and build number. Once you have the version, check it against VMware's official product lifecycle documentation to confirm whether it is currently within general support. Do not rely on guesswork — the exact version and build number both matter.

An ESXi version beyond its vendor's general support period no longer receives security patches, which creates a security risk and a Cyber Essentials concern for any in-scope infrastructure. The options are: upgrade to a currently supported ESXi version under an active subscription; migrate VMs to an alternative hypervisor platform; or, in some circumstances, isolate the host from in-scope network segments while a migration plan is completed. Continuing to run an unsupported hypervisor version indefinitely without a plan is not an acceptable maintenance position.

Yes. ESXi sits below every VM on the host — a compromised hypervisor potentially affects all virtual machines simultaneously. Unpatched ESXi versions have been targeted by ransomware campaigns and specific CVEs. The risk is heightened when management interfaces such as SSH or the ESXi Shell are enabled and reachable from the business network. Keeping the hypervisor patched, restricting management access and disabling unnecessary services are the primary controls. An unsupported version with no patch access removes the ability to apply security fixes as vulnerabilities are discovered.

Cyber Essentials requires that in-scope software receives security updates from its vendor. An ESXi version within VMware's general support period, with active patch access under a current subscription, satisfies this requirement provided patching is kept current. An ESXi version beyond its support period, or a deployment running the discontinued free licence with no confirmed update access, creates a Cyber Essentials concern for any in-scope systems it hosts. The current IASME/NCSC scheme requirements should be verified directly for any specific environment before drawing conclusions.

It depends on the specific situation. Hyper-V is included in Windows Server licences, is updated through Microsoft's standard patching mechanisms, and is familiar to most Windows-trained IT teams and UK managed service providers. It is a reasonable option where the VMware subscription cost is disproportionate for the scale of the environment and where the business already holds Windows Server licences. However, migration is a real project with cost, risk and effort. A total cost comparison — including migration work, testing and any new hardware — is needed before concluding that a move to Hyper-V saves money. Neither platform universally wins.

The hypervisor component of Hyper-V is included in Windows Server licences, so there is no separate hypervisor cost for environments that already require Windows Server. This makes the direct licence cost of Hyper-V lower than a VMware subscription for many SME environments. However, total cost of ownership includes migration effort, hardware compatibility, management tooling, backup software, staff skills and ongoing support. A migration from ESXi to Hyper-V is itself a project with cost attached. Lower licence cost does not automatically mean lower total cost.

The Hyper-V role is included at no additional cost within Windows Server Standard and Datacenter licences. Microsoft previously offered a standalone Hyper-V Server product at no cost, but this has been discontinued — verify current availability with Microsoft. For environments that already purchase Windows Server licences to run Windows virtual machines, Hyper-V adds no separate hypervisor licence cost. Businesses still need valid Windows Server licences for any Windows guest VMs they run.

Yes, VM migration between ESXi and Hyper-V is technically possible. The approach generally involves exporting or backing up VMs from the source platform and importing or converting them on the target platform. The specific method depends on the backup software in use and the VM configuration. The important discipline is the same regardless of tooling: take a full backup before starting; test the migrated VM thoroughly before cutting over; verify every application works correctly on the new platform; and do not decommission the source environment until all VMs are confirmed operational on the target. Application vendor support for the new guest OS and platform should also be confirmed.

Some VM workloads can be migrated to Azure, but not every VM is a good candidate for direct lift-and-shift cloud hosting. Azure is most cost-effective for workloads with variable demand, where the cloud model avoids over-provisioned hardware, or where the application already has an Azure-native equivalent. Running a general-purpose Windows Server VM in Azure that replicates an on-premises server is often more expensive than on-premises hosting when computed over a full year. The stronger question for each workload is whether the application running inside the VM can be replaced by a SaaS or managed cloud service, rather than whether the VM itself should move to Azure unchanged.

Proxmox Virtual Environment is a genuine open-source hypervisor with an active development community and commercial support available. It is a credible alternative for technically capable teams in cost-sensitive environments. The practical challenge for many UK SMEs is that fewer managed service providers carry active Proxmox competence, which means in-house technical skill or a specialist provider is needed for day-to-day management. Proxmox is a reasonable option to evaluate — it is not automatically right or wrong, and should be assessed against the skills and support available to the business.

Nutanix AHV is the built-in hypervisor included with Nutanix's hyper-converged infrastructure platform. It combines compute, storage and virtualisation in a single system managed through Nutanix's Prism interface. Nutanix is a serious enterprise platform relevant where hyper-converged infrastructure simplifies operations at scale. For a typical SME running a small number of VMs on a single host, Nutanix would generally represent a material increase in both cost and infrastructure complexity rather than a simplification. It is worth evaluating for larger or growing virtualisation footprints where HCI provides a genuine operational benefit.

A licence or support review is a good prompt to assess hardware lifecycle at the same time. If the physical host is within its manufacturer's warranty and showing no fault indicators, a licence renewal on the existing hardware may be appropriate. If the hardware is approaching or beyond its manufacturer's supported lifecycle, combining a platform decision with a hardware refresh means the new configuration starts on hardware with a known warranty and support period. Solving a licence problem on hardware that is about to fail simply moves the crisis rather than preventing it.

There is no universal rule, but server hardware beyond five to seven years from purchase warrants a careful review. The relevant checks are: whether the hardware is still within the manufacturer's warranty or a valid extended support arrangement; whether firmware and BIOS are current; whether storage health indicators show any degradation; whether the hardware appears on the hypervisor vendor's compatibility list for the version you intend to run; and whether spare parts are still available in the event of a component failure. Age alone is not the measure — known health, supported status and available support coverage are.

This depends on the backup product and how it has been configured. Some backup products support restoring a VM backup to a different hypervisor platform — for example, recovering a VMware backup to a Hyper-V host. Others restore only to the same platform type. The important point is that this should be tested before it is needed, not assumed. A backup that can only restore to the same ESXi host provides no protection against the scenario where that host is the thing that has failed. Confirming and testing cross-platform recovery is part of a complete backup strategy.

In a single-host environment, every VM goes offline simultaneously. Recovery depends entirely on whether a current backup exists for each VM, whether that backup can be restored to a different host or platform, whether replacement hardware or an alternative recovery destination is available, and whether the recovery procedure has been documented and tested. If none of these are in place, recovery from a complete host failure could take days and might involve data loss. This is not a reason to avoid single-host virtualisation — it is a reason to ensure the recovery plan addresses the scenario explicitly.

Virtualisation alone does not provide high availability. Running multiple VMs on a single host means those VMs share the same hardware failure point. True high availability — where VMs can fail over automatically to another host if the first fails — requires a cluster of multiple physical hosts, shared or replicated storage, and specific clustering features such as VMware vSphere HA or Hyper-V Failover Clustering. These are enterprise configurations with material cost and complexity. Most SME single-host environments should instead focus on reducing recovery time through well-tested backups and a documented recovery plan.

Both approaches are valid in different circumstances. Upgrading a VM in place — changing the guest OS version without rebuilding the VM — is quicker and retains the existing application configuration, but carries the guest OS upgrade risks and preserves any accumulated configuration drift. Rebuilding a VM from scratch — creating a new VM and reinstalling or migrating the application — produces a cleaner result, reduces technical debt and is often the better choice for domain controllers, complex application servers or VMs with unknown configuration history. The decision should be made per VM based on its role, the reliability of its current configuration and the availability of application reinstallation resources.

A formal review should happen at least annually, and additionally whenever there is a significant change — new hardware, a hypervisor version upgrade, a change in licensing terms or a new application being deployed as a VM. The annual review should cover: ESXi version and patch status against the current lifecycle; licence and support contract validity; hardware health; guest OS lifecycle for all VMs; backup coverage and a tested restore; management access and account review; and the documented recovery plan for a complete host failure. Regular maintenance — patching, backup monitoring, hardware alerts — should happen continuously rather than waiting for the annual review.

A Virtualisation Health Check is a structured review of a virtualised environment covering the areas most likely to create risk if left unexamined. It typically covers: the hypervisor version and its support status; the licence and update access position; physical host hardware health and lifecycle; guest OS versions and their own support status; VM inventory and resource allocation; application support status for software running in each VM; backup coverage and a verified restore test; management access security; network configuration; and the recovery plan for a complete host failure. It is not a one-time certificate — it reflects the state of the environment at the point it is conducted and should be repeated regularly.