There is a date on the calendar that has turned a long-running architecture debate into a scheduling problem. Before 1 November 2026, every Azure VMware Solution customer still running pay-as-you-go nodes with an included VMware Cloud Foundation subscription must supply a portable VCF licence key bought directly from Broadcom, or the service stops being available to them on the old terms. Microsoft stopped selling Azure VMware Solution with VCF included after 15 October 2025, and the grace period for existing deployments runs out on 31 October 2026. Modernizing VMware stopped being a five-year strategy the moment that became a renewal deadline.
The temptation is to treat this as a procurement exercise — sign the Broadcom subscription, keep the estate exactly as it is, revisit the question in three years. That works, and for a meaningful slice of workloads it is the correct answer. But it also spends the one moment when the organisation is genuinely willing to reopen every assumption about where its virtual machines live. Modernizing VMware using Azure native services is not a single migration. It is a sequence of decisions about which workloads keep their hypervisor, which ones shed it, which ones stop being virtual machines altogether, and which ones should never have been running in the first place.
The market data says almost everyone is somewhere in that sequence and almost nobody has finished it. A CloudBolt survey published in January 2026 found 86% of organisations actively reducing their VMware footprint, with 44% having moved at least a quarter of their environment and only 2% past the three-quarters mark. Gartner’s 2026 strategic planning assumption puts 55% of enterprises at a complete migration off VMware by 2029. The gap between “actively reducing” and “actually finished” is where most IT budgets currently live, and it is where modernizing VMware succeeds or stalls.
What follows covers what modernizing VMware on Azure actually involves in practice: the four destinations a workload can land in, what Azure VMware Solution is and where its Generation 2 architecture changes the network story, how Azure Arc lets you modernise management before you move a single VM, what Azure Migrate can and cannot tell you, the mechanics of HCX cutover, the identity and security services that make the estate look like the rest of Azure, when a workload should stop being a VM entirely, when Azure Local is the honest answer instead, what modernizing VMware costs across three years, and the specific ways these programmes go wrong.
Modernizing VMware: The Quick Answer
Modernizing VMware using Azure native services means moving your vSphere estate onto Azure infrastructure and then progressively replacing the parts of it that Azure does better — storage, identity, security, backup, monitoring, and eventually the application runtime itself. Azure VMware Solution provides the landing zone: dedicated bare-metal hosts running vCenter, vSAN, vSphere, and NSX, deployed and patched by Microsoft, sitting adjacent to every other Azure service. You migrate with VMware HCX, keep your existing operational tooling, and then modernise underneath the workload rather than in front of it.
The distinguishing move is sequencing. A traditional migration asks you to refactor before you move, which is why so many of them stall. Modernizing VMware on Azure inverts that: relocate first with zero application change, gain the adjacency to Azure services, and then modernise workload by workload against a business case rather than a mandate. Azure Arc extends the same logic backwards, letting you apply Azure governance, patching, and security to VMs that have not moved yet, so modernizing VMware management does not have to wait for modernizing VMware placement.
| Decision | What Azure native services give you | What they do not do |
|---|---|---|
| Landing zone | Managed vSphere, vSAN, and NSX on dedicated hosts | Remove the need for a Broadcom VCF subscription |
| Migration | HCX live vMotion and bulk migration with network extension | Rewrite applications or resolve technical debt |
| Management | One Azure control plane across on-premises, AVS, and Azure | Replace vCenter for day-to-day vSphere operations |
| Storage | Azure NetApp Files, Elastic SAN, and Pure Storage Cloud datastores | Make vSAN capacity free or unlimited |
| Identity | Microsoft Entra ID as an external identity source for vCenter | Retire Active Directory on its own |
| Security | Defender for Cloud, Sentinel, and Update Manager across the estate | Cover what runs inside unmanaged guest operating systems |
| Modernisation | Assessed paths into AKS, App Service, and managed databases | Guarantee every workload has a PaaS destination |
| Exit | Portable licensing and a phased path off the hypervisor | Deliver savings in the first twelve months |
Why Modernizing VMware Became Urgent in 2026
For two decades the case for staying on vSphere was that nothing else was as good and the licence was already paid for. Broadcom removed the second half of that sentence, and the first half stopped being true somewhere around the point where the hyperscalers started shipping managed vSphere.
The pricing evidence is consistent across independent surveys. Roughly 59% of VMware customers report renewal increases above 25%, and about 14% say their costs doubled outright. Broadcom ended standalone vSphere Standard and Enterprise Plus sales, consolidating everything into VMware Cloud Foundation subscriptions with minimum core commitments and multi-year terms. For a mid-sized estate that was previously buying exactly the sockets it needed, the new floor is frequently larger than the actual footprint.
That is the forcing function, but it is not the argument. The argument for modernizing VMware is that the operational model around those virtual machines has not changed since 2012 while everything around it has. Patching is still a scheduled outage. Capacity is still a purchase order with a twelve-week lead time. Disaster recovery is still a second data centre that is idle 364 days a year. Security tooling is still a separate console from the one covering the cloud estate — a fragmentation problem we have written about at length in the context of avoiding security tool sprawl with unified SecOps.
Modernizing VMware onto Azure native services collapses several of those problems at once, not because the hypervisor changes but because the surrounding platform does. The point is worth holding onto through the rest of this article: the value of modernizing VMware is rarely in the migration itself. It is in what becomes possible once the estate is adjacent to everything else.
The November 2026 Licence Deadline That Forces the Question
The licensing change deserves its own section because the dates are specific, the consequences are not negotiable, and they set the clock on every modernizing VMware decision that follows.
Microsoft stopped selling Azure VMware Solution with an included VCF subscription after 15 October 2025. Reserved instances purchased before that date keep their original licence terms for the remainder of their commitment, which is why a great many organisations bought one, three, or five-year reservations in the weeks before the cutoff — reserved instances also carry roughly 50% savings against pay-as-you-go pricing, so the move made sense on two axes at once.
Everyone else is on the clock. Existing pay-as-you-go deployments with an included licence continue to operate unchanged through 31 October 2026. Before 1 November 2026, those customers must supply Microsoft with a portable VCF licence key purchased directly from Broadcom. New nodes purchased from 16 October 2025 onwards already require it. Microsoft’s own guidance for Azure VMware Solution customers navigating the Broadcom licensing changes is the authoritative source, and the BYOL option is now available in all 35 AVS regions at a lower node price than the old bundled arrangement.
There is a planning subtlety here that catches people. A portable VCF subscription is portable — the same entitlement can cover on-premises hosts, Azure VMware Solution hosts, or a mix, and it can move between them as the estate shifts. That makes the licence a strategic asset rather than a sunk cost, and it means the sequencing question (“do we migrate before or after renewal?”) has a genuinely different answer than it did under the old per-cloud model. Teams modernizing VMware estates should be modelling the licence and the infrastructure together, because optimising either in isolation produces the wrong answer.
What Cloud-First Architecture Means When Modernizing VMware
“Cloud-first” has been diluted into meaninglessness by a decade of vendor decks, so it is worth defining what it means specifically in the context of modernizing VMware.
It does not mean everything runs in a public cloud region. It does not mean every workload becomes serverless. It means the default control plane is Azure Resource Manager, the default identity provider is Microsoft Entra ID, the default policy engine is Azure Policy, the default observability stack is Azure Monitor, and anything that deviates from those defaults does so because of a documented requirement rather than because that is how it has always been.
Under that definition, a virtual machine running on Azure VMware Solution is a cloud-first workload. A virtual machine running on an on-premises host that is Arc-enabled, policy-governed, and patched through Azure Update Manager is also cloud-first. A container running in AKS is cloud-first. What is not cloud-first is a VM whose only management interface is a vCenter console that nobody outside the infrastructure team can reach.
That reframing matters because it decouples modernizing VMware from physically relocating everything. The organisations that make the fastest progress are the ones that separate “where does this run” from “how is this governed,” solve the second question first across the entire estate, and then treat placement as an optimisation problem rather than a prerequisite. Modernizing VMware under that definition starts producing results in weeks rather than after the first migration wave.
The Four Destinations for a VMware Workload
Every VM in the estate ends up in one of four places, and the entire planning exercise behind modernizing VMware is really about sorting the inventory into these four buckets and then executing each bucket differently.
The first destination is Azure VMware Solution: the workload keeps its hypervisor, its VMDK disks, its NSX segments, and its operational runbooks, and relocates onto Microsoft-managed bare metal. This is the lowest-risk, fastest path and it is where most of the volume goes first. The second is native Azure infrastructure-as-a-service: the VM sheds vSphere and becomes an Azure virtual machine with managed disks, availability zones, and the full Azure VM ecosystem. The third is platform-as-a-service: the workload stops being a VM at all and becomes an App Service, an AKS deployment, an Azure SQL managed instance, or a function. The fourth is Azure Local or a retained on-premises footprint, for workloads that cannot leave the building for latency, sovereignty, or regulatory reasons.
There is a fifth destination nobody puts on the slide: decommissioning. In practice, a properly executed discovery pass on a decade-old estate finds somewhere between 10% and 25% of VMs that are powered on, consuming licence cores, and serving nothing. Modernizing VMware is the only realistic opportunity most organisations get to run that audit, and the savings from it frequently fund the first year of the programme.
The mistake is treating these as a maturity ladder where PaaS is the goal and AVS is a waypoint. They are destinations with different economics, and modernizing VMware well means matching each workload to the right one rather than pushing everything towards the most modern-sounding option. A stable, low-change line-of-business application with a 15-year lifespan and no development team is correctly placed on Azure VMware Solution permanently. Moving it to containers would be an expensive way to achieve nothing.
Azure VMware Solution: Modernizing VMware Without Rewriting It
Azure VMware Solution provides private clouds built from dedicated bare-metal Azure infrastructure, each one running VMware vCenter Server, vSAN, vSphere, and NSX. Microsoft deploys, patches, and upgrades all four. You get vCenter access, you keep your VM templates, your vSphere role-based access control, your NSX distributed firewall rules, and your third-party backup agents.
The operational significance is easy to understate. Modernizing VMware through Azure VMware Solution means the migration does not touch the application, the operating system, the IP address, the MAC address, or the runbook. The change-control conversation for a relocation is fundamentally different from the change-control conversation for a refactor, and on a large estate that difference is measured in quarters.
Microsoft’s introduction to Azure VMware Solution documents the shared responsibility split precisely, and it is worth reading before the programme starts rather than after the first incident. Microsoft owns the physical infrastructure, the ExpressRoute circuits, the host lifecycle, ESXi and vCenter and NSX and vSAN patching, the provider-side networking, and backup and restore of vCenter and NSX Manager. You own everything above that: NSX segments and firewall policy, VM lifecycle, guest operating system patching, antivirus, backup software, vSAN storage policies, HCX configuration, and connectivity design.
The line most teams get wrong is guest patching. Microsoft patches the platform, not your Windows Server 2016 fleet. Modernizing VMware onto managed infrastructure removes an entire class of maintenance work and leaves another class entirely intact, and budgeting as though it removed both is a reliable way to end the first year behind schedule.
Inside an Azure VMware Solution Private Cloud
The hardware specifics matter more than they usually do, because they determine both the cost model and the sizing that modernizing VMware depends on.
A private cloud is built from clusters, and a cluster requires a minimum of three hosts and scales to a maximum of 16. Only one host type is permitted per private cloud, with the AV64 expansion as a documented exception. The AV36 runs dual Intel Xeon Gold 6140 CPUs with 36 physical cores and 576 GB of RAM. The AV36P moves to Cascade Lake with 768 GB. The AV48 uses Sapphire Rapids Xeon Gold 6442Y processors, 48 cores, 1 TB of memory and 25.6 TB of raw NVMe capacity on vSAN ESA. The AV52 delivers 52 cores and 1,536 GB of RAM. The AV64 runs Ice Lake Xeon Platinum 8370C with 64 cores and 1 TB of memory. Every host type carries 100 Gbps network throughput.
Two details in that specification list change architecture decisions. The first is that vSAN Express Storage Architecture is now the default on AV48 and on AV64 Gen 2 hosts, which materially changes the performance profile and the usable-capacity maths compared with the original storage architecture on older SKUs. The second is that Microsoft recommends deploying vSAN clusters with a minimum of four hosts rather than three, because at three hosts a single fault domain failure — or a routine maintenance-mode reboot — protects existing data but blocks object creation. Sizing a production cluster at exactly the documented minimum is a decision that looks fine until the first patch window, and it is one of the most common early errors when modernizing VMware onto managed hosts.
Software versions are current and centrally managed. New deployments ship vCenter Server 8.0 U3e, ESXi 8.0 U3f with a hot patch, vSAN 8.0 U3, NSX 4.2.3.2, and HCX 4.11.4. When Broadcom publishes an advisory, Microsoft schedules the remediation across the fleet — the July 2026 response to VMSA-2026-0006 committed all vCenter and ESXi hosts to 8.0 U3k once qualification completed, estimated for August 2026. You do not schedule that work, but you do receive Service Health notifications about it, and since the maintenance orchestrator reached general availability in January 2026 you can reschedule planned maintenance directly from the Azure portal.
Generation 2 and the End of Mandatory ExpressRoute
The most consequential architectural change to Azure VMware Solution in the last two years is the one that gets the least attention, because it is a networking change and networking changes do not demo well.
Generation 1 private clouds connect vSphere hosts to Azure resources through Microsoft-managed ExpressRoute circuits, with ExpressRoute Global Reach linking the private cloud back to on-premises. It works, it is well understood, and it adds a layer of circuit management that has nothing to do with your workloads. Generation 2, generally available since September 2025 on the AV64 SKU, deploys the private cloud directly inside an Azure virtual network. The hosts attach to standard Azure networking, powered by Azure Boost, at 100 Gbps with lower latency — and ExpressRoute is no longer required.
For teams modernizing VMware, that is a genuine simplification rather than a repackaging. It means the private cloud behaves like every other resource in the VNet, which means network security groups, private endpoints, route tables, and Azure Firewall apply in the way an Azure network engineer already expects. For organisations modernizing VMware with a small networking team, removing the ExpressRoute layer removes an entire specialism from the critical path.
The constraints are real and current. Generation 2 is AV64-only, and at general availability it covered East US, Canada Central, Canada East, North Europe, and UK West, with SLAs specified per region. Microsoft has also been migrating Gen 2 workload connectivity from T0 NICs to 7170 anchor NICs with an iBGP full-mesh topology, a change coordinated through Customer Success Account Managers with a four-hour maintenance window and up to roughly two minutes of north-south connectivity loss. If your target region is not on the Gen 2 list, this is a roadmap item rather than a design option, and any architecture built today for modernizing VMware should not assume it.
Modernizing VMware Storage: When vSAN Stops Being the Answer
The single most common cost failure when modernizing VMware is buying compute you do not need in order to get the storage you do. It is worth understanding before a single node is priced.
Because a private cloud scales in whole hosts, a storage-heavy workload forces you to add CPU and RAM you will never use. A file server estate consuming 200 TB does not need 12 hosts’ worth of cores, but under vSAN-only sizing that is what it gets. Azure solved this by allowing datastore capacity expansion using Azure storage services independently of the cluster, and the options have matured to the point where anyone modernizing VMware should evaluate them in every sizing exercise rather than treat them as an exception.
Azure NetApp Files provides NFS datastores attached directly to Azure VMware Solution hosts, and since June 2026 nConnect support is generally available, allowing multiple TCP connections per mount for materially better throughput on data-intensive workloads. Azure Elastic SAN reached general availability for the AV64 SKU in February 2025 as a VMware-certified datastore, letting storage and performance scale on their own axis. Azure Native Pure Storage Cloud entered public preview in April 2025 for vVols-based block storage, and Pure Cloud Block Store has been generally available since March 2024.
The planning rule that falls out of this is straightforward. Size clusters for compute, size datastores for capacity, and treat any sizing model that derives host count purely from terabytes as a first draft. Teams modernizing VMware estates with large unstructured data footprints routinely find that external datastores change the node count by a third or more, which is the difference between a business case that clears and one that does not.
Modernizing VMware Networking: NSX, Global Reach, and Virtual WAN
Network design is where modernizing VMware either becomes straightforward or becomes a six-month engagement.
Each private cloud creates private networks for management, provisioning, and vMotion at deployment. Workload connectivity runs through NSX, and you retain full control of segments, additional Tier-1 routers, the gateway and distributed firewalls, NSX load balancing, IPsec VPN, and NAT. Connectivity to on-premises on Generation 1 runs over ExpressRoute Global Reach, connecting circuits directly at the Microsoft Edge. Each Azure VMware Solution environment is its own ExpressRoute region with its own virtual MSEE device, which is what lets multiple instances in one region connect to the same peering location.
Two constraints trip people up. ExpressRoute gateways do not transit traffic between circuits, so attaching two circuits to one gateway does not route between them — that is what Global Reach is for. And in locations where Global Reach is unavailable due to local regulation, modernizing VMware requires a routing solution built from Azure IaaS virtual machines, which is a documented pattern in the Cloud Adoption Framework but is not what anyone drew on the whiteboard.
Internet access for private cloud VMs is disabled by default on new private clouds and is enabled through Azure Virtual WAN public IP functionality on the NSX Edge. That default is correct and should be left alone until there is a specific need, because the fastest way to undermine the security posture of a freshly migrated estate is to restore an internet path that nobody has re-reviewed since the original data centre design. The identity-boundary thinking that applies here is the same as in any identity-centric zero trust architecture — the migration is the moment to tighten the boundary, not to replicate it.
Azure Arc: Modernizing VMware Management Before You Move Anything
The most underused service in the whole business of modernizing VMware is the one that requires no migration at all.
Azure Arc-enabled VMware vSphere extends the Azure control plane to vSphere infrastructure, and it works against on-premises vCenter Servers, Azure VMware Solution private clouds, and both at once. You deploy an Azure Arc resource bridge — a virtual appliance — into the vSphere environment, connect it to vCenter, and Azure automatically discovers the full inventory of VMs, templates, networks, datastores, clusters, hosts, and resource pools, keeping it continuously in sync.
What that buys anyone modernizing VMware is substantial. Virtual machines appear in the Azure portal and behave like Azure VMs for create, resize, delete, and power operations. Application teams get self-service VM lifecycle through Azure RBAC rather than through a ticket to the infrastructure team. The Azure Connected Machine agent installs at scale, and once guest management is enabled the whole Azure management surface applies: Azure Policy machine configuration for auditing, Microsoft Defender for Cloud and Defender for Endpoint for threat detection, Microsoft Sentinel for correlation, Azure Update Manager for OS patching, Azure Monitor and VM insights for observability, and Azure Automation for runbooks. Automation works through Python, Java, JavaScript, Go, and .NET SDKs, plus Terraform, Bicep, ARM, REST, CLI, and PowerShell.
The scale limits are specific. Azure Arc-enabled VMware vSphere currently supports vCenter Server version 8 with a maximum of 9,500 VMs, and multiple vCenters can share one resource bridge provided the combined total stays under that ceiling. Estates above that need multiple bridges, and that is a design decision worth making early in a modernizing VMware programme rather than discovering at onboarding.
There is also a licensing benefit that pays for the effort on its own. Arc delivers Windows Server management benefits for VMs covered by Software Assurance, and pay-as-you-go Extended Security Updates for Windows Server and SQL Server on-premises — with free SQL Server ESUs for VMs running on Azure VMware Solution. For an estate with a meaningful Windows Server 2012 or SQL Server 2014 tail, that is a real number.
One retirement to note: Microsoft retired Azure Kubernetes Service on VMware (preview) on 16 March 2026, directing customers to AKS on Azure Local for on-premises Kubernetes. Anyone whose modernization plan was built on that preview needs a new plan.
Azure Migrate: The Assessment That Decides Everything
Nothing in modernizing VMware is as consequential as the inventory, and nothing is as consistently rushed.
Azure Migrate discovers the vSphere estate agentlessly through an appliance, collects configuration and performance data continuously, and produces assessments against multiple target shapes. For this scenario the important one is the Azure VMware Solution assessment, which supports the AV36, AV36P, AV48, AV52, and AV64 SKUs across both Generation 1 and Generation 2, sizes the required node count, and — since November 2024 — costs Azure NetApp Files as an external storage option and accounts for the cost of porting an on-premises VMware Cloud Foundation subscription to Azure VMware Solution.
The tooling has moved quickly through 2026 and several of the additions change how the planning phase of modernizing VMware works. Reports, in public preview since March 2026, generate executive-level summaries tailored to a chosen strategy — modernising to PaaS, migrating to Azure virtual machines, or rehosting to Azure VMware Solution — with readiness analysis, TCO and ROI comparisons, security insights, and cost-optimisation recommendations covering Azure Hybrid Benefit, reserved instances, and dev/test pricing. Wave Planning, added in November 2025, breaks a large migration into sequenced waves grouped by business criticality and application complexity, with progress tracking across each wave. Reserved tags, from April 2026, let you classify workloads as Prod, Dev, Test, or UAT and mark migration intent as Migrate, Retain, or Retire, and those tags feed directly into sizing and pricing rather than sitting as documentation.
Two 2026 additions deserve particular attention from anyone modernizing VMware at scale. Arc-based discovery, in preview since November 2025, assesses servers and SQL Server instances that are already Arc-enabled without deploying additional appliances, generating business cases within an hour. And the June 2026 integration with the GitHub Copilot modernization CLI brings code-level analysis into the portfolio view, so refactor-versus-replatform decisions come with effort estimates and code-fix recommendations rather than a consultant’s intuition. The Azure Migrate release history is the reference to check before assuming a capability does or does not exist, because the pace of change has been high.
Building the Business Case for Modernizing VMware
The Azure Migrate business case is the artifact that gets a modernizing VMware programme funded, and it is more capable than most teams realise.
It produces total cost of ownership for on-premises versus Azure including Azure VMware Solution, year-on-year cash flow analysis, utilisation-based insight into which workloads are genuinely cloud-appropriate, and quick wins around end-of-support Windows and SQL Server versions. It models Azure Hybrid Benefit for Windows Server and for RHEL and SLES subscriptions, savings plans for compute, and cost savings from Azure Backup, Azure Monitor, and Azure Update Manager replacing third-party equivalents. Since June 2025 it also produces sustainability insights, comparing on-premises emissions to Azure emissions with yearly reduction tracking — which matters if your organisation has ESG reporting obligations attached to infrastructure decisions.
The discipline that separates a business case that survives contact with finance from one that does not is honesty about what is excluded. Modernizing VMware does not eliminate guest OS licensing. It does not eliminate the backup software contract on day one. It does not eliminate the people, and in the first year it usually adds contractors. A business case that shows savings in month three is a business case that will be litigated in month nine.
The credible shape is a three-year model where year one is flat or slightly negative, year two shows infrastructure savings as the on-premises estate decommissions, and year three shows the compounding benefit of the modernizing VMware work that the relocation made possible. That model is harder to sell and much easier to defend.
Migration Mechanics: Modernizing VMware With HCX
VMware HCX is the recommended migration tool for moving on-premises vSphere workloads into an Azure VMware Solution private cloud, and Microsoft deploys HCX Cloud Manager on the cloud side with a fully configured compute profile as an add-on. HCX Enterprise has been included at no extra cost since February 2023, which brings Replication Assisted vMotion and Mobility Optimized Networking into scope for everyone rather than only for customers who bought the upgrade.
The customer side of the work is specific and non-trivial: download and deploy the HCX Connector OVA on-premises, pair it with the cloud manager, configure the network profile, compute profile, and service mesh, and then configure network extension or Mobility Optimized Networking. Network extension is the capability that makes modernizing VMware at volume tolerable, because it stretches Layer 2 segments from on-premises into the private cloud so that VMs keep their IP addresses across the move. Without it, every migration wave becomes a DNS and firewall-rule project.
HCX Cloud Manager can be reached over a public IP address, which matters for sites that are not connected to Azure by ExpressRoute or VPN, and which avoids the reduced tunnel MTU that double encapsulation over a VPN produces. Run Commands exist to restart and scale HCX Cloud Manager without a support ticket.
One constraint deserves flagging because it produces confusing failures late in a modernizing VMware programme. Adding AV64 nodes to a private cloud built on AV36, AV36P, or AV52 creates a heterogeneous EVC environment: AV64 clusters run Icelake EVC mode while the older SKUs have no explicit EVC mode. Live vMotion from a base cluster to AV64 works. Live vMotion back to a base cluster works only if the VM originated there and has not been power cycled; a VM created on AV64 or power cycled since the move will fail with an EVC compatibility error. The workarounds are to set VM-level EVC to match the lower cluster or to accept a cold vMotion, and both are much easier to plan for than to diagnose at 2am.
Modernizing VMware Identity with Microsoft Entra ID
Identity is the first thing modernizing VMware should address, and the thing most often deferred to phase three.
Since March 2026, Microsoft Entra ID integration for Azure VMware Solution has been generally available as an external identity source for vCenter. Before that, the practical options were vSphere SSO with an LDAP connection back to on-premises Active Directory, which meant the private cloud’s administrative access depended on a domain controller reachable over the ExpressRoute circuit — a dependency that is fine right up until the circuit is the thing that broke.
Moving vCenter authentication to Entra ID does three things at once for anyone modernizing VMware. It brings conditional access, multifactor authentication, and privileged identity management to the hypervisor administration plane, which is the highest-value credential in the estate and historically the least protected. It removes the on-premises dependency from the recovery path. And it puts vSphere administrative access into the same audit and access-review process as everything else, which is the difference between claiming administrative control in an audit and evidencing it — a distinction that matters enormously in the context of SOC 2 compliance evidence.
The sequencing advice is to do this early, ideally before the first production wave. Modernizing VMware identity after the estate has moved means re-running the access review against a larger surface with more stakeholders, and the work does not get easier.
Modernizing VMware Security Across the Whole Estate
The security argument for modernizing VMware onto Azure native services is not that the platform is more secure. It is that the estate stops being a separate security domain.
The platform baseline is solid before modernizing VMware adds anything to it. vSAN data-at-rest encryption is enabled by default, and customer-managed keys through Azure Key Vault have been available since February 2023 for organisations that need to hold their own master encryption keys. vSAN in-transit encryption became available through a Run Command in March 2025. Trusted Launch has been available across all Azure VMware Solution regions since November 2024, enabling virtual TPM on VMs, which is what unlocks Windows 11 and modern OS baselines on the platform.
Above the platform, the services that matter are the ones that treat AVS virtual machines identically to Azure virtual machines and Arc-enabled servers. Microsoft Defender for Cloud provides posture management and threat detection with Defender for Endpoint included. Microsoft Sentinel collects and correlates security events across the whole estate. Azure Update Manager handles OS patching for Windows and Linux. Azure Policy machine configuration audits settings inside the guest. Every one of those works across on-premises vSphere, Azure VMware Solution, and native Azure through the same agent and the same control plane.
That consolidation is the actual security outcome of modernizing VMware. Modernizing VMware in a way that leaves the migrated estate on a separate SIEM, a separate patching tool, and a separate posture-management product has moved the workloads without improving anything, and the detection and response benefits described in our analysis of AI-driven ransomware detection depend entirely on the telemetry being in one place.
Modernizing VMware Disaster Recovery: Closing the Second Data Centre
Disaster recovery is where the financial case for modernizing VMware is easiest to make and hardest to argue with, because the alternative is a building that exists to be idle.
Azure VMware Solution stretched clusters have been generally available since June 2023, delivering 99.99% uptime by spanning availability zones so that VMs and applications fail over automatically to an unaffected zone with no application impact. In May 2026, VMware Live Site Recovery for stretched clusters reached general availability, extending protection across regions with automated failover — which means a stretched cluster is no longer only a zone-resilience story.
The partner ecosystem carries the rest of what modernizing VMware resilience requires. VMware Live Site Recovery and vSphere Replication are Microsoft-deployed add-ons. Veeam, Commvault, Rubrik, JetStream, and Zerto all support the platform. Broadcom’s November 2025 addition of external storage as both source and target in vSphere Replication is being validated by Microsoft for non-vSAN Azure first-party storage, which closes a gap for estates using Azure NetApp Files or Elastic SAN datastores.
The strategic move is to stop running a second data centre for a scenario that has never occurred. Modernizing VMware with cloud-based recovery replaces a fixed cost that scales with the primary estate with a variable cost that scales with the protected estate, and for most organisations the protected estate is much smaller than the total. That is frequently the single largest line item in the entire business case.
Modernizing VMware Into PaaS: When a VM Should Stop Being a VM
Relocation buys adjacency. Adjacency is only worth something if you then use it, and this is the point where most modernizing VMware programmes quietly stop.
Azure Migrate assesses ASP.NET and Java Tomcat web applications for both Azure App Service and Azure Kubernetes Service, returning readiness, cluster right-sizing, and cost for each target, plus a TCO comparison between them in the business case. The app containerization tooling packages applications running on servers into container images and deploys them to App Service containers or AKS, with automatic Application Insights integration for Java applications and Key Vault for secrets. Since November 2025, GitHub Copilot code insights enhance those web app assessments with source-level analysis, and the June 2026 modernization CLI integration extends that to portfolio scale.
The honest framing is that the assessed population is smaller than the estate. Web tier applications on modern frameworks have clean PaaS destinations. A twelve-year-old .NET Framework application with a COM dependency and a licensed third-party control does not, and no amount of tooling will invent one. Modernizing VMware workloads into PaaS is a genuine opportunity for a slice of the portfolio and a distraction for the rest, and the assessment’s job is to tell you which is which before anyone commits.
The pattern that works for modernizing VMware applications is incremental decomposition rather than wholesale rewrite: move the monolith to Azure VMware Solution intact, identify the one or two components with clear boundaries and active development, lift those into AKS or App Service, and leave the remainder alone until there is a reason. That approach delivers value every quarter instead of promising it in eighteen months.
Modernizing VMware Databases: The Highest-Value Move
If there is one workload class where modernizing VMware pays for itself fastest, it is databases, and it is worth separating from the general application discussion.
Azure Migrate discovers and assesses SQL Server instances and databases — including Always On failover cluster instances and availability groups — and recommends across Azure SQL Managed Instance, SQL Server on Azure Virtual Machines, and Azure SQL Database, with readiness and cost for each. PostgreSQL discovery and assessment arrived in September 2025, MySQL in February 2025, and MongoDB in April 2026 with target guidance for Azure Document DB or MongoDB on Azure VMs.
The reason databases pay off disproportionately when modernizing VMware is licensing and operations rather than infrastructure. A SQL Server Enterprise instance running at 8% utilisation on a VMware host is consuming core licences that dwarf the hypervisor cost. Consolidating that onto a managed instance, or right-sizing it onto Azure VMs with Azure Hybrid Benefit, produces savings that show up immediately and do not depend on any application change. It also moves patching, backup, high availability, and point-in-time restore into the platform, which removes work rather than relocating it.
The caveat is that database migration is the workload class where application testing is genuinely required, and the temptation to fold it into the same wave as everything else should be resisted. Modernizing VMware infrastructure and modernizing the data tier are separate projects that happen to share a programme, and treating them as one is how migration windows get missed. The broader capability question — who owns the data platform after the move — is worth settling early, and it is the same question that sits behind data engineering and analytics as a managed service.
Azure Local: Modernizing VMware When the Workload Cannot Leave
Not every workload has a public-cloud destination, and modernizing VMware as though every workload did produces architecture that fails its first regulatory review.
Azure Local is Microsoft’s answer for workloads that must stay on-premises for latency, data residency, or sovereignty reasons while still being governed by the Azure control plane through Arc. Azure Migrate now supports direct VMware-to-Azure Local migrations using a dual-appliance architecture — a source appliance on the VMware side, a target appliance on the Azure Local side — with the control plane in the Azure portal. Analysis of enterprise deployments through late 2025 and early 2026 suggests moving from a traditional three-tier VMware architecture to Azure Local can reduce server footprint by around 50% and total cost of ownership by roughly 30% over five years.
The February 2026 addition of fully disconnected operation extends the option to environments where external connectivity is impossible or unacceptable. That is a significant capability, and it should also be approached with care: independent assessments of the disconnected variant published in 2026 flag material known issues, including AKS not functioning fully air-gapped, and note that the multi-rack option remains in preview and requires a persistent connection back to Microsoft. The variant that is genuinely disconnected is currently constrained in scale; the variant that scales is not fully disconnected.
The practical guidance for teams modernizing VMware with a genuine sovereignty requirement is to prove the specific workload on the specific variant before committing the architecture, and to keep Azure VMware Solution in the plan for everything that does not actually carry the requirement. Sovereignty constraints have a habit of expanding to cover workloads that were never in scope, and each one that does removes an option.
What Modernizing VMware Actually Costs
Cost conversations about modernizing VMware go wrong in a predictable way: someone compares an Azure VMware Solution node price to a depreciated server they already own, concludes the cloud is expensive, and the conversation ends.
The comparison that means something when modernizing VMware includes the VCF subscription either way, because Broadcom’s licensing model applies to on-premises hosts too. It includes the data centre facility, power, cooling, and the refresh cycle. It includes the second site for disaster recovery. It includes the backup software, the monitoring stack, and the security tooling that Azure services replace. And it includes the staff time spent on hypervisor patching, firmware updates, and capacity planning that Microsoft absorbs on the managed platform.
On the Azure side, the levers for modernizing VMware economically are substantial and frequently unused. Reserved instances at one, three, or five years deliver roughly 50% against pay-as-you-go. VCF BYOL nodes price below the old bundled arrangement and are available across all 35 AVS regions. Azure Hybrid Benefit applies Windows Server and SQL Server licences with Software Assurance, and extends to RHEL and SLES subscriptions. External datastores decouple storage cost from node count. Arc-based Extended Security Updates are pay-as-you-go on-premises and free for SQL Server on Azure VMware Solution.
The realistic expectation is that modernizing VMware is cost-neutral in year one, positive in year two once the on-premises estate decommissions, and clearly positive from year three as the modernisation work compounds. Programmes sold on immediate savings tend to have those savings extracted from the budget before they are realised, which is how a well-designed migration turns into an underfunded one.
The Skills Problem Modernizing VMware Exposes
There is a staffing dimension to this that rarely appears in the plan and reliably appears in the retrospective.
The team that runs vSphere well is not automatically the team that runs Azure networking, Azure Policy, Bicep templates, and Kubernetes well. Modernizing VMware onto Azure native services asks a virtualisation team to become a cloud platform team, and that transition takes 12 to 18 months of deliberate investment, not a two-day course. The organisations that skip it end up with an Azure VMware Solution private cloud administered exactly like the on-premises estate it replaced, which delivers the licence outcome and none of the platform outcome.
The specific gaps that modernizing VMware exposes are consistent: infrastructure-as-code, identity and conditional access, Azure networking constructs, cost management as an ongoing discipline rather than a procurement event, and container fundamentals. The good news is that the vSphere expertise remains directly relevant — Azure VMware Solution is still vSphere, and an engineer who understands storage policies, DRS, and NSX firewall design is enormously valuable during the migration itself.
The pattern that works is pairing rather than replacing: bring in cloud platform capability alongside the existing team for the duration of the programme, with an explicit knowledge-transfer expectation rather than an implicit one. This is the same structural problem we examined in the context of closing the AI and cloud technical skills gap, and the failure mode is identical: the capability arrives with the contractors and leaves with them.
Governance and Compliance While Modernizing VMware
Compliance obligations do not pause while you are modernizing VMware, and the transitional state — half the estate on-premises, half in Azure VMware Solution, both in scope — is the hardest one to evidence.
Azure VMware Solution carries the certifications that matter for regulated workloads. It is included in the Azure Commercial FedRAMP High provisional authorisation, was added to the Azure Government FedRAMP High P-ATO, holds DoD SRG Impact Level 4 authorisation, and was approved at Impact Level 5 within the DISA provisional authorisation of Azure Government in April 2025. The service does not store customer data, and vSAN data-at-rest encryption is on by default.
The governance work that modernizing VMware actually demands is more mundane. Every policy, every control mapping, and every piece of evidence collection has to work across both halves of the estate simultaneously for the duration of the programme. That is precisely the case for Arc-enabling the on-premises footprint before migrating any of it: if Azure Policy, Defender for Cloud, and Update Manager already cover the whole estate, the migration does not change the evidence story at all. If they do not, every wave creates a reconciliation problem.
Azure Migrate’s security insights help on the input side, auto-detecting unsupported operating systems and software, pending critical updates, known CVEs associated with installed software versions, and servers without security or patch management coverage — and, since March 2026, extending that assessment to discovered web apps and databases on end-of-support runtimes. Running that assessment early converts “we will fix it after the migration” into a costed line item, which is the only form in which it ever actually gets fixed.
The Modernizing VMware Rollout Roadmap
The sequence below is the one that consistently works for modernizing VMware. It front-loads the reversible decisions and defers the irreversible ones until there is evidence to support them.
Step 1: Arc-Enable the Existing Estate First
Before any migration planning, deploy the Azure Arc resource bridge against the existing vCenter and onboard the inventory. This costs almost nothing, changes nothing operationally, and gives a modernizing VMware programme an accurate, continuously synced inventory in the Azure portal from week one. It also starts the clock on Extended Security Update savings and gives the security team a single view months before the first VM moves.
Step 2: Run Discovery and Build the Business Case
Deploy the Azure Migrate appliance, enable software inventory and agentless dependency analysis, and let it run for at least 30 days to capture a genuine performance profile rather than a snapshot. Use reserved tags to classify environment and migration intent as the data arrives. Then build the business case for modernizing VMware against all three targets — Azure VMs, Azure VMware Solution, and PaaS — rather than the one you have already decided on.
Step 3: Settle the Licence Position
Model the portable VCF subscription across the target end state, not the current one. Decide whether reserved instances make sense for the AVS footprint and at what term. This step gates everything downstream because it determines the cost floor, and modernizing VMware without a settled licence position means every subsequent number is provisional.
Step 4: Design the Landing Zone and the Network
Choose Generation 1 or Generation 2 based on region availability and SKU fit, design the NSX segment and firewall topology, and settle the on-premises connectivity model — Global Reach, VPN, or a routed IaaS solution where Global Reach is unavailable. Every later stage of modernizing VMware inherits these choices. Size clusters for compute and datastores for capacity, separately. Leave internet access disabled.
Step 5: Modernise Identity and Security Before the First Wave
Move vCenter authentication to Microsoft Entra ID. Enable Defender for Cloud, Sentinel connectors, and Azure Update Manager across the Arc-enabled estate. Establish the Azure Policy baseline. Modernizing VMware identity and security before the first wave means every wave lands into a governed environment instead of creating a remediation backlog.
Step 6: Deploy HCX and Run a Pilot Wave
Stand up the service mesh, configure network extension for the segments in scope, and migrate a non-critical but representative application — ideally one with a database, a web tier, and a scheduled job, so the pilot exercises the real dependency patterns. Measure the cutover window against the estimate and correct the estimate before modernizing VMware at volume.
Step 7: Execute in Waves With Explicit Sequencing
Use Wave Planning to group workloads by application boundary and business criticality rather than by hostname or subnet. Sequence dependent workloads into the same wave. Track each wave to completion before starting the next two, and keep decommissioning of the source infrastructure inside the wave rather than deferring it to a cleanup phase that never gets scheduled.
Step 8: Modernise Selectively, With a Business Case Each Time
Only after the estate is stable in Azure VMware Solution should modernizing VMware workloads into PaaS start, and only against assessed candidates with an owner and a reason. Databases first, then actively developed web applications, then everything else — which for a large portion of the estate correctly means nothing at all.
Metrics That Matter When Modernizing VMware
Programmes for modernizing VMware generate enormous amounts of reporting and very little signal. These are the measures that predict whether the outcome will be good.
| Metric | What it tells you | Target shape |
|---|---|---|
| Percentage of estate Arc-enabled | Governance coverage independent of location | 100% before wave two |
| VMs discovered vs VMs in CMDB | Quality of the inventory you are planning from | Within 5%, investigated if wider |
| Decommission rate per wave | Whether savings are being realised or deferred | Source hosts retired inside the wave |
| Cutover window vs estimate | Whether the migration model is calibrated | Within 20% by wave three |
| Cluster CPU and memory utilisation | Whether sizing was driven by compute or storage | 60–75% steady state |
| Datastore split (vSAN vs external) | Whether storage cost is decoupled from node count | External for capacity-led workloads |
| Guest OS patch compliance | The responsibility Microsoft does not absorb | Unchanged or better post-migration |
| PaaS modernisation candidates assessed | Whether adjacency is being used or just acquired | Reviewed quarterly, not once |
| Reserved instance coverage | Whether the run-rate is optimised or drifting | Above 70% of steady-state nodes |
The one to watch hardest is the decommission rate. Modernizing VMware without retiring the source infrastructure doubles the cost of the estate and delivers nothing, and it is astonishing how often the decommissioning work is scheduled after the last wave, defunded, and never done.
Common Mistakes When Modernizing VMware
The failure modes in modernizing VMware are consistent enough to be worth naming individually.
Sizing the private cloud from storage. Terabytes drive host count under vSAN-only sizing, which buys cores nobody uses. Evaluate Azure NetApp Files, Elastic SAN, and Pure Storage Cloud in every sizing exercise, not as an exception.
Deploying three-host production clusters. It is the documented minimum and Microsoft explicitly recommends four, because at three hosts a maintenance-mode reboot blocks object creation. The saving is one node; the cost is a class of incident during every patch window.
Treating the migration as the modernisation. Modernizing VMware is not the same as relocating it, and moving a VM to Azure VMware Solution changes where it runs and nothing else. If nothing is scheduled after the move, the programme has bought adjacency and never spent it.
Deferring identity. Moving vCenter authentication to Entra ID after the estate has migrated means re-running the access review at a larger scale with more stakeholders. Doing it first costs a week.
Assuming Microsoft patches the guest. The shared responsibility matrix is explicit: Microsoft owns ESXi, vCenter, NSX, and vSAN. You own the operating systems, the antivirus, the backup agents, and the applications.
Ignoring the EVC constraint when adding AV64. Live vMotion back to a base SKU cluster fails for any VM created on or power cycled since arriving at AV64, and this surfaces as an inexplicable error during a maintenance operation rather than during planning.
Building for Generation 2 in a region that does not have it. Gen 2 is AV64-only with a defined region list. Designing around the absence of ExpressRoute in a region that still requires it produces a network design that has to be rebuilt.
Not budgeting the skills transition. A virtualisation team becoming a cloud platform team is a 12 to 18 month investment. Skipping it produces an Azure private cloud operated exactly like the data centre it replaced.
Leaving decommissioning to a cleanup phase. Source infrastructure that is still powered on is still consuming licence cores, power, and support contracts. Retire it inside the wave.
Where Modernizing VMware on Azure Still Falls Short
An honest assessment of modernizing VMware has to name the limits, because every one of them has caught a real programme.
The licence is not included and cannot be avoided. Azure VMware Solution runs VMware software and Broadcom charges for it. Modernizing VMware onto Azure changes who operates the platform and does not change who owns the intellectual property. Organisations whose primary objective is to stop paying Broadcom need a different destination — Azure IaaS, Azure Local, or PaaS — and should be clear about that from the start rather than discovering it at renewal.
Generation 2 is not everywhere. The simplified networking model is genuinely better and it is AV64-only across a limited region set. Most of the world is still designing around ExpressRoute Global Reach.
Host types are not mixable within a private cloud, with the AV64 expansion carveout, and that carveout brings its own EVC complications into any modernizing VMware plan. Estates with genuinely heterogeneous requirements end up with multiple private clouds and the operational overhead that implies.
Arc has a ceiling. 9,500 VMs per resource bridge against vCenter 8 is generous but finite, and the largest estates need a multi-bridge design from day one.
The population of workloads with a real PaaS destination is smaller than the marketing around modernizing VMware suggests. Assessment tooling covers ASP.NET, Java Tomcat, Spring Boot, SQL Server, PostgreSQL, MySQL, and MongoDB well. It does not cover the long tail of packaged applications, vendor appliances, and bespoke systems that make up a large share of most estates, and those workloads stay virtual machines indefinitely.
And the savings are back-loaded. Every credible model shows year one as flat. Any business case that shows otherwise has either excluded the licence, excluded the parallel running period, or excluded the people.
Frequently Asked Questions
Do I have to buy a VCF subscription from Broadcom to use Azure VMware Solution?
Yes, for any node purchased from 16 October 2025 onwards, and for all pay-as-you-go deployments from 1 November 2026. Microsoft stopped selling Azure VMware Solution with an included VCF subscription after 15 October 2025. Existing pay-as-you-go deployments with an included licence operate unchanged through 31 October 2026 and must supply a portable VCF licence key before that date. Reserved instances bought before the cutoff retain their original terms for the remainder of the commitment.
Is modernizing VMware onto Azure cheaper than staying on-premises?
Over three years, usually — but not in year one. The comparison has to include the VCF subscription on both sides, the facility, the refresh cycle, the disaster recovery site, and the tooling that Azure services replace. Reserved instances, VCF BYOL pricing, Azure Hybrid Benefit, and external datastores are the main levers. A model that shows savings in the first twelve months has almost certainly excluded the parallel running period.
Can I use Azure Arc without migrating anything?
Yes, and it is the recommended starting point for modernizing VMware. Azure Arc-enabled VMware vSphere connects to an on-premises vCenter through a resource bridge appliance, discovers the full inventory, and applies Azure governance, patching, security, and monitoring to VMs that never move. It supports vCenter 8 with up to 9,500 VMs per bridge and works identically against Azure VMware Solution private clouds.
What is the minimum Azure VMware Solution deployment?
Three hosts. A cluster requires a minimum of three and scales to 16, and a private cloud must use a single host type with AV64 expansion as the documented exception. Microsoft recommends four hosts rather than three for production vSAN clusters, because at three hosts a fault domain failure or maintenance-mode reboot protects existing data but blocks object creation.
Does Microsoft patch my virtual machines?
No. Microsoft deploys, patches, and upgrades ESXi, vCenter Server, NSX, and vSAN, and backs up vCenter and NSX Manager. You remain responsible for guest operating system installation and patching, antivirus, backup software, configuration management, application components, and VM networking on NSX segments. Azure Update Manager can take over guest patching once the machines are Arc-enabled.
How do I migrate the VMs themselves?
VMware HCX is the recommended tool for modernizing VMware onto Azure VMware Solution. Microsoft deploys HCX Cloud Manager on the private cloud side with a configured compute profile; you deploy the HCX Connector on-premises, pair the sites, and build the service mesh. HCX Enterprise, including Replication Assisted vMotion and Mobility Optimized Networking, has been included at no extra cost since February 2023. Network extension lets VMs keep their IP addresses across the move, which is what makes large waves practical.
Should every workload eventually become PaaS?
No. Stable, low-change applications with long lifespans and no development team are correctly placed on Azure VMware Solution permanently. PaaS modernisation pays where there is an active development team, a clean application boundary, and an assessed destination — most reliably for databases and actively maintained web applications. Modernizing VMware workloads into containers without those conditions is expensive and delivers little.
What if the workload cannot leave our data centre?
Azure Local is the designed answer for modernizing VMware under a residency constraint, managed through Arc so it stays in the same control plane. Azure Migrate supports direct VMware-to-Azure Local migration through a dual-appliance architecture. Fully disconnected operation arrived in February 2026 but carries documented constraints at scale, so prove the specific workload on the specific variant before committing the architecture.
How long does a typical programme take?
For a mid-sized estate of a few thousand VMs, modernizing VMware takes three to six months of discovery, licence modelling, and landing zone design before the first production wave, then 9 to 18 months of migration waves, with PaaS work running continuously afterwards. The variable that moves the timeline most is not the technology; it is how quickly application owners can be assembled to make decisions about their own workloads.
Final Verdict
The licence deadline is real, and it is the reason modernizing VMware is being discussed now rather than in 2028. But treating 1 November 2026 as the objective produces a procurement outcome and nothing else. The organisations that get value from this moment are the ones that use a forced renewal to reopen questions that had been closed for a decade.
Modernizing VMware using Azure native services works best as a sequence rather than an event. Arc-enable the estate so governance stops depending on location. Assess honestly, including the workloads that should be switched off. Settle the licence position against the target end state. Migrate with HCX into a landing zone where identity and security are already correct. Then, and only then, start replacing the parts of the stack that Azure genuinely does better — storage that scales independently of compute, disaster recovery that does not require a second building, patching that is a policy rather than a project, and eventually application runtimes for the slice of the portfolio that warrants it.
The estate that comes out the other side of modernizing VMware is not defined by having left VMware. Plenty of it will still be vSphere, correctly. It is defined by having one control plane, one identity provider, one security surface, and one place where decisions about placement and cost get made. That is what cloud-first architecture actually means, and modernizing VMware is simply the most expensive and most visible step towards it.
References
Microsoft, Introduction to Azure VMware Solution — host specifications, cluster limits, shared responsibility matrix, and software versions.
Microsoft, What’s new in Azure VMware Solution — platform update history including Generation 2 general availability, Entra ID integration, and storage options.
Microsoft, Azure VMware Solution in an Azure Virtual Network — the Generation 2 architecture and its region and SKU constraints.
Microsoft, What is Azure Arc-enabled VMware vSphere? — resource bridge architecture, supported scenarios, and scale limits.
Microsoft, What’s new in Azure Migrate — Reports, Wave Planning, reserved tags, Arc-based discovery, and Copilot integrations.
Microsoft, Build a business case with Azure Migrate — TCO modelling, cash flow analysis, and sustainability insights.
Microsoft, Create an Azure VMware Solution assessment — supported SKUs and sizing methodology.
Microsoft Community Hub, Broadcom VMware licensing changes: what Azure VMware Solution customers need to know — the authoritative statement of the licensing timeline.
Microsoft Community Hub, Broadcom VMware licensing changes: what Azure VMware Solution partners need to know — the partner-facing detail on BYOL availability and pricing.
Microsoft Azure, Migrate and modernize VMware in Azure — the product-level framing of the modernisation paths.
Network World, Some enterprises are dropping VMware, just not all at once — survey data on footprint reduction, pricing increases, and migration targets.
