VMware alternatives after the Broadcom licensing changes

Broadcom states that it no longer sells perpetual licences and that offerings are available only as subscriptions or term licences. Existing perpetual licences can still be used, and support continues for the term of active contracts, but support and subscription (SnS) contracts for perpetual products can no longer be renewed.

In your licensing assessment, record for each host whether it runs on a perpetual or subscription licence and the date its current support contract ends.

The two main offers are VMware Cloud Foundation and VMware vSphere Foundation. vSphere Standard and vSphere Essentials Plus remain for smaller deployments. Ask your reseller which bundle maps to your current features, and get the answer in writing.

Read the vCenter and ESXi versions. Broadcom lists the end of general support for vSphere 7.0 (ESXi, vCenter and vSAN 7.x) as 2 October 2025 and for vSphere 8.0 as 11 October 2027. If you run 7.x today you are already past general support.

Connect-VIServer -Server vcenter.contoso.com
Get-VMHost | Select-Object Name,Version,Build

Broadcom again offers ESXi 8.0 Update 3e as a free hypervisor. Its KB says the free licence cannot be managed by vCenter, excludes vMotion, DRS, HA and VADP-based backups, and has no official Broadcom support. It is a lab or edge option, not a production cluster replacement. Mark any host where these limits are acceptable.

Record every VM with vCPU, memory, disk size, guest OS, firmware type (BIOS or UEFI), vTPM use and network. The commands below write all of these to a CSV. RVTools is another common way to export the same data. If Azure or Azure Local is on your shortlist, set up the Azure Migrate appliance instead, which also produces sizing data for Azure.

Install-Module VMware.PowerCLI -Scope CurrentUser
Connect-VIServer -Server vcenter.contoso.com
Get-VM | Select-Object Name,NumCpu,MemoryGB,ProvisionedSpaceGB,@{N='GuestOS';E={$_.Guest.OSFullName}},@{N='Firmware';E={$_.ExtensionData.Config.Firmware}},@{N='vTPM';E={[bool]($_.ExtensionData.Config.Hardware.Device | Where-Object { $_ -is [VMware.Vim.VirtualTPM] })}},@{N='Network';E={(Get-NetworkAdapter -VM $_).NetworkName -join ';'}} | Export-Csv .\vm-inventory.csv -NoTypeInformation

Note which of these you rely on: HA, DRS, vMotion, Storage vMotion, vSAN, NSX, distributed switches, Fault Tolerance, Site Recovery Manager, Horizon and Tanzu. Each one needs an equivalent or a decision to drop it. Add a column per feature to your application inventory and dependency map.

List backup software, monitoring, automation scripts (PowerCLI), CMDB sync and any appliance that only ships as an OVA. Appliances supplied by vendors are often the hardest part of a move, so ask each vendor which hypervisors they support.

Map each VMware feature from Step 2 to the candidate platform, citing the vendor page for each answer. For example, Proxmox VE clusters use quorum where each node has one vote and at least three votes are needed for a stable cluster; a two-node cluster needs a QDevice for the extra vote.

Confirm in writing that your backup product supports the target hypervisor at the version you will deploy, including application-consistent backups and granular restore. If not, budget time to change backup products. Proxmox VE pairs with Proxmox Backup Server, which supports incremental backups of running VMs and live restore.

Decide whether you keep your SAN, move to hyperconverged storage, or use the cloud. Check the hardware compatibility list for the candidate platform before you reuse servers.

Hyper-V and Azure Local suit Windows and PowerShell skills. Proxmox VE and XCP-ng suit Linux skills. Factor in training and whether you can get local support partners in your city.

Test the migration tool on three representative VMs: one Windows, one Linux and one appliance. Record the downtime each one needed. That test is the most reliable input for planning.

Get the Broadcom renewal quote and quotes for the alternative platform, support subscriptions, hardware (if any), backup licensing changes and partner services. Do not rely on published list prices in blogs.

Count staff time for testing, cutover windows, retraining and a period of running both platforms. Use the per-VM downtime measured in Step 4.

Enter your figures in the renew-or-move calculator and keep the output with the business case.

Save the guest network configuration first. Proxmox recommends removing guest tools tied to the old hypervisor before migrating, because they can be hard to remove afterwards, and considering removing static IP configuration on Windows. Update DHCP reservations for the new MAC address, or plan to set the MAC manually on the target VM. On the Windows Admin Center VM Conversion route, leave them in place until the VM runs on Hyper-V: Microsoft's overview says the extension removes them, but its FAQ says they are not uninstalled automatically, so check installed apps after migration and remove them yourself if they remain.

ipconfig /all | Out-File -FilePath C:\Temp\ipconfig-before.txt

Proxmox notes that vTPM state cannot currently be migrated from VMware. If BitLocker or another full-disk encryption keeps keys in the vTPM, back up the recovery key, then suspend protection before you migrate.

manage-bde -protectors -get C:
Suspend-BitLocker -MountPoint "C:" -RebootCount 0

Windows guests on KVM need VirtIO drivers, and Proxmox says Linux guests need the VirtIO drivers loaded in the initramfs. Microsoft says Linux guests moving to Hyper-V need Hyper-V drivers installed before migration. Install them first so the VM boots on the new platform.

Enter the ESXi host's domain name or IP address and an admin account for that host. If the host uses a self-signed certificate, add its CA to the trust store or tick Skip Certificate Verification. Connect to the ESXi host directly: Proxmox warns that going through vCenter dramatically reduces performance. Proxmox says import was tested from ESXi 6.5 to 8.0.

Power down the source VM first. Select the target storage for the disks and the network bridge for the NIC. On the Advanced tab you can change storage per disk, NIC models or bridges, or leave out disks, CD-ROMs or NICs. Check the Resulting Config tab, then select Import in the wizard to begin. Proxmox advises importing no more than four VM disks at once, and testing live-import on a test VM before you rely on it.

Use qm importovf for a full OVF export. For a single VMDK, create the VM first, remove its default disk on the Disk tab, then run qm disk import. The disk appears as an unusedX entry: select it, choose Edit to attach it to a bus, and set the boot disk under Options > Boot Order. For Windows guests attach the disk as IDE or SATA first, until the VirtIO drivers are installed.

qm importovf 120 /mnt/export/app01.ovf local-zfs
qm disk import 121 /mnt/export/app02.vmdk local-zfs

Search for VM Conversion (Preview) and select Install. The gateway needs version 2410 (build 2.4.12.10) or later, the latest PowerCLI, and VMware VDDK version 8.0.3 extracted to C:\Program Files\WindowsAdminCenter\Service\VDDK. Microsoft supports vCenter 6.x, 7.x and 8.x and says the extension is in preview.

Select Connect to vCenter and enter the vCenter FQDN, username and password. Select up to 10 VMs, enter the Path to store data in the Synchronize VM window and select Synchronize. When the sync finishes, go to the Migrate tab, select the VM, select Migrate and then Proceed. Stay signed in: Microsoft says the migration can pause if the browser session closes or times out.

Start with low-risk internal servers, then application tiers together, then critical systems. Keep each wave inside one change window, and note the owner who signs off each VM.

Power off the source VM, run the final sync or import, boot on the target, check the network, run application tests and get sign-off. Keep the source VM powered off, not deleted, until the rollback window closes.

After the last wave, remove hosts from vCenter, retire licences, update the CMDB and confirm backups run on the new platform.