VMware vs Azure Local which platform makes more sense now?
We compare VMware and Azure Local against your applications, hardware, licensing and the work of changing platforms. For workloads that need to stay local, we look at what the chosen platform will cost to run, how it will be recovered and who will operate it after cutover.
- vSphere and vCenter
- Established application integrations
- Product and subscription terms
- Application support
- Availability and recovery
- Operating capability
- Whole-of-life cost
- Local compute and storage
- Azure Arc management
- Validated hardware and deployment model
Choose around the workloads you need to run
Both platforms can run Windows and Linux workloads. We check the application vendor's support requirements, the services each workload depends on and the operating capability behind the platform before favouring either option.
Azure Local fits a deliberate move into Microsoft infrastructure
Azure Local is a strong candidate where local processing, latency or site operations still matter and your team wants to manage that infrastructure through Azure and Microsoft tooling. The case is stronger when the hardware refresh, application support, licensing position and migration window line up.
VMware can remain the better operating choice
An established VMware environment may have specialist appliances, network services, backup integrations or application support that would be costly to replace. Keeping it can make commercial sense when the renewal is workable and the platform still meets your needs, including any hardware replacement and software upgrades needed to stay supported.
The estate can move in stages
Some applications may stay on VMware while others move to Azure Local, Azure or a replacement SaaS service. A staged transition can protect a critical system's operating window, but it also creates a period of duplicated licensing, capacity and administration. We cost that overlap before treating it as the safer option.
VMware and Azure Local, side by side
The VMware product and the Azure Local deployment model both matter. We compare the actual subscription, architecture and support requirements being proposed, rather than treating either name as a fixed bundle.
| Area | VMware | Azure Local |
|---|---|---|
| Compute and hardware | vSphere on supported servers. Reuse depends on the target software version and hardware compatibility. | Hyper-V on validated Azure Local systems. An existing server must meet the supported configuration, including firmware and drivers. |
| Storage | Supported external storage or vSAN, with features and capacity entitlement checked against the product being licensed. | Storage Spaces Direct in hyperconverged systems. Qualified external SAN options have their own configuration and eligibility requirements. |
| Management | vCenter and VMware tooling operate the virtual infrastructure. Additional components depend on the product and design. | Azure Arc, the Azure portal and automation tools connect to local infrastructure. Local administration remains part of operations. |
| Azure integration | Azure Arc can connect supported VMware environments and guest operating systems to Azure management services. | Azure registration and management are part of the standard connected deployment. Optional Azure services still need configuring and costing. |
| Licensing | VCF and VVF use physical-core subscription licensing. Guest operating systems and applications need separate consideration. | Azure Local service charges are based on physical cores. Windows Server guest licensing and eligible Azure Hybrid Benefit affect the total. |
| Connectivity | Local workloads are governed by the deployed architecture. Azure-connected features have their own connectivity requirements. | The standard connected deployment needs regular Azure communication. Disconnected operations is a separate design and commercial path. |
| Availability and recovery | Cluster availability, backups and disaster recovery need a design for the supported VMware and backup versions. | Failover clustering, backup and site recovery are designed around the supported Azure Local configuration. |
| Work of changing | Keeping VMware can avoid a hypervisor conversion, while still requiring upgrades or hardware changes. | Moving from VMware needs migration planning, guest and application checks, recovery testing and a change in platform operations. |
Azure Arc also supports VMware
Azure governance is available without changing hypervisor. Arc-enabled VMware vSphere connects supported vCenter environments through an Arc resource bridge, while the Arc agent can bring supported guest operating systems into Azure services. We check the version and feature requirements before using Azure integration as a reason to move.
What Azure Local changes in your local environment
Azure Local runs workloads on infrastructure at your sites and connects that infrastructure to Azure management. Its hyperconverged platform builds on Azure Stack HCI, combining Hyper-V, Storage Spaces Direct and Failover Clustering. The wider Azure Local family includes deployment options with different hardware, connectivity and commercial requirements.
Validated hardware and a defined storage design
In a hyperconverged design, servers provide compute and local drives that Storage Spaces Direct combines into shared storage. We size CPU, memory, usable capacity and network throughput for the workloads, including the capacity needed during a host failure or maintenance.
Qualified Fibre Channel and iSCSI SAN configurations are also available. Existing servers and SANs aren't automatically reusable, so we check the exact system, adapters, disks, firmware, drivers and storage configuration against the supported solution, then price reuse against replacement.
Azure management with local operating responsibilities
Azure Arc connects the registered environment to Azure. The portal, command-line tools and deployment templates can provision and manage resources, with role-based access controlling who can do what. Windows Admin Center and PowerShell remain useful for local administration.
Azure Monitor, Azure Policy and Microsoft Defender services need the relevant configuration, permissions and licensing. We define which controls apply to the platform, which apply inside the guest and who responds when a check fails. Joining Azure doesn't put those operating arrangements in place by itself.
Connectivity is part of the architecture
Existing virtual machines can keep running during a loss of Azure connectivity, while portal actions and other cloud-dependent functions may be unavailable. In the standard connected deployment, 30 consecutive days without Azure connectivity puts the system out of policy and prevents new virtual machines being created until it synchronises again.
For an environment that must stay disconnected, Azure Local disconnected operations needs a separate local control plane, supported hardware and qualifying commercial and support arrangements, with its own design and cost model.
Local workload data and Azure management data
Workload data stays on the local infrastructure unless a configured service moves or copies it elsewhere. Management metadata and selected monitoring data can be sent to Azure, and cloud backup and replication create further data flows. We document those flows against your residency, access and retention requirements.
Azure Local licensing vs VMware, and the full cost of changing
We compare both options over the same operating period, including the hardware lifecycle and migration overlap. A lower platform fee can be outweighed by new hardware, application changes or the cost of keeping two environments running.
The VMware quote and the capacity it covers
For VCF and VVF, physical processor cores set the subscription count, with a minimum of 16 cores per processor under Broadcom's published counting guidance, and disabling cores in the BIOS doesn't reduce it. We also check the product, term, support and any vSAN raw-storage entitlement against the quote.
Moving virtual machines only reduces the VMware licence requirement if it lets the licensed host or physical-core count fall, subject to the applicable terms, so a lower VM count isn't treated as a saving by itself.
Work through the VMware renewal and exit options →Azure Local fees and Azure Hybrid Benefit
The Azure Local service is charged by physical core through Azure. Windows Server guest licensing, hardware, support and any Azure services used alongside it are added separately.
Eligible Windows Server Datacenter licences with active Software Assurance can cover the Azure Local service fee and Windows Server guest subscription fees through Azure Hybrid Benefit, once the licences are allocated across the physical cores and the benefits activated. The benefit applies to the qualifying cloud-connected hyperconverged configuration without external storage, so we check eligibility before counting the saving and keep the ongoing Software Assurance cost in the comparison.
The costs that sit outside either platform fee
We include Windows Server and SQL Server entitlements, application licences, backup capacity, disaster recovery, monitoring, network changes and hardware support. The migration allowance covers conversion tools, testing, parallel operation, staff training and the work of retiring the old environment.
Where eligibility or pricing is unconfirmed, we show the effect on the total, and commitments that continue after cutover stay in the business case.
Read how cost signals inform infrastructure decisions →Updates, recovery and support need an owner
Host maintenance and guest patching are separate tasks
On Azure Local, we plan platform updates around health checks, available cluster capacity and the hardware vendor's supported firmware and driver process, with room to take a host out of service when maintenance needs it.
Hotpatch can reduce restarts for eligible Windows Server guest images, but baseline updates still need restarts and Hotpatch doesn't remove host maintenance. Platform servicing, guest patching and application maintenance stay distinct in the operating plan.
Recovery has to work beyond a host failure
Cluster failover can restart affected virtual machines on another host. Backup and disaster recovery cover corruption, deletion, cyber incidents and the loss of a site, so we check restore support, retention, application consistency and the time needed to recover the required services together.
Azure Site Recovery can replicate supported Azure Local virtual machines to Azure. The design still needs compatible guest and disk configurations, network access, identity and DNS, test failover and a workable return, and replication doesn't replace an independent backup.
Review Backup and Disaster Recovery →Platform, hardware and application support must join up
We define who handles cluster health, guest issues, hardware faults, patching and vendor escalation. Azure Local brings Microsoft platform support, the hardware provider and application vendors into that arrangement, and VMware needs the same clear ownership across its stack.
The handover includes access, configuration records, monitoring, maintenance procedures and tested recovery instructions, with the ongoing operating scope agreed before cutover.
Prove the move before committing the estate
A VMware-to-Azure Local migration changes the virtualisation platform as well as the management model. We use a representative migration to test the method and expose constraints before scheduling the critical systems.
Check the application and guest configuration
We verify vendor support, operating system versions, boot mode, disk layout, encryption and guest drivers. Specialist appliances, attached devices and licences tied to the existing virtual hardware can change the migration method or keep a workload on VMware.
Move connected services in a workable order
Identity, DNS, IP addressing, firewall rules, service accounts, databases and application integrations set the sequence. We agree outage windows and acceptance checks with the people who use and own the systems, then measure the actual transfer and validation time in the pilot.
Define recovery and the limits of rollback
We test backup and restoration on the destination and keep access to historical recovery points where required. The cutover plan identifies the last safe rollback point and how data written after the move would be handled, because turning the old virtual machine back on may not restore a consistent application.
Timing can change the decision
A platform can be the better long-term fit and still be the wrong immediate move under the current migration window.
A VMware renewal, a smaller retained estate or Azure VMware Solution may provide a workable transition period. AVS continues to use VMware, so its Azure infrastructure and VMware licensing costs remain part of that decision.
Read why VMware exit is a workload placement decision →See what we've delivered for our clients
nodes in the VMware estate
virtual server workloads migrated
landing paths assessed before selection
VMware vs Azure Local questions we hear most
Is Azure Local the same as Azure Stack HCI?
Azure Stack HCI is now part of Azure Local. The hyperconverged platform carries that technology forward, while Azure Local covers a wider family of deployment options. We check the specific deployment model because connectivity, hardware and licensing benefits vary.
Is Azure Local a direct replacement for VMware?
It can replace VMware for supported workloads, but the move involves a different hypervisor, management model and migration process. Application support, virtual networking, storage, backup and operating skills all need checking before the destination is confirmed.
Is Azure Local cheaper than VMware?
It can be, particularly where eligible Microsoft licences reduce platform and guest fees. We compare the complete cost over the same period, including hardware, migration, coexistence and ongoing operations. The result depends on the estate and the actual commercial terms.
Can we reuse our existing servers and storage?
Possibly. Azure Local needs a supported system and configuration, and external storage must qualify for the selected deployment. We check the exact hardware, firmware and storage design before including reuse in the budget, and licensing benefits may differ when external storage is used.
Does Azure Local need a constant internet connection?
No, but it does need to connect regularly. Running virtual machines carry on through a short outage. Over a longer one, the standard deployment allows 30 days without syncing to Azure before it goes out of policy and blocks new VMs until it reconnects. Sites that must stay offline need the separate disconnected operations design.
Can Linux workloads run on Azure Local?
Yes. Azure Local runs supported Linux distributions as well as Windows Server. Vendor support, guest drivers and backup coverage are confirmed for each Linux workload, the same as for Windows.
Do we need Azure Local to manage VMware from Azure?
No. Azure Arc can link a supported vCenter, and the virtual machines it runs, to Azure policy, monitoring and management without changing hypervisor. It's worth confirming which Arc features your VMware version supports before treating Azure management as a reason to move.
Do all workloads have to leave VMware at once?
No. We can plan a staged move around application dependencies, support constraints and the renewal date. Any retained VMware capacity and the cost of running both platforms stay in the plan until they can be retired.
If VMware and Azure Local are both options, review the estate first
Bring us your VMware quote, host inventory and application constraints. We'll compare the viable paths, then design, migrate and operate the agreed environment.
Prefer email? contact@inlightit.com.au