Leaving VMware: Hyper-V, Azure VMs or Azure VMware Solution?

Most VMware exit conversations start with a renewal quote and quickly turn into a platform question: where should these workloads run next? In the Microsoft world there are three common answers. Hyper-V on your own hosts, native Azure virtual machines, or Azure VMware Solution. Each one asks something different of your team, your hardware and your budget, and many estates end up using more than one.

This post sets out what each destination involves, so the decision gets made workload by workload instead of once for the whole estate.

Three Destinations, Three Different Trade-offs

• Hyper-V on your own hardware. The hypervisor changes; the servers, storage and network can stay, as long as they're supported for the Windows Server version you plan to run. Your team swaps vCenter for System Center Virtual Machine Manager (SCVMM) or Windows Admin Center.
• Native Azure VMs. The servers leave your data centre. There's no hypervisor for you to run, but every VM has to clear Azure's migration requirements, and you pay for the capacity you run, on pay-as-you-go or reserved pricing.
• Azure VMware Solution (AVS). Your VMs keep running on VMware vSphere, but on dedicated bare-metal hosts in Azure. Your team keeps the vSphere tools it knows. You're still running VMware, so you're still buying VMware licensing.

When Hyper-V Fits

Hyper-V tends to fit when the hardware still has life in it, most workloads are Windows servers with steady demand, and you want the data to stay in your own facility. It's also the path with the most familiar day-to-day shape: clusters, live migration, templates and a central console.

What to plan for:

• The conversion method. Microsoft's guide to converting VMware VMs with SCVMM 2025 is clear that conversions are offline (the VM is stopped, with no snapshots), VMs on vSAN can't be converted that way, VMware Tools must be removed first, and VMs with IDE disks can't be converted. Partner tools can shorten downtime windows, at extra cost.
• Running it afterwards. Decide who owns the console, how hosts get patched while workloads keep running elsewhere in the cluster, and how backup and DR work before the first production wave.

Our VMware to Hyper-V guide covers the method, and one Ontario public library's move shows the full path from licensing pressure to a running Hyper-V estate.

When Native Azure VMs Fit

Azure VMs tend to fit servers that are due for a hardware refresh, workloads with uneven demand, and applications you'd rather not host on premises at all. Microsoft's tool for the move is Azure Migrate, a free service for discovery, assessment and migration.

What to plan for:

• Blockers, VM by VM. Agentless migration supports vCenter Server and ESXi 6.5 through 9.0, but encrypted disks, shared-disk clusters, independent disks, teamed NICs and IPv6 aren't supported.
• Old operating systems. Microsoft can't guarantee reliable results for Windows Server 2008 through 2012 R2 and advises upgrading first. Our Windows Server 2012 R2 guide covers the options.
• Where the data lives. Azure Migrate project metadata can be kept in the Canada geography (Canada Central or Canada East), and the migrated VMs can run in Canadian regions too.
• Protection from day one. A migrated VM isn't protected until backup and, where needed, replication are set up. Our post on Azure Backup versus Azure Site Recovery walks through which servers need which.

When Azure VMware Solution Fits

Azure VMware Solution gives you private clouds of vSphere clusters on dedicated Azure hosts, with vCenter Server, vSAN, vSphere and NSX in every private cloud. A cluster starts at three hosts and can grow to 16. Microsoft runs the hardware and patches and upgrades ESXi, vCenter, vSAN and NSX. Your team still manages the VMs, network segments, firewall rules and the HCX migration setup.

It tends to fit workloads that can't be re-platformed quickly: applications only supported on vSphere, or estates that need to leave a data centre by a fixed date and modernize later.

The licensing changed, though, and it matters for the decision. According to Microsoft's portable VCF licensing reference:

• Since November 1, 2025, new AVS deployments must use a portable VMware Cloud Foundation (VCF) subscription bought from Broadcom. Microsoft no longer includes VCF with new host purchases.
• Existing license-included pay-as-you-go deployments must move to portable VCF by October 31, 2026 to remain compliant.
• License-included reserved instances must be exchanged for VCF bring-your-own-license reservations, or the workloads moved off AVS, by August 30, 2027, or when the reservation expires if that comes first.

So AVS changes where VMware runs, not whether you license it. If you already run AVS, check now whether your hosts are on pay-as-you-go or a reservation, because the pay-as-you-go deadline comes first. Microsoft's portable VCF guide says a running private cloud can be converted without workload interruption.

Before October 31: AVS License-Change Checklist

Applies to Azure VMware Solution private clouds still on Microsoft's license-included VMware Cloud Foundation (VCF).

1. Know which deadline is yours. License-included pay-as-you-go hosts must move to portable VCF by October 31, 2026. License-included reserved instances have until August 30, 2027, or until the reservation expires if that's sooner. (licensing reference)
2. Buy VCF from Broadcom. Since November 1, 2025, Microsoft no longer includes VCF with new AVS nodes; the subscription comes from Broadcom. (licensing reference)
3. Count cores per host. AV36/AV36P = 36, AV48 = 48, AV52 = 52, AV64 = 64. Three AV64 hosts = 192 cores. Register only BYOL hosts' cores, and never more than your Broadcom entitlement across all private clouds. (licensing reference)
4. Gather the Broadcom details. 25-character VCF key, site ID, serial number and expiration date. (configuration guide)
5. Register in the Azure portal. Private cloud > Manage > Portable VCF (BYOL) > Configure. Registration is per private cloud and portal-only. (configuration guide)
6. Reserved hosts: exchange first. Exchange the license-included reservation for a VCF BYOL reservation, then register the license within 60 minutes. (configuration guide)
7. Firewall add-on. Using NSX Distributed or Gateway Firewall (vDefend) beyond your eligible cores needs a separate Broadcom add-on license. (licensing reference)
8. Confirm status. Recheck the Portable VCF (BYOL) page after each change; unregistered or over-deployed cores make a private cloud noncompliant and at risk of suspension. (licensing reference)

Sources: Microsoft Learn, Portable VCF licensing reference and Configure portable VCF for Azure VMware Solution.

Many Estates Use More Than One

The practical answer is usually a mix: a few hard cases on AVS or left on VMware for a set period, servers with spare hardware life on Hyper-V, and the rest on Azure VMs. A few questions sort workloads quickly:

• Where does this data have to live?
• When is the hardware under it due for replacement?
• Is the application vendor-supported only on vSphere?
• Who will run the platform day to day, and what do they know today?
• Which date are you working against: a VMware renewal, an AVS licensing date, or an end-of-support date on the guest OS?

Answer those per application, not per cluster, and the destinations usually sort themselves.

Talk It Through Before You Commit

A platform decision made from a renewal quote alone tends to get revisited. If you want a second set of eyes on your hosts, your licensing dates and which workloads belong where, we're happy to go through it with you. Book a VMware exit review.