Leaving VMware? Your Secure Exit Path to Azure

For the Australian organisations Oreta works with, the question of what virtualisation looks like over the next few years is getting harder to put off.

Since Broadcom acquired VMware, the commercial model has changed significantly. Perpetual licences have been replaced by subscriptions built around VMware Cloud Foundation (VCF). The cost impact is real. Speaking at its Sydney infrastructure conference in May 2026, Gartner said Broadcom’s VCF-only licensing means VMware bills typically rise by 300 to 400 percent[1].In a January 2026 CloudBolt survey of 302 IT decision-makers, 59% had seen prices rise by more than 25%, and 86% said they are reducing their use of VMware[2].

What’s changing for Azure VMware Solution

Broadcom has changed its licensing across all hyperscale clouds, so customers must now buy a portable VCF subscription directly from Broadcom to use with services such as Azure VMware Solution (AVS)[3].

If you run AVS, there are now specific deadlines to plan around. AVS itself isn’t ending. Only the SKU with the licence bundled in is changing
[4].You can keep running VMware in Azure by buying a portable VCF subscription from Broadcom and bringing it to AVS. Microsoft stopped selling AVS with VCF included after 15 October 2025, so new node purchases now require a VCF subscription bought from Broadcom[3].That leaves a decision. You can stay on AVS under the new licensing model, or you can use the change to move workloads onto native Azure and reduce your dependency on VMware. Many organisations are weighing the same choice. Gartner expects 35 per cent of workloads now running on VMware to be on a different platform by 2028[1], and predicts that by 2029, 55 per cent of enterprises will be testing alternatives to their VMware deployments, up from 25 per cent in 2026
[5].

Key AVS licensing deadlines

1. Licence-included pay-as-you-go: 31 October 2026.
   Microsoft retires the licence-included PayGo SKUs on this date[4].After it, a private cloud still on that model can be found non-compliant, and Microsoft has said it may suspend it until the licensing is resolved[6].
2. Eligible licence-included Reserved Instances: 30 August 2027.
   Before then, you need to move to AVS VCF BYOL or migrate to another Azure destination to avoid service disruption from 31 August 2027. Microsoft supports a self-service exchange from licence-included to BYOL reservations[4].
3. AV36 hosts: also 30 August 2027.
   Microsoft originally aligned AV36 retirement with Broadcom’s end of vSphere 8 support on 30 September 2027, but has brought it forward to match the licence-included end of service
   [4].

These dates aren’t a single “VMware end of life” event. They’re deadlines on the commercial and technical options for running VMware in Azure. The useful question isn’t how to keep VMware running. It’s what each workload should run on next.

Three paths for your VMware workloads 

1. Stay with VMware on Azure 

Staying on AVS is the least disruptive option. Under the portable VCF BYOL model, you buy the VCF subscription from Broadcom and associate it with your AVS private cloud, while Microsoft continues to manage the underlying service. 

This can still make sense for: 

1. Workloads that depend heavily on VMware 
2. Workloads with little room for modernisation 
3. Workloads that need to leave a datacentre without significant application change 

2. Move VMware workloads to native Azure VMs

A VMware VM doesn’t have to become an AVS VM.

Azure Migrate can assess VMware workloads for migration to native Azure VMs, with readiness checks, performance-based sizing, cost estimates and migration guidance. Microsoft also supports agentless migration of on-premises VMware VMs directly to Azure[7]. For suitable workloads, this removes the VMware layer entirely.

The trade-off is simple. Going through AVS can get you out of a datacentre faster. Going straight to Azure VMs reduces your long-term platform dependency. 

Some applications can move with little change. Others depend on VMware networking, virtual hardware, storage behaviour, licensing, backup products, clustering or application architecture. Those dependencies need to be resolved before migration. 

3. Modernise the workload

Some workloads shouldn’t become VMs at all. 

A long-running VMware estate carries years of accumulated infrastructure decisions. A workload might have started on a physical server, been virtualised, moved between clusters and ended up as one VM among hundreds. Moving it straight into Azure keeps all that history and does nothing to improve the application. 

For suitable workloads, Azure offers other destinations, including App Service, Azure databases, Azure Kubernetes Service, Azure Red Hat OpenShift and other managed services. Microsoft lists modernisation with other Azure services as one of the alternatives to staying on AVS[4]. Gartner also advises that organisations considering a move off VMware tend to do better when they focus on application modernisation[1].

The upside can be significant. A Forrester study commissioned by Microsoft found a composite organisation using Azure PaaS could realise a 228 per cent return on investment over three years
[8].

At that point, the project is no longer just a hypervisor migration. It’s a question of whether the workload still needs to be a server.

Start with discovery, not migration

The most common mistake Oreta sees is starting with the target platform. Before choosing between AVS, Azure VMs or a managed Azure service, you need to understand what’s running in your VMware environment. That means an inventory of: 

1. Virtual machines and operating systems 
2. CPU, memory and storage utilisation 
3. Application and server dependencies 
4. Network flows 
5. Internet exposure 
6. Authentication dependencies 
7. Backup and disaster recovery requirements 
8. Licensing dependencies 
9. Availability and recovery requirements 
10. Data location and residency requirements 
11. Business criticality
12. Application owners 

Azure Migrate can discover and assess VMware environments, including application dependencies, before replicating and migrating VMs[9].This helps you group workloads into sensible migration waves.

This matters most for organisations that have run VMware for many years. The inventory may show that what you thought was a 200-VM environment is really a set of very different workloads with very different futures. It may also surface servers doing nothing at all. Research by Jonathan Koomey and Jon Taylor across 16,000 servers found around 30% of virtual servers were comatose, still costing money in licensing while delivering no useful work[10].

Don’t lift and shift the security model

Moving a workload from VMware to Azure doesn’t make it secure on its own. The security architecture must move with the workload and be reassessed along the way. That covers identity, privileged access, network segmentation, administrative access, endpoint protection, logging, vulnerability management, backup, recovery and monitoring.
The management layer deserves particular attention. Huntress case data shows hypervisors went from 3% of the ransomware encryption incidents it observed in the first half of 2025 to 25% in the second half[11]. Getting access and segmentation right from day one keeps your new environment on a strong footing.

For AVS, Microsoft recommends[12]:

1. Allowing access only over ExpressRoute or other secured networks
2. Avoiding internet exposure of management services such as vCenter Server
3. Configuring network security groups to control ingress and egress
4. Enabling Microsoft Defender for Cloud for unified security management

Oreta applies the same principle to native Azure workloads. We deploy them into appropriately governed Azure landing zones [13] and design each workload in line with the Azure Well-Architected Framework [14], rather than recreating the legacy VMware environment in Azure.

What to do now: your VMware exit assessment 

Oreta recommends starting with the estate itself, before making decisions about VMware licensing or the Azure landing zone. A structured VMware exit assessment should answer four questions. 

What do we have? An accurate inventory of the estate, including utilisation, dependencies, applications, operating systems, storage and network requirements. 

What needs to stay the same? Workloads with strong VMware dependencies, or ones that genuinely need a minimal-change migration. 

What can move to Azure natively? Workloads suited to Azure VMs, and applications that could move to managed Azure services instead. 

What should we retire? Not every VM needs a destination. Some servers are still running only because nobody has confirmed they’re no longer needed. A migration is the time to find them, before you pay to run them somewhere else. 

Don’t let the deadline choose your architecture 

The AVS dates create real urgency, but urgency shouldn’t set the architecture. For some organisations, AVS with portable VCF licensing is the right answer. For others, it’s the push to leave VMware entirely. Either way, make the call workload by workload, based on: 

1. Business requirements 
2. Technical dependencies 
3. Security 
4. Cost 
5. The operating model you want 

At Oreta, we believe the safest exit isn’t the one that moves the most VMs fastest. It’s the one where you know what you’re moving, why you’re moving it, where it’s going, and what the environment should look like once VMware is out of the picture.

If you’re on licence-included pay-as-you-go, 31 October 2026 is now only weeks away. Microsoft advises allowing plenty of time to purchase VCF from Broadcom and complete the transition
[4]. Reserved Instance customers have until 30 August 2027. That’s enough time to plan properly, if discovery starts now.

Ready to map your VMware estate? Talk to Oreta about a VMware exit assessment and build a clear, workload-by-workload plan for Azure. Book a conversation [PLACEHOLDER: CTA link] 

Frequently asked questions 

Is Azure VMware Solution being retired? No. AVS continues as a Microsoft-managed service. Only the licence-included option is being retired, so customers now bring their own portable VCF subscription from Broadcom. 

What happens if I’m still on licence-included pay-as-you-go after 31 October 2026? Your private cloud will no longer meet Broadcom’s licensing terms and may be suspended by Microsoft until licensing is resolved. 

When do licence-included Reserved Instance customers need to act? By 30 August 2027. You can exchange to AVS VCF BYOL reservations or migrate workloads to another Azure destination. 

Can I move VMware VMs to Azure without AVS? Yes. Azure Migrate supports assessment and agentless migration of VMware VMs directly to native Azure VMs. 

Where should a VMware exit start? With discovery. An accurate inventory of workloads, dependencies and utilisation shows which workloads should stay, move, modernise or retire.

References

1. The Register,Quit VMware and you’ll emerge with more complex and less capable infrastructure, 12 May 2026.
2. Network World,Some enterprises are dropping VMware, just not all at once, 18 February 2026.
3. Microsoft Tech Community,UPDATED: Broadcom VMware Licensing Changes: What Azure VMware Solution Customers Need to Know.
4. Microsoft Learn, Azure VMware Solution license-included service retirement, using portable VCF and other options, updated 1 September 2026.
5. The Register, Gartner predicts 55% of enterprise VMware users will be investigating an exit by 2029, 22 September 2026.
6. Microsoft Learn, Portable VMware Cloud Foundation licensing reference for Azure VMware Solution .
7. Microsoft Learn, Migrate VMware VMs to Azure (agentless).
8. Microsoft Azure Blog, Forrester study finds 228 percent ROI when modernizing applications on Azure PaaS.
9. Microsoft Learn, How to migrate VMware VMs to Azure IaaS.
10. Computerworld, A third of virtual servers are zombies, May 2017.
11. Huntress, Hardening the Hypervisor, December 2025.
12. Microsoft Learn, Security recommendations for Azure VMware Solution.
13. Microsoft Learn, What is an Azure landing zone?
    
14. Microsoft Learn, Azure Well-Architected Framework.