AVS, Azure VMs, Containers or Rebuild? Choosing a Route for Each VMware Workload

Which route should each VMware workload take?

Each workload should take the route its own signals point to, not the route the rest of the estate takes. Azure VMware Solution (AVS) suits workloads that must move quickly without change, and Azure VMs suit servers on supported operating systems. Containers suit applications built as services, code you will keep investing in deserves modernisation, and end-of-life packages such as Dynamics AX 2012 or NAV should be replaced with SaaS.

This post is the decision framework we use for each workload. It sits under our complete guide to leaving VMware after Broadcom, which covers the licensing changes and the wider timeline. The volume of moves is real: Gartner research VP Julia Palmer told The Register in September 2025 that more than a third of workloads now on VMware will run on another platform by 2028.

What are the five routes off VMware?

The five routes differ in how much the workload changes and in whether the Broadcom relationship survives.

Azure VMware Solution: fast, unchanged, still VMware

AVS gives you private clouds of vSphere clusters on dedicated bare-metal Azure hosts, with vCenter, vSphere, vSAN and NSX. Microsoft manages the infrastructure and the VMware software lifecycle. Each cluster runs between 3 and 16 hosts. New deployments currently run vCenter and ESXi 8.0 U3k with HCX 4.11.4, so VMs move across without conversion.

The licence model changed in 2025. New AVS node purchases have not included a VCF licence since 1 November 2025. Customers buy VCF directly from Broadcom, and the subscription must cover every physical core: three AV64 hosts need 192 cores. Microsoft reports these registrations to Broadcom monthly. AVS therefore removes your hardware, not your Broadcom contract.

AVS fits when a data centre or hardware deadline arrives before the applications are ready, or when an application cannot change at all in the time available. It does not fit when the business goal is to end Broadcom spend, or when the estate is so small that a three-host minimum outweighs the workload. AVS runs in two UK regions, UK South and UK West, and AVS Gen 2 (AV64 hosts only) is available in both. AV48 hosts are not listed in either UK region.

Microsoft partners with the relevant specializations can access funding under Frontier Accelerate for Azure, the FY27 name for Azure Accelerate. Microsoft's page names VMware to AVS as a supported scenario.

Azure VMs: the default for supported servers

Rehosting onto Azure VMs ends the VMware licence for that server. Azure Hybrid Benefit lets you bring Windows Server core licences with active Software Assurance (at least 8 core licences per VM) and SQL Server licences. Microsoft allows 180 days in which licences run both on-premises and in Azure during migration.

Azure VMs fit stable servers on supported operating systems. They fit badly when the operating system has no security update path, because moving an unsupported server to Azure does not make it supported. They also fit badly when an application changes weekly and the team spends its time on server care rather than on the code.

Containers on AKS or SUSE Rancher

The container route has two homes. AKS runs on Azure, and AKS on Azure Local runs on-premises. SUSE Rancher with SUSE Virtualization (formerly Harvester) runs on-premises or hybrid, and Harvester also runs ordinary VMs on the same platform. Our post on Rancher, Harvester and AKS covers the platforms in detail.

Containers fit applications that already run as separate services, especially on Linux. They fit poorly for older Windows applications. AKS requires the first system node pool to be Linux, Windows nodes do not support privileged containers, and Windows Server 2019 node pools lost support on 1 March 2026. A monolithic Windows application with GUI or host dependencies usually belongs on an Azure VM or in a modernisation plan.

Modernise the application

Modernisation rebuilds the application on platform services or new code. Azure Hybrid Benefit covers SQL Server on Azure SQL Database (vCore tiers) and SQL Managed Instance, so existing SQL licences can carry across. Azure Migrate added integration with the GitHub Copilot modernization CLI in June 2026 (preview) to give code insights at scale.

This route fits systems that set you apart and that change often. It does not fit an application you plan to retire within a couple of years. Spend the effort where the business will keep investing.

Replace with SaaS

Some workloads should stop existing. Dynamics AX 2012 R3 left extended support on 10 January 2023. NAV 2016 left extended support on 14 April 2026, NAV 2017 leaves on 11 January 2027 and NAV 2018 leaves on 11 January 2028. Rehosting any of these moves an unsupported ERP onto new infrastructure. We recommend Dynamics 365 instead, and our post on AX 2012 and NAV on VMware sets out why.

Decision table: which route fits which workload?

Which signals decide the route for a workload?

Seven signals decide most routes. We collect them for every workload before anyone argues about platforms.

The operating system and SQL Server signals carry dates, and those dates move the decision more than any other factor. Windows Server 2012 and 2012 R2 ESUs ended on 13 October 2026. Windows Server 2016 extended support ends on 12 January 2027. Microsoft offers Windows Server 2016 ESUs for up to three years, but it has not stated directly that they will be free on Azure VMs or AVS. Its 27 March 2026 licensing notice says new ESU offerings from 1 April 2026 carry the same price inside or outside Azure.

SQL Server follows a similar pattern. SQL Server 2014 ESUs run until 8 July 2027 and are still free on Azure VMs, AVS and Azure Stack. SQL Server 2016 extended support ended on 14 July 2026, and moving it to Azure no longer brings free ESUs. Billing for SQL Server 2016 ESUs started on 15 July 2026, and they run until 17 July 2029.

Team skills deserve more weight than they usually get. A route that your team cannot run safely is the wrong route, however elegant it looks on a slide.

How does Azure Migrate feed the decision?

Azure Migrate turns the signals above from guesswork into data. Microsoft has added most of the useful features since May 2025, and several remain in preview as of October 2026.

1. Discover. The Azure Migrate appliance discovers servers through vCenter Server (versions 9.0 back to 5.5). It cannot discover through ESXi hosts directly. It inventories installed software for up to 10,000 servers per appliance through VMware Tools, without in-guest agents. You can import an RVTools export (preview) for a quick first look before deploying the appliance.
2. Map dependencies. Agentless dependency analysis covers up to 3,000 servers per appliance. Agent-based dependency analysis is retired for new onboarding, and the classic view that still offers it is due for deprecation by the end of 2026. Network discovery for VMware and NSX (preview since August 2026) adds subnets, VLANs, NSX segments, load balancers and firewall and NAT policies.
3. Assess by application. Application-aware assessment, generally available since May 2025, groups servers into applications rather than judging each VM alone. Automatic application discovery (preview since May 2026) speeds up that grouping. Reserved tags for environment and migration intent (April 2026) change how the assessment sizes each target.
4. Compare targets. Reports (preview since March 2026) produces executive summaries, TCO and ROI views and security insights for Azure VM, PaaS or AVS targets.
5. Plan waves. Wave Planning (preview since November 2025) and Auto Wave Planning (preview since September 2026) sequence applications into migration waves. Dependency groups from step 2 become the boundaries of each wave.
6. Replicate and cut over. Microsoft recommends agentless replication for VMware, using vSphere snapshots and Changed Block Tracking. One appliance replicates up to 300 VMs at once per vCenter, or 500 with a scale-out appliance. The classic agent-based replication appliance fully retired on 30 September 2026.

The Azure Copilot migration agent (preview since March 2026) gives a conversational way to plan and analyse VMware migrations using Azure Migrate data. Migration itself still runs in the Azure Migrate portal.

Azure Migrate answers "what is there and what talks to what". It does not answer "will this application still work for its users after cutover". That second question needs a test baseline, which we cover in proving every app still works after a VMware migration.

A real estate that needed three routes

One of our clients shows why a single route rarely fits a whole estate. The company, an anonymised oil and gas business based in Scotland, ran its own VMware infrastructure. We took it off VMware using three routes in the same estate:

• Its containerised applications moved from VMware to SUSE Rancher.
• Its ERP was replaced with Dynamics 365 Finance & Operations rather than rehosted.
• Its other workloads, including the SQL Server estate, moved to Azure services, with PaaS used where it fitted rather than only Azure VMs.

The oil and gas VMware exit case study describes the project. No single platform would have suited all three groups of workloads.

Worked example: an illustrative estate

The estate below is illustrative only. It is not a client, and the workloads are invented to show how the signals combine.

Picture a UK distribution business with workloads on vSphere 8. Its Broadcom renewal falls in spring 2027, and its hardware is due for replacement in the same year.

The estate ends up with five routes and one small AVS footprint. The AVS piece is the only part that still needs a VCF subscription, so the renewal conversation with Broadcom shrinks to the cores that footprint uses. Our cost model post shows how to price that comparison honestly.

What are the common traps?

We see the same mistakes in most VMware exit plans.

1. Treating AVS as the destination. AVS still needs a VCF subscription for every physical core, and licence-included pay-as-you-go hosts must move to portable VCF by 31 October 2026. Plan the exit from AVS on the day you plan the entry.
2. Assuming every ESU is free on Azure. SQL Server 2014 ESUs are free on Azure until 8 July 2027. SQL Server 2016 ESUs are not. Microsoft has not confirmed free Windows Server 2016 ESUs on Azure.
3. Rehosting Windows Server 2012 servers. Their ESUs ended on 13 October 2026, so a rehost moves a server that no longer receives security updates.
4. Choosing routes per VM instead of per application. A web tier on Azure VMs with its database left on vSphere adds latency between them and breaks the wave plan. Use dependency data to group them.
5. Ignoring the network. NSX firewall rules and load balancers carry years of undocumented decisions. Azure Migrate network discovery (preview) helps, but someone still has to decide what each rule is for.
6. Forcing Windows applications into containers. The AKS Windows limits are real, and the effort often exceeds a straight rehost or a proper rebuild.
7. Cutting over without a test baseline. Teams test the infrastructure and assume the application works. Capture how each application behaves before migration, then re-test after cutover.
8. Upgrading on-premises platforms to the newest release on day one. The Harvester v1.9.0 release notes say upgrading to v1.9.0 "is currently not recommended" because known issues can force VMs to shut down.

How we approach route selection

We run the framework above as our VMware Exit Assessment. Agents assist with discovery and code analysis, so each workload gets its signals and a recommended route. We build a cost model against your Broadcom renewal, and we set a UI and regression test baseline before anything moves. We re-test after cutover and hand over an evidence pack, and a managed service can run the result afterwards.

The testing approach comes from our agentic software delivery work. One anonymised client has every release AI-tested, including UI testing and Azure DevOps bug verification, and the client released more than 15 testing roles. That project is about release testing, not migration, and the agentic release testing case study describes it.