--- title: "VMware to Azure: Avoid the Broadcom Per-Core Trap" description: "Compare Azure VMware Solution, Azure Local, and native Azure, then model Broadcom per-core licensing, build the landing zone, and migrate in waves." canonical: "https://adamtheautomator.com/vmware-to-azure-migration-roadmap/" --- # VMware to Azure: Avoid the Broadcom Per-Core Trap > Compare Azure VMware Solution, Azure Local, and native Azure, then model Broadcom per-core licensing, build the landing zone, and migrate in waves. Source: https://adamtheautomator.com/vmware-to-azure-migration-roadmap/ --- ATA Learning Tap to hide [ ATA Learning ](/) * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Search for: * [](https://twitter.com/adbertram) * [](https://github.com/Adam-the-Automator) * [](https://www.linkedin.com/company/adam-the-automator-llc) * [](/feed/) ![VMware to Azure: Avoid the Broadcom Per-Core Trap](https://adamtheautomator.com/wp-content/uploads/publisher/2e05d9c85b2b81d1a183f32356379208/90bb2192ef4e2f89f05de2af33aa4bff61921c1c0f9e1b8f86c0de25a90ba045.webp) # VMware to Azure: Avoid the Broadcom Per-Core Trap [![](https://secure.gravatar.com/avatar/d0b9d42e21e5622713f8b693aa5c0f9244d5f7dd200ed29b8398f52dee5de337?s=192&d=mm&r=g)Adam Bertram](https://adamtheautomator.com/author/adam-bertram/)5 October 202619 min. read Categories: [Cloud](/category/cloud/) Tags:[Azure](/tag/azure/)[Virtualization](/tag/virtualization/)[Azure Migrate](/tag/azure-migrate/)[Microsoft Licensing](/tag/microsoft-licensing/) Table of Contents * [The VMware Trap: When Azure Becomes a Broadcom Reseller](#the-vmware-trap-when-azure-becomes-a-broadcom-reseller) * [What Azure Takes Over and What Broadcom Keeps](#what-azure-takes-over-and-what-broadcom-keeps) * [The Core Math and the Compliance Calendar](#the-core-math-and-the-compliance-calendar) * [Four Ways Out of VMware](#four-ways-out-of-vmware) * [Path 1: Azure VMware Solution](#path-1-azure-vmware-solution) * [Path 2: Azure Local](#path-2-azure-local) * [Path 3: Native Azure](#path-3-native-azure) * [Path 4: Negotiate and Stay](#path-4-negotiate-and-stay) * [Deciding Per Workload: The Exit-Path Decision Matrix](#deciding-per-workload-the-exit-path-decision-matrix) * [Reading the Matrix by Application Group](#reading-the-matrix-by-application-group) * [Prerequisites Before the First Wave](#prerequisites-before-the-first-wave) * [The Short List](#the-short-list) * [Assess the Estate With Azure Migrate Before You Commit](#assess-the-estate-with-azure-migrate-before-you-commit) * [Discovery That Changes the Design](#discovery-that-changes-the-design) * [Wave Planning Without a Spreadsheet](#wave-planning-without-a-spreadsheet) * [Check Capacity Before You Build the Business Case](#check-capacity-before-you-build-the-business-case) * [Model the Money: Node Cost, Hybrid Benefit, and Break-Even](#model-the-money-node-cost-hybrid-benefit-and-break-even) * [Where the Break-Even Actually Sits](#where-the-break-even-actually-sits) * [Build the Landing Zone and Connectivity First](#build-the-landing-zone-and-connectivity-first) * [The Four Decisions That Cannot Wait](#the-four-decisions-that-cannot-wait) * [Deploy the Destination: AVS, Azure Local, or Native Azure](#deploy-the-destination-avs-azure-local-or-native-azure) * [Create the AVS Private Cloud](#create-the-avs-private-cloud) * [Azure Local and Azure VMs](#azure-local-and-azure-vms) * [Migrate in Waves: Tools, Cutover, and NSX Translation](#migrate-in-waves-tools-cutover-and-nsx-translation) * [Translating NSX-T Security Into NSG and Azure Firewall Policy](#translating-nsx-t-security-into-nsg-and-azure-firewall-policy) * [The Throughput Limit That Rarely Makes the Project Plan](#the-throughput-limit-that-rarely-makes-the-project-plan) * [Validate, Roll Back, and Decommission Each Wave](#validate-roll-back-and-decommission-each-wave) * [The Wave Acceptance Gate](#the-wave-acceptance-gate) * [The Dated Roadmap Tied to Your Renewal Deadline](#the-dated-roadmap-tied-to-your-renewal-deadline) * [Two Rules That Keep the Trap Closed](#two-rules-that-keep-the-trap-closed) * [Frequently Asked Questions](#frequently-asked-questions) * [Does Moving to AVS Remove Our VMware Licensing Costs?](#does-moving-to-avs-remove-our-vmware-licensing-costs) * [Can We Migrate Straight to Azure Virtual Machines Instead of AVS?](#can-we-migrate-straight-to-azure-virtual-machines-instead-of-avs) * [What Happens If We Miss the Portable VCF Deadlines?](#what-happens-if-we-miss-the-portable-vcf-deadlines) Read a VMware renewal quote past the headline number, and you will find a structure that charges for cores nobody bought. Broadcom retired perpetual licensing ([the end-of-availability notice](https://knowledge.broadcom.com/external/article/309138/vmware-end-of-availability-of-perpetual.html) is the primary source), folded vSphere into [VMware Cloud Foundation](https://learn.microsoft.com/en-us/azure/azure-vmware/vmware-cloud-foundations-license-portability), and moved the licensing metric from CPU sockets to physical cores with a 16-core minimum per socket. First-round quotes have arrived at two to four times the old vSphere run rate, and published reports describe increases ranging from 100% to 800%. A range that wide stops being a platform team problem and becomes a budget problem that follows the workloads into [Azure VMware Solution](https://learn.microsoft.com/en-us/azure/azure-vmware/introduction) if you lift them without modernizing. This VMware migration roadmap runs in the order the decisions actually happen. It starts with the estate you can prove you run and the money the Broadcom subscription adds to the budget, and it ends with a wave you have validated or rolled back. Two mistakes sink the plan before the first VM moves: treating Azure VMware Solution as the finish line, and budgeting from the Azure pricing calculator alone. Both are fixable at a whiteboard. ## The VMware Trap: When Azure Becomes a Broadcom Reseller Azure VMware Solution (AVS) runs vSphere, vSAN, NSX, and [HCX](https://learn.microsoft.com/en-us/azure/azure-vmware/install-vmware-hcx) on dedicated Azure bare metal, managed by Microsoft. It removes the hardware refresh, the data center lease, and the 2 a.m. memory module swap. It doesn’t remove Broadcom. ### What Azure Takes Over and What Broadcom Keeps Microsoft Learn’s [portable VCF licensing reference](https://learn.microsoft.com/en-us/azure/azure-vmware/portable-vcf-licensing-reference) draws the boundary: “As of November 1, 2025, Microsoft no longer includes a VCF license or subscription with new Azure VMware Solution node purchases.” Every SKU on the [Azure VMware Solution pricing page](https://azure.microsoft.com/en-us/pricing/details/azure-vmware/) now reads VCF BYOL (bring your own license), and the node price “includes the Azure infrastructure and the AVS managed service, but does not include the VMware VCF portable subscription required from Broadcom.” The AVS trap is the Broadcom VMware licensing model that follows the workloads. Lift your virtual machines to AVS, skip the modernization work, and you hold a permanent per-core Broadcom subscription that grows every time you add a node. That subscription continues for as long as workloads stay on AVS, which is why workloads you plan to modernize should route to native Azure instead. ### The Core Math and the Compliance Calendar The core math is public. AV36 and AV36P hosts carry 36 cores each, AV48 carries 48, AV52 carries 52, and AV64 carries 64. A three-node AV36P deployment, the smallest cluster Azure will provision, registers 108 cores with Broadcom. Scale that to a 12-node AV52 estate and you register 624 cores while Microsoft bills you for 12 nodes. Neither invoice knows about the other, and the [Broadcom-side deadlines](https://techcommunity.microsoft.com/blog/azuremigrationblog/broadcom-vmware-licensing-changes-what-azure-vmware-solution-customers-need-to-k/4448784) arrive regardless: * October 31, 2026: license-included pay-as-you-go deployments must move to portable VCF to remain compliant. * August 30, 2027: reserved instances for license-included hosts must be exchanged for VCF BYOL reservations, or those workloads leave AVS. The financial case for AVS itself is real. Microsoft’s commissioned [Forrester Total Economic Impact study](https://info.microsoft.com/ww-landing-forrester-the-projected-total-economic-impact-of-microsoft-azure-vmware-solution.html) from April 2024 reports a 298% three-year ROI and 90% of on-premises server refreshes avoided, and every benefit line behind those numbers comes from leaving hardware and owned licenses behind. A [March 2026 Forrester study](https://techcommunity.microsoft.com/blog/azuremigrationblog/fast-cloud-migration-measurable-roi-forrester-total-economic-impact-study-of-azu/4508136) commissioned by Microsoft reports a 341% three-year ROI for the same composite organization. ![VMware trap exit paths](https://adamtheautomator.com/wp-content/uploads/publisher/b8050afa068fc5a82d671100c5bb3396ed092025280a675ff856a18755945502.png) * * * _**Reality Check: A lift-and-shift to AVS without a modernization plan trades a data center lease for a per-core subscription and a second vendor relationship. You still pay for the second move, and you make it on a schedule you never planned for.**_ * * * Whether a given workload needs a second move off AVS is the first decision on the list, and it isn’t the same decision for every workload. ## Four Ways Out of VMware You probably frame the choice as AVS against native Azure. And that framing hides two options and one uncomfortable truth: only two of the four paths remove Broadcom from the bill, and only one removes VMware from your operating model. | Path | VMware stack stays | Broadcom subscription stays | Strongest fit | | --- | --- | --- | --- | | Azure VMware Solution | Yes | Yes | Deadline-driven exits, fragile dependencies, NSX-heavy estates | | Azure Local, Hyper-V based | No, guests convert | No | Sites that need local hardware, latency-bound or data-residency workloads | | Native Azure IaaS and PaaS | No | No | Estates you intend to modernize, ordinary servers, small VMware footprints | | Negotiate and stay | Yes | Yes | Estates with no exit deadline where renewal math still beats migration | ### Path 1: Azure VMware Solution AVS keeps vCenter, NSX, and your existing runbooks, and VMware HCX moves virtual machines without converting them. It wins on time to exit, and licensing is the price of that speed. Growth in the VCF core count outpaces the modernization work that would end the subscription. AVS also needs an Enterprise Agreement, a Microsoft Customer Agreement, or a CSP-managed subscription before reserved instance pricing is available to you. ### Path 2: Azure Local [Azure Local](https://learn.microsoft.com/en-us/azure/azure-local/migrate/migration-azure-migrate-vmware-overview) runs Hyper-V on your own validated hardware with Azure Arc management, and Azure Migrate handles the discovery, replication, and cutover of VMware guests into it. Broadcom leaves the picture entirely. What you keep is the rack, the power draw, and the refresh cycle, which is the wrong trade when hardware is the reason you are leaving. Guest support is the second gate: an appliance that validates on vSphere doesn’t automatically [validate on Hyper-V](https://adamtheautomator.com/vmware-vs-hyper-v/). ### Path 3: Native Azure Moving to [Azure virtual machines](https://learn.microsoft.com/en-us/azure/app-modernization-guidance/foundation/replatform-vmware-and-azure-vmware-solution-applications) and managed platform services is the only path that ends the VMware and Broadcom line items together. It costs rework, and the [Cloud Adoption Framework](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/azure-vmware-solution/strategy) names exactly when that trade pays: [workloads you plan to modernize soon](https://adamtheautomator.com/ready-move-beyond-liftandshift-azure-migration-roi/), workloads that run fine on Azure VMs without VMware dependencies, and small footprints that can move directly. It loses when nobody has estimated the rework, because an unestimated rework line always looks cheap in a status meeting. ### Path 4: Negotiate and Stay Renegotiating with Broadcom is a legitimate destination. [Azure Migrate’s business case](https://learn.microsoft.com/en-us/azure/migrate/how-to-build-a-business-case?view=migrate) exists to test it, comparing three targets (modernize to PaaS, migrate to all IaaS, or migrate to AVS) against your current run cost. A discount percentage only reduces the rate, because the new metric bills every physical core whether or not your guests use it. So the four-path table decides nothing on its own, because most real estates contain all four cases at once. ## Deciding Per Workload: The Exit-Path Decision Matrix One destination per data center is the most expensive habit in this migration. The Cloud Adoption Framework frames AVS itself as an on-ramp, letting you keep familiar VMware technologies “while gradually building Azure capabilities at a pace that aligns with business priorities.” The same page draws the other side of the line: “moving directly to Azure IaaS or PaaS services often provides greater cloud-native benefits and can reduce long-term platform costs.” Sort the estate by signal, then assign a target: | Signal in the workload | Best-fit target | Why it wins | | --- | --- | --- | | Fragile dependency graph, NSX firewall rules, VMware backup tooling, hard exit date | Azure VMware Solution | HCX moves guests without re-IP, which buys calendar time | | Ordinary server with no VMware-specific dependency | Azure virtual machines | Ends VMware operations instead of relocating them | | Web app, API, or containerized service | [App Service](https://learn.microsoft.com/en-us/azure/app-service/overview), [AKS](https://learn.microsoft.com/en-us/azure/aks/what-is-aks), or [Container Apps](https://learn.microsoft.com/en-us/azure/container-apps/overview) | No guest OS to patch, and scaling is a platform concern | | SQL Server that can run on a managed engine | [Azure SQL Managed Instance](https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/sql-managed-instance-paas-overview) or Azure SQL Database | Removes the database OS layer and its licensing | | Windows Server 2012 or SQL Server 2012 workloads | AVS or Azure VMs | Three years of Extended Security Updates at no charge in Azure, against a penalty of 75% of license price elsewhere in year one, 100% in year two, and 125% in year three | | No exit deadline and renewal still beats two years of migration | Negotiate and stay | Migration without a forcing function burns goodwill and budget | ### Reading the Matrix by Application Group Two failures repeat here. Deciding for the whole estate in one meeting lets the loudest application choose for the quiet ones, and deciding per virtual machine produces thousands of micro-decisions. Sort by application group, and let groups that share a dependency graph migrate together. The matrix needs evidence, so the next step is discovery rather than a decision. ## Prerequisites Before the First Wave Line these up before the first wave. Each item names what it unlocks and when you can skip it. ### The Short List * **An Azure subscription where you hold Contributor or higher.** Add an Enterprise Agreement, Microsoft Customer Agreement, or CSP subscription before you plan a reservation purchase, because AVS reservation eligibility depends on one. * **A portable VCF entitlement from Broadcom.** Azure won’t deploy the private cloud without a key, though the licensing rules for portable VCF allow a 60-day three-node trial with a trial key. * **A dedicated /22 CIDR block for the private cloud management network.** It carries vCenter Server, NSX-T Manager, and HCX, and it can’t overlap your virtual networks. Use the [network planning checklist](https://learn.microsoft.com/en-us/azure/azure-vmware/plan-private-cloud-deployment) to confirm block selection and the 40-character resource name limit. * **Host quota requested ahead of your window.** Allocation can take up to five business days and undeployed quota expires after 30 days. Follow the [host quota request process](https://learn.microsoft.com/en-us/azure/azure-vmware/request-host-quota-azure-vmware-solution) before you commit to dates, because that delay turns a scheduled cutover into a slipped quarter. * **HCX 4.11.0 or later on both sides.** The [HCX 4.11.0 upgrade notice](https://techcommunity.microsoft.com/blog/azuremigrationblog/hcx-4-11-0-upgrade-and-what-it-means-for-current-hcx-users/4421149) explains the support boundary, and 4.10.x is already out of support. * **Source networks on a vSphere Distributed Switch.** Networks on a vSphere Standard Switch can’t be extended, and that constraint lives in the HCX network extension documentation rather than in your vCenter console. * **An Azure Migrate appliance with read access to vCenter.** The [appliance setup guide](https://learn.microsoft.com/en-us/azure/migrate/how-to-set-up-appliance-vmware?view=migrate-classic) covers the OVA and installer script paths. * **The Az PowerShell module for the native Azure path.** Migration at scale is scripted through [Az.Migrate](https://learn.microsoft.com/en-us/powershell/module/az.migrate/) rather than the portal, which caps selection at 10 machines per batch. ## Assess the Estate With Azure Migrate Before You Commit Discovery is where you find out that half the estate is over-provisioned and the other half silently supports things nobody documented. Azure Migrate runs that work with an appliance that reads hardware inventory and collects performance samples over weeks, then sizes the target from observed utilization instead of assigned vCPU counts. The scale ceilings matter when you plan: one project assesses up to 35,000 VMware VMs, one appliance discovers up to 10,000 VMs across up to 10 vCenter Servers, and the [assessment tutorial](https://learn.microsoft.com/en-us/azure/migrate/tutorial-assess-vmware-azure-vm?view=migrate) walks the readiness report for AVS and Azure VMs side by side. ### Discovery That Changes the Design Network discovery is the capability you are most likely to underuse. Azure Migrate collects subnets, VLANs, NSX segments, port groups, NAT policies, load balancers, and firewall policies, then [recommends Azure networking constructs](https://learn.microsoft.com/en-us/azure/migrate/whats-new?view=migrate) including network security groups and [Azure Firewall](https://learn.microsoft.com/en-us/azure/firewall/overview) for the same traffic patterns. Pull that inventory before anyone starts writing NSG rules by hand. ### Wave Planning Without a Spreadsheet Auto Wave Planning groups discovered workloads by dependency and application boundaries, then sequences them with priority, confidence, and risk indicators. Treat the output as a starting draft. The order that survives review has shared databases moving last, stable dependencies inside a wave, and the riskiest workload in wave two. ### Check Capacity Before You Build the Business Case Quota availability differs by region and SKU, and finding out after you build the model wastes the model. Run this from a shell where the Azure CLI is authenticated: ```bash az vmware location check-quota-availability --location eastus2 --output table ``` The command returns the host quota available to your subscription in that region, and it needs the `vmware` Azure CLI extension, which installs on first use and requires core Azure CLI 2.75.0 or higher. The extension itself is version 8.1.0. The commands and limits in this roadmap were validated on Azure CLI 2.85.0 with the `vmware` extension 8.1.0. The `New-AzMigrateServerReplication` parameter set was verified against `Az.Migrate` 2.12.1; the agentless replication path and the HCX 4.11.0 workflow need an AVS private cloud, an Azure Migrate project with a discovered VMware source machine, and deployed HCX appliances, so those were not executed end to end. Compare what it returns against the SKU you intend to reserve before you request an increase. Then build the numbers rather than the narrative. Microsoft’s own [business case guidance](https://learn.microsoft.com/en-us/azure/migrate/how-to-view-a-business-case?view=migrate) states that only reserved instances count as a savings option when the target is AVS, so the model has to include a commitment decision rather than pay-as-you-go rates. ## Model the Money: Node Cost, Hybrid Benefit, and Break-Even Budgets that start from the Azure pricing calculator are wrong before the first invoice, because the biggest line item on an AVS deployment isn’t on that page. The table below is an illustrative model for one estate: three AV36P hosts running 40 virtual machines, compared against the same 40 machines sized by the assessment for native Azure. Substitute your own assessment output and your own Broadcom quote. | Cost driver | AVS, 3 x AV36P | Native Azure, 40 VMs | | --- | --- | --- | | Azure infrastructure | About $10,500 per month, based on the Forrester composite of roughly $3,500 per node per month | Sized from assessment; reserved capacity for ordinary workloads typically lands well below the AVS floor | | Broadcom portable VCF | 108 cores registered; priced from your Broadcom quote, and it never appears on the Azure invoice | None | | Windows Server and SQL Server | Azure Hybrid Benefit with active Software Assurance | Azure Hybrid Benefit with active Software Assurance | | Capacity floor | Three nodes minimum, N+1 recommended | None; scale per workload | | Savings options | Reserved instances only for the AVS target | Reserved instances and savings plans | Two licensing mechanics do more for the AVS column than any discount negotiation. First, [Azure Hybrid Benefit on AVS](https://learn.microsoft.com/en-us/azure/azure-vmware/sql-server-hybrid-benefit) applies SQL Server licensing at the host level covering all physical cores, and a VM-Host placement policy limits which host cores carry the license while allowing unlimited SQL Server virtualization on them. Second, Windows Server nodes need a minimum of eight core licenses per VM, so [bring-your-own Windows licensing](https://learn.microsoft.com/en-us/windows-server/get-started/azure-hybrid-benefit) pays off fastest on dense hosts. Extended Security Updates add three years of free patches for legacy Windows Server and SQL Server, against a penalty of 75% of license price outside Azure in year one, 100% in year two, and 125% in year three. ![AVS vs native Azure cost](https://adamtheautomator.com/wp-content/uploads/publisher/85f5f61e4645718c8c219ce683b16a35cfc093f039e617bfacbf9a1004c781e1.png) ### Where the Break-Even Actually Sits The comparison stops being close once you account for cores. Multiply your deployed host cores by the Broadcom per-core licensing rate to get the annual subscription that rides on top of the Azure bill, then compare the total against the cost of modernizing the workloads that can leave virtual machines entirely. Most estates modernize the top handful of platforms first, which is where the [SQL Server and web tier workloads](https://adamtheautomator.com/migrate-sql-server-azure-sql-database/) sit. If the three-year rework estimate for those platforms is unknown, your model is carrying an unsourced number. * * * _**Warning: A budget built from the Azure pricing calculator alone understates AVS run cost, because the node price excludes the VCF subscription and because egress and interconnect charges are easy to leave out. Put both in writing before someone signs a three-year commitment.**_ * * * The model tells you what the destination costs. But the landing zone determines whether you can deploy it on schedule. ## Build the Landing Zone and Connectivity First [Landing zone work](https://adamtheautomator.com/build-azure-landing-zones/) is unglamorous, and it’s the phase that slips first. Four decisions have to be settled before the first wave, and three of them can’t be reversed cheaply. ### The Four Decisions That Cannot Wait **Addressing and naming.** Reserve a /22 block for the private cloud management network and prove it does not overlap anything in your subscription or on-premises. Keep the private cloud resource name at 40 characters or fewer; beyond that limit, public IP creation fails, which shows up as a networking bug rather than a naming problem. **Generation.** AVS has two private cloud generations whose main difference is network architecture. Choose [Generation 2](https://learn.microsoft.com/en-us/azure/azure-vmware/native-introduction) for new deployments: it attaches vSphere hosts directly to your Azure virtual network instead of routing through a Microsoft-managed ExpressRoute circuit, and it uses the express storage architecture with AV64 hosts. But Generation 1 remains valid only when an existing dependency requires it, because moving between generations requires workload migration. **Connectivity.** Generation 1 needs [ExpressRoute](https://learn.microsoft.com/en-us/azure/expressroute/expressroute-introduction) with Global Reach for cross-region paths. Generation 2 terminates directly in the virtual network, which also lets [Azure Arc](https://learn.microsoft.com/en-us/azure/azure-arc/overview), network security groups, and Azure Firewall policy apply to the VMware side without a bolt-on appliance. **Commitment.** AVS reservations run one, three, or five years against a host SKU and region, and they aren’t purchasable everywhere. Confirm that your chosen SKU carries the term you need in your region, that your agreement type qualifies, and that quota exists for the reserved hosts, because Azure can restrict new reservation purchases for a host SKU during regional capacity shortages. None of these decisions should be made the week of the first cutover. Pick them during assessment, while a wrong answer still costs a meeting instead of a wave. ## Deploy the Destination: AVS, Azure Local, or Native Azure The deployment itself is a short list of commands once the prerequisites exist. Create the private cloud with the Azure CLI, then confirm it reached a healthy state before you touch HCX. ### Create the AVS Private Cloud ```bash az vmware private-cloud create \ --resource-group \ --name \ --location eastus2 \ --sku AV36P \ --cluster-size 3 \ --network-block 10.175.0.0/22 \ --strategy SingleZone \ --accept-eula \ --yes ``` Three flags carry the decisions from the previous sections. `--network-block` takes the /22 management block, `--cluster-size` sets the management cluster hosts (minimum 3, maximum 16), and `--strategy` takes `SingleZone` or `DualZone`. The remaining two flags, `--accept-eula` and `--yes`, acknowledge the end-user license agreement. Without them the command tries to prompt for that agreement, and a shell or CI runner with no terminal to answer the prompt cancels the create with `Unable to prompt for confirmation as no tty available. Use --yes.` The [private cloud CLI reference](https://learn.microsoft.com/en-us/cli/azure/vmware/private-cloud?view=azure-cli-latest) lists the full parameter set for the `vmware` extension, including the VCF license argument for BYOL registration. Azure documents an estimate of four hours or more for the initial deployment, and the [deployment tutorial](https://learn.microsoft.com/en-us/azure/azure-vmware/tutorial-create-private-cloud) confirms the expected end state. ```bash az vmware private-cloud show \ --resource-group \ --name \ --output table ``` Read the status column for `Succeeded` before scheduling anything downstream. Additional capacity arrives one host at a time, or as a new cluster through [`az vmware cluster create`](https://learn.microsoft.com/en-us/cli/azure/vmware/cluster?view=azure-cli-latest), which takes a cluster name, the private cloud, a resource group, a SKU, and a cluster size. One ordering detail is easy to miss: AV64 hosts on a Generation 1 private cloud require an existing seed cluster of at least three AV36P, AV48, or AV52 nodes, while a Generation 2 AV64 cluster deploys directly. ### Azure Local and Azure VMs Azure Local takes a different route to the same outcome. You validate and register the hardware, [create the Arc-enabled cluster](https://adamtheautomator.com/manage-hybrid-infrastructure-azure-arc/), then use Azure Migrate to discover and replicate VMware guests into it, following the [Azure Local VMware migration prerequisites](https://learn.microsoft.com/en-us/azure/azure-local/migrate/migrate-vmware-prerequisites). No Broadcom line item appears anywhere in that path, and you still own the rack, its power bill, and the hardware refresh. Azure VMs take the third route and need no VMware-specific deployment step at all. The work moves from platform buildout to application migration, which is where the next section spends its effort. ## Migrate in Waves: Tools, Cutover, and NSX Translation Two engines do the moving, and the destination picks the engine. VMware HCX carries guests into AVS with the VMware stack intact. Azure Migrate carries guests into Azure virtual machines or Azure Local with the guest converted. The sequence below holds for both paths. ![HCX migration waves](https://adamtheautomator.com/wp-content/uploads/publisher/ee0e0b1818e3fab74e36aa759a2035c47e9f2bcb8da870a57edb08c9bf49eccc.png) 1. **Pair the migration appliances.** For AVS, deploy the HCX Cloud Manager in the private cloud and the HCX Connector in the source vCenter, activate the pair with a site key, and build the service mesh. The [HCX architecture overview](https://learn.microsoft.com/en-us/azure/azure-vmware/architecture-migrate) covers the appliance roles and the encrypted tunnels the mesh creates. 2. **Extend layer 2 for the wave.** Network extension keeps guest IP and MAC addresses, which lets a fragile application move without a re-IP project. [Network extension has hard limits](https://techdocs.broadcom.com/us/en/vmware-cis/hcx/vmware-hcx/4-11/vmware-hcx-user-guide-4-11/extending-networks-with-vmware-hcx/about-vmware-hcx-network-extension/restrictions-and-limitations-for-network-extension.html): one appliance pair per network per site, three destinations per network, about eight extended networks per appliance, and no loop detection. 3. **Pick the move type per workload.** vMotion moves a running guest with zero downtime, one at a time. Bulk migration replicates a wave in the background and takes a short outage at switchover. Cold migration takes the full outage during transfer. Replication Assisted vMotion batches with a vMotion cutover, and OS Assisted Migration handles non-vSphere guests. 4. **Replicate to native Azure targets.** Enable replication from the appliance, then run a test migration into a non-production virtual network before anything touches production. The target region and cache storage account lock in at first replication, so choose them deliberately. 5. **Script the scale instead of using 10-machine batches.** The portal caps selection at 10 machines per batch, so at-scale work runs through Az.Migrate: ```powershell New-AzMigrateServerReplication ` -MachineId "" ` -TargetVMName "app01" ` -TargetResourceGroupId "" ` -TargetNetworkId "" ` -TargetSubnetName "app-tier" ` -TargetVMSize "Standard_D4s_v5" ` -DiskType "Standard_LRS" ` -LicenseType "NoLicenseType" ` -OSDiskID "" ``` The parameters mirror decisions from earlier sections: `-TargetVMSize` and `-DiskType` carry the sizing your assessment produced and the disk tier you are willing to pay for, `-OSDiskID` comes from the discovery record for the source machine, and the name, resource group, network, and subnet parameters reproduce the placement the exit-path matrix assigned. Set the license type on this call when the workload qualifies for Azure Hybrid Benefit, or you’ll pay for Windows Server twice. The [cmdlet reference](https://learn.microsoft.com/en-us/powershell/module/az.migrate/new-azmigrateserverreplication) lists the full parameter set, and the [agent-based migration path](https://learn.microsoft.com/en-us/azure/migrate/tutorial-migrate-vmware-agent?view=migrate) covers guests that agentless replication cannot handle. 1. **Schedule around blackout windows and churn patterns.** A migration started inside a configured blackout window doesn’t run its final replication and fails. High-churn guests delay delta cycles, extend the shutdown window, and can exhaust datastore space on the source, which is why [agentless replication concepts](https://learn.microsoft.com/en-us/azure/migrate/concepts-vmware-agentless-migration?view=migrate) recommend enlarging datastores before a heavy wave. 2. **Cut over, then complete the migration.** Azure Migrate shuts the source VM down during cutover to run a final sync with no data loss. Run the complete step after validation to release replication artifacts and seed disks, or leave managed disks billing storage transactions for machines that no longer exist. 3. **Decommission the source.** Remove guests from vCenter inventory, local backups, and the CMDB, then retire the physical hosts. The on-premises host count sets your Broadcom core count, so a wave that never decommissions pays both sides indefinitely. ### Translating NSX-T Security Into NSG and Azure Firewall Policy NSX distributed firewall rules enforce at the vNIC and at line rate. Azure network security groups evaluate per subnet and per interface with a different rule model, and Azure Firewall handles the centralized path. Pull the firewall policy inventory from Azure Migrate’s network discovery, group the rules by application tier, and rebuild them as NSG rules plus firewall policy collections in a workstream that starts during assessment. ### The Throughput Limit That Rarely Makes the Project Plan Migration and workload traffic share the NSX Edge by default. Microsoft Learn states: “Each of the DPDK cores can process up to ~5 Gbps traffic, based on flow hashing, packet size, and services enabled on NSX gateway.” The [NSX scale recommendations for HCX](https://learn.microsoft.com/en-us/azure/azure-vmware/azure-vmware-solution-nsx-scale-and-performance-recommendations-for-vmware-hcx) prescribe a separate Tier-1 gateway for HCX uplink traffic and multiple network extension appliances. Mobility Optimized Networking reduces asymmetry in some topologies, but [MON guidance](https://learn.microsoft.com/en-us/azure/azure-vmware/vmware-hcx-mon-guidance) requires a Tier-1 gateway connected straight to Tier-0 with no virtual appliance between them. * * * _**Pro Tip: Measure the wave window before you promise it. Migrate one representative guest, record the elapsed time and the throughput it consumed, then scale the estimate by guest count and disk size. A pilot that takes 40 minutes tells you more about the schedule than any vendor table.**_ * * * ## Validate, Roll Back, and Decommission Each Wave A wave is done when the evidence says so. Define these checks before the wave starts and run them as a gate: ### The Wave Acceptance Gate * **Application response and naming from outside the wave.** A client on another network completes the primary transaction path, with dependency calls in the same test, and internal DNS records point at the new location for anything that changed. * **Latency baseline.** Compare against the pre-migration measurement for the same transaction, and treat a regression beyond the agreed threshold as a failed wave. * **Backup and monitoring coverage.** The backup job completes against the new platform and the monitoring agent reports, which is the check you skip and then rediscover during an incident. * **Licensing reconciliation on AVS.** Compare registered VCF cores against deployed host cores. A mismatch is the noncompliance condition that carries the suspension risk. * **Security rule parity.** Run the allowed-and-denied test matrix from the NSX rule inventory and confirm the NSG and firewall rules reproduce the intended outcome. Rollback is a decision with a number attached. Keep source guests powered off but present through the soak window, keep the service mesh until the wave is accepted, and agree in advance on the threshold that triggers a return to the source. Because the test migration ran against a non-production network, a rollback is a rerun of the cutover. The [Cloud Adoption Framework migration guidance](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/azure-vmware-solution/migration) covers the same evaluation and decommission phases, and the [VMware migration support matrix](https://learn.microsoft.com/en-us/azure/migrate/migrate-support-matrix-vmware-migration?view=migrate) lists the configurations that block replication outright, including shared VHDs, Fibre Channel disks, and guests with BitLocker enabled. ## The Dated Roadmap Tied to Your Renewal Deadline Sequencing is where the anti-trap plan holds or collapses. Each phase below has a duration range and an exit criterion, and the dates come from your own Broadcom renewal, with the portable VCF deadlines as the outside boundary. | Phase | Typical duration | Exit criterion | | --- | --- | --- | | Assess and decide | 4 to 6 weeks | Dependency map, rightsized inventory, business case for each target, per-workload matrix signed off | | Land | 3 to 6 weeks | Quota allocated, /22 in place, generation chosen, connectivity tested, VCF entitlement registered | | Pilot wave | 2 to 4 weeks | Ten or fewer low-risk guests moved through the full sequence, rollback rehearsed | | Production waves | 2 to 6 months | Waves of 50 to 200 guests at a two to four week cadence, each accepted against the validation gate | | Modernize | Starts during wave two, runs 6 to 18 months | Workloads flagged for PaaS or managed data services leave virtual machines | | Decommission | Per wave, final pass in 4 weeks | Source hosts retired and Broadcom core count reduced | ### Two Rules That Keep the Trap Closed Any workload flagged for modernization within 18 months doesn’t land on AVS during a wave, because a second move costs more than routing it correctly the first time. Decommissioning also needs a named owner, since the savings case depends on hardware actually retiring. Broadcom’s own notice confirms that [vSphere 8 is the last version available under perpetual licensing](https://blogs.vmware.com/cloud-foundation/2024/01/22/vmware-end-of-availability-of-perpetual-licensing-and-saas-services/), and licensing-advisory sources track its end of general support in October 2027. Treat that date as a secondary-source estimate rather than a vendor commitment, and treat it as the second forcing function on your roadmap. If your renewal lands before it, the renewal sets the schedule. ## Frequently Asked Questions The questions below come up in the first planning meeting of almost every VMware exit, and each answer depends on decisions made in the sections above. ### Does Moving to AVS Remove Our VMware Licensing Costs? No, moving to Azure VMware Solution doesn’t remove your VMware licensing costs. Since November 1, 2025, the AVS node price covers Azure infrastructure and the managed service, and the VCF subscription that runs on it comes from Broadcom. You keep a per-core licensing cost and gain a second counterparty, and [registering a portable VCF entitlement](https://learn.microsoft.com/en-us/azure/azure-vmware/vmware-cloud-foundations-license-portability) is now part of every AVS deployment. ### Can We Migrate Straight to Azure Virtual Machines Instead of AVS? Yes, you can migrate straight to Azure virtual machines instead of AVS, and for a large share of ordinary servers it’s the better destination. Azure Migrate replicates VMware guests directly to Azure VMs using the same discovery data, and the [agentless migration tutorial](https://learn.microsoft.com/en-us/azure/migrate/tutorial-migrate-vmware?view=migrate) is the execution path. Reserve AVS for workloads whose operating systems, middleware, vendor support, or dependency graphs cannot survive the conversion. ### What Happens If We Miss the Portable VCF Deadlines? Missing a portable VCF deadline carries Microsoft’s stated consequence of suspension: “Microsoft may suspend a noncompliant private cloud until the issue is resolved.” The practical sequence is less dramatic and more expensive. And pay-as-you-go deployments that miss October 31, 2026 must convert to portable VCF, and [reserved instances](https://learn.microsoft.com/en-us/azure/azure-vmware/reserved-instance) for license-included hosts must be exchanged by August 30, 2027, or the workloads leave AVS and rejoin the migration queue you just paid to escape. Share this article [Share on X](https://twitter.com/intent/tweet?url=https%3A%2F%2Fadamtheautomator.com%2Fvmware-to-azure-migration-roadmap%2F&text=VMware%20to%20Azure%3A%20Avoid%20the%20Broadcom%20Per-Core%20Trap)[Share on Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fadamtheautomator.com%2Fvmware-to-azure-migration-roadmap%2F)[Share on LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fadamtheautomator.com%2Fvmware-to-azure-migration-roadmap%2F) ## Related Posts ![](https://adamtheautomator.com/wp-content/uploads/publisher/2e05d9c85b2b819f9960cc3af514f9a0/4edae5c1327c7aaa91f7cd7fb033f216b4ba0310906a424978cd0f2b4bca4345.webp) ### [Azure Data Sovereignty Guardrails: Cut Jurisdictional Risk](/azure-data-sovereignty-guardrails/) Master Azure data sovereignty with residency policies, encryption keys, operator oversight, and compliance controls to prevent jurisdictional data access. ![](https://adamtheautomator.com/wp-content/uploads/publisher/3075d9c85b2b8183b1f2c3f391257a46/bd9070a98945da0014fd6ce4e9aeebdec333abbe87cd0491a6f55c3584262ee7.webp) ### [AKS: Ship Production-Ready Apps with Helm and CNI Overlay](/aks-production-ready-helm-overlay/) Build a production-shaped AKS path: Azure CNI Overlay, ACR, Helm, Gateway API routing, Entra workload identity, and NetworkPolicy hardening. ![](https://adamtheautomator.com/wp-content/uploads/2026/09/featured_image-1.webp) ### [Bicep: Never Hand-Write Azure ARM JSON Again](/azure-bicep-vs-arm-templates/) Learn how Bicep simplifies Azure infrastructure deployment with domain-specific language, dependency inference, and reusable modules for cleaner IaC. ## Categories * [IT Ops](/category/it-ops/) * [Cloud](/category/cloud/) * [DevOps](/category/devops/) * [Home Ops](/category/home-ops/) * [Information Security](/category/infosec/) * [Software Development](/category/software-development/) ## Site * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Copyright 2026© ATA Learning | [Privacy Policy](/privacy/)