Azure Local is not just a VMware alternative. It is a different operating model for modern on-premises infrastructure.
Azure Local has become a serious platform option for organisations reviewing VMware renewal pressure, ageing infrastructure, sovereignty requirements, workload placement or the next local infrastructure cycle. It is not public cloud replacing local infrastructure. It is Microsoft's Azure-connected infrastructure platform for customer-owned environments, using Azure Arc as the control plane and bringing Azure-consistent management, governance, monitoring and security to workloads that still need to run locally.
See when Azure Local actually fitsWhat it is. Azure Local is Microsoft's Azure-connected infrastructure software for customer-owned environments, formerly known in many buyer conversations as Azure Stack HCI. It runs on-premises or in customer-controlled locations, is managed through Azure Arc, and is billed through Azure on a per-physical-core basis. Best fit: usually strongest for Windows-heavy estates with local infrastructure requirements that want a more Azure-aligned operating model — especially where Azure Hybrid Benefit applies and the organisation is already standardised on Microsoft tooling. Not automatic: hardware requirements, licensing position, workload mix, migration risk and operational capability all affect whether it fits better than Nutanix, Proxmox, retained VMware, AVS or direct Azure migration. Six variables to test: workload fit, lifecycle timing, commercial model, migration risk, post-cutover operating model, and support posture after go-live.
Azure Local is strongest when local infrastructure still matters and the organisation is already Microsoft-aligned.
Azure Local is one of the strongest modern on-premises platform options when three things are true:
- the organisation still has a real reason for workloads to stay local
- Microsoft and Azure are already central to the operating model
- Azure-consistent management improves governance, monitoring, security and supportability
It is not compelling because it is new. It is compelling when Azure alignment improves the operating model, Azure Hybrid Benefit improves the commercial case, and local control still matters for latency, sovereignty, resilience or operational continuity. Where those conditions are missing, another platform may be better. The question is not whether Azure Local is newer — it is whether Azure Local fits the estate better than VMware, Nutanix, Proxmox, Azure VMware Solution or selective migration to Azure.
What Azure Local actually is.
Azure Local extends Azure capabilities into local environments. It is designed for customer-owned infrastructure — including local datacentre, distributed, edge and sovereignty-sensitive environments where workloads need to remain close to users, systems, data or operations. It is managed through Azure Arc and integrates with Microsoft tooling such as Azure Policy, Microsoft Defender for Cloud, Azure Monitor, the Azure portal, Azure CLI, Azure PowerShell and Azure Resource Manager templates.
Azure Local is not just a hypervisor decision — it is a platform and operating-model decision. The practical question is whether the organisation wants on-premises infrastructure managed in a more Azure-consistent way.
Azure Local includes:
- Azure Arc as the unifying control plane across local infrastructure
- Azure portal, CLI, PowerShell and ARM template-based management
- Azure Policy integration
- Defender for Cloud integration
- Azure Monitor integration
- Support for connected and disconnected deployment modes
- Hyperconverged deployments as a core model
- Azure-consistent management across local and Azure workloads
What hyperconverged means in this context.
For most organisations assessing Azure Local, the practical interest is HCI: hyperconverged infrastructure. That means compute, storage and virtualisation are consolidated on a modern local platform rather than run as separate siloed infrastructure layers. With Azure Local, that HCI model is combined with Azure-connected governance and management. The appeal is not only consolidation — it is a cleaner operating model for local workloads.
In practice, hyperconverged means:
- Compute, storage and networking consolidated on the same hardware nodes
- A single platform to manage rather than separate siloed layers
- Scaling from single-machine deployments to multi-node clusters as requirements grow
- Hardware validated through Microsoft's OEM partner program
- Azure-connected management over local workloads
- A more modern operating pattern than traditional VMware-era three-tier infrastructure
Why organisations are looking at Azure Local now.
Azure Local becomes relevant when organisations are reassessing VMware, refreshing host infrastructure, modernising local operations, or deciding which workloads should stay local rather than move directly to cloud. It is rarely one pressure by itself — the common triggers arrive together:
- VMware renewal pressure forcing a broader platform review
- Host infrastructure approaching end of useful life
- Workload placement decisions requiring a structured local option
- Sovereignty or compliance requirements keeping workloads on-premises
- A desire for Azure-consistent management without full cloud migration
- Infrastructure modernisation needing a structured local landing path
- Business continuity requirements that rely on local compute
- Low-latency systems that need to remain close to data or operations
Azure Local is not relevant because every organisation needs it. It is relevant because many organisations now need a better answer for workloads that still need to remain local. If renewal pressure is the driver, start with Broadcom VMware renewal or VMware exit strategy; if hardware lifecycle is the driver, see server replacement strategy; if placement is the open question, see VMware workload placement.
Where Azure Local usually fits well.
Azure Local is usually a strong fit where the environment is Windows-heavy, the organisation still needs on-premises control, and Azure governance patterns already make sense across the broader environment. It is not the right answer because the organisation uses Microsoft — it is the right answer when Microsoft alignment, local control and hybrid management are all genuine requirements.
- Windows-heavy virtualised environments
- Standard line-of-business application workloads
- Local workloads with low-latency requirements
- Workloads that need to remain close to users, sites, equipment or data
- Sovereignty-sensitive or compliance-sensitive workloads
- Organisations already using Microsoft tooling and governance widely
- Environments where Azure Arc, Azure Policy, Defender for Cloud and Azure Monitor fit the operating model
- Infrastructure refresh decisions where a modern local platform is needed
- Staged VMware exit paths where local control still matters
- Organisations that want cloud-consistent management without moving everything into Azure
- Environments where Azure Hybrid Benefit materially improves the commercial case
Azure Local is strongest when the business still needs local infrastructure but wants that local infrastructure to operate inside a Microsoft-led governance model.
Where Azure Local is not the right answer.
Azure Local is not automatically the best local platform just because the organisation already uses Microsoft. It can be the wrong answer where Azure is not the desired control-plane anchor, the environment is not strongly Microsoft-oriented, or another private-platform direction is a better long-term fit — and it can be the wrong immediate move if the environment is too entangled, poorly documented, or not ready to transition safely under current time pressure.
- The organisation does not want Azure to be central to the operating model
- The environment is not materially aligned to Microsoft tooling or governance
- Azure Hybrid Benefit does not apply and the commercial case weakens
- The workload mix is Linux-heavy or non-Microsoft-heavy
- Local infrastructure no longer has a strong role
- HCI-certified hardware cost is not commercially justified for the estate size
- Migration risk is too high under current renewal or refresh pressure
- Nutanix or another private-platform direction is a better fit
- Support ownership after cutover is unclear
- No one has Azure or Windows Server depth to run it after go-live
Those are not Azure Local problems — they are fit and timing problems. The platform should be assessed against the actual environment, not selected by default. See Azure Local vs Nutanix.
The management model is one of Azure Local's biggest differentiators.
Azure Arc changes what local infrastructure can do without requiring workloads to move to cloud. Azure Local allows administrators to provision and manage Windows and Linux VMs hosted locally using Azure management tools — the Azure portal, Azure CLI, Azure PowerShell and Azure Resource Manager templates — and it integrates with Azure Policy, Defender for Cloud and Azure Monitor. It supports RBAC, self-service capabilities and a single view across Azure Local VMs and Azure VMs.
That matters for organisations already standardised on Microsoft governance and operations. The attraction is not only that workloads remain local — it is that local infrastructure can sit inside a more modern Azure-consistent management model.
That management model includes:
- Azure portal, CLI, PowerShell and ARM management
- RBAC and role-based administration
- Self-service VM provisioning
- A single view across Azure Local and Azure VMs
- Azure Policy enforcement
- Defender for Cloud integration
- Azure Monitor integration
- Azure Arc-enabled management
- Copilot for Azure support where appropriate
Azure Local changes day-two operations.
Azure Local does not manage itself. The platform can make parts of the operating model stronger, but it still needs disciplined ownership after go-live, and the operating model should be defined before the project begins rather than inherited from the old one. Azure Local changes the tools and the approach — it does not remove responsibility for patching, monitoring, recovery, lifecycle management or incident response.
Windows Server 2022 and 2025 on Azure Local support Hotpatch, which applies critical operating system updates in memory without a host reboot. Cluster-Aware Updating handles host firmware and driver updates in a rolling sequence with no workload downtime. Patching becomes more structured, but it still requires a defined schedule and ownership.
Azure Local requires HCI-certified hardware from OEM partners. This limits hardware choice, but it also clarifies support boundaries across OEM hardware, Microsoft platform support and the MSP or internal operations layer. Firmware updates are coordinated, not improvised.
Azure Monitor and Microsoft Defender for Cloud are integrated into the operating model, so host health, cluster performance and security posture can surface through Azure management tooling. The team gains visibility that many legacy three-tier environments do not have, but someone still needs to respond to what monitoring shows.
Azure Site Recovery integrates directly with Azure Local for VM replication to Azure, and cluster-level failover handles host failures automatically. The recovery story can be strong, but RTO and RPO expectations still need to be tested against actual workload dependencies.
Microsoft supports the Azure Local platform and Azure Arc management layer; the OEM supports the physical hardware; guest operating system and application support follow standard Microsoft or vendor agreements; and the MSP or internal team owns the operational layer between them. Knowing which boundary applies to which incident matters before something breaks.
The support model needs to be designed before go-live.
Azure Local's support model is clearer when it is designed properly. It becomes messy when everyone assumes someone else owns the hard middle layer. A serious Azure Local operating model needs:
- Microsoft or Azure infrastructure capability
- OEM hardware support for HCI-certified nodes
- Documented responsibility for Azure Arc and Azure Policy
- Ownership for Defender for Cloud and Azure Monitor configuration
- A defined patching and update cadence
- Firmware and driver update ownership
- Backup and recovery ownership
- Escalation paths across Microsoft, OEM, MSP and internal IT
- Post-cutover documentation and runbooks
- Incident response ownership during Australian operating hours
The platform may be Azure-connected. The accountability still needs to be local and practical.
The commercial model is different from traditional on-premises licensing.
Azure Local is billed through Azure and appears on the Azure subscription bill like other Azure services. The standard model is per physical processor core in an Azure Local instance, with additional charges where Azure services are consumed alongside the local platform. No traditional on-premises software licence is required for the Azure Local host platform itself, although guest VMs may still require operating system licensing. That makes the commercial model different from legacy platform buying — and it still needs to be assessed properly against hardware, guest licensing, support model and likely three-year operating cost. Azure Local is not automatically cheaper; it is a different model.
Azure Hybrid Benefit. Eligible Windows Server Datacenter licences with active Software Assurance can waive the Azure Local host service fee and the Windows Server guest subscription fee, which Microsoft lists at $23.30 per physical core per month. Combined with Reserved Instance pricing, Microsoft cites potential compute savings of up to 80% compared with standard pay-as-you-go rates. Where Azure Hybrid Benefit applies, it can materially change the commercial case; where it does not apply, Azure Local may look very different against Nutanix, Proxmox or a retained VMware path.
The commercial comparison should include:
- Azure Local host service fees
- Windows Server guest licensing
- Azure Hybrid Benefit eligibility
- Software Assurance status
- Hardware cost and lifecycle timing
- HCI-certified hardware requirements
- Support model and operational overhead
- Azure services consumed alongside Azure Local
- Backup tooling and recovery design
- Monitoring and security tooling
- Migration effort and sequencing
- Three-year operating cost across all components
The business case should be tested before the platform is chosen.
What breaks the Azure Local business case.
The business case is strongest when several conditions align: a Microsoft-heavy estate, eligible licensing, a workload profile that suits HCI, local infrastructure still genuinely required, and an operational team or MSP able to run the platform properly. When those conditions are absent or assumed rather than verified, the case can unravel.
Azure Local's strongest commercial and operational position depends on Microsoft alignment. If Azure is not the desired management anchor, the platform may create more operating change than value.
Hybrid Benefit can materially improve the economics. Without eligible Windows Server Datacenter licences with active Software Assurance, the host fee and guest subscription fee apply in full, and the comparison to Nutanix, Proxmox or VMware may look different once Hybrid Benefit is removed from the model.
Azure Local is strongest for the right kind of local workload. Linux-heavy estates, workloads that do not benefit from Azure governance, or environments where local infrastructure is not genuinely required may suit another platform better.
Azure Local's management advantages require someone who knows how to use them. An organisation that selects Azure Local but has no Azure infrastructure depth may run the platform below its capability and above its difficulty.
Azure Local requires HCI-certified hardware. Modelling the business case on commodity server prices or assuming any existing hardware can be reused will underestimate the total investment — the hardware cost must be in the model from the start.
Connectivity and deployment reality.
Azure Local is generally deployed as a cloud-connected product. For hyperconverged deployments, Azure Local must sync successfully with Azure at least once every 30 consecutive days; if sync does not occur within that period, the cluster enters reduced functionality mode, where current VMs continue running but new VMs cannot be created until sync is restored. That is an important design detail — Azure Local can tolerate temporary disconnection, but the connected operating model still needs to be understood. Microsoft also supports disconnected operations for permanently disconnected requirements, which matters for environments with remote sites, limited connectivity, air-gapped needs or sovereignty constraints.
- Azure Local syncs with Azure at least once every 30 days
- If sync fails beyond that period, the cluster enters reduced functionality mode
- Current VMs continue running
- New VM creation is suspended until sync is restored
- Available where cloud sync is not possible as a standard operating condition
- Relevant for air-gapped environments
- Relevant for sovereignty-constrained environments
- Relevant for remote sites with limited connectivity
Azure Local is not pretending local conditions do not exist. The platform is designed for local realities, but the connectivity model must be designed properly.
The strongest candidates need local performance, control or continuity.
The strongest Azure Local candidates are workloads that need local performance, local control or local continuity while still benefiting from Azure-aligned governance, monitoring and security. Azure Local is often well suited to:
- Local production systems with operational dependency
- Windows-heavy line-of-business workloads
- Latency-sensitive services that should not sit far from the point of use
- Workloads that need to remain close to where data is generated
- Workloads with sovereignty or local-control requirements
- Environments that need continuity through network outages
- Organisations wanting Azure-consistent governance for local infrastructure
- Staged hybrid environments where not everything belongs in public cloud
- VMware workloads moving to a modern local platform rather than directly to cloud
Azure Local is usually weaker when workloads are better suited to SaaS, Azure-native services, or a cloud-managed platform that removes the need for local infrastructure entirely. That is why Azure Local should be considered alongside workload placement, not before it — see also Azure vs on-prem vs hybrid and hybrid infrastructure workload migration.
Migration and implementation reality.
A good Azure Local strategy is not just about choosing the platform — it is about shaping the transition properly. The most common mistake is treating Azure Local as a simple swap. Even when Azure Local is the right destination, the quality of the outcome depends on workload sequencing, host timing, rollback planning, backup posture and post-cutover support model. In practice, Azure Local works best when the organisation has already worked out which workloads should stay local, how tightly they depend on surrounding systems, and what the post-cutover operating model should be — which is why it often sits best inside a broader infrastructure review rather than as a standalone purchase.
A good Azure Local implementation should address:
What moves first and what stays on VMware while the target is validated.
Whether refresh and migration happen together or separately.
Explicit fallback logic before any production move.
How backup and recovery work during the transition.
Who owns operations after go-live.
Confirming Azure Hybrid Benefit eligibility before commitment.
Confirming HCI-certified hardware and OEM support pathway.
Azure Monitor, Defender for Cloud and alert response ownership.
Patching, firmware, driver and cluster update discipline.
Azure Local in recent infrastructure decisions.
Azure Local is increasingly part of real infrastructure refresh and VMware exit decisions. In recent infrastructure review work, Azure Local has been shortlisted where the environment required local control, Microsoft-aligned governance and clearer host refresh direction. The decision was not made because Azure Local was the newest option — it was tested against workload fit, licensing position, migration risk and post-cutover support before the landing path was locked.
That is where Azure Local belongs in the decision process: not as a default VMware replacement, but as one of the serious local platform options to test when retained workloads still need a modern operating model.
Where Inlight IT fits in this decision.
We assess Azure Local as one option, not the preferred destination. Inlight IT assesses it as part of infrastructure platform, VMware exit and infrastructure refresh work, and the recommendation follows the estate: workload profile, licensing position, commercial logic, migration risk and supportability after go-live.
We assess Azure Local, Nutanix, Proxmox, AVS and VMware retention together, because Azure Local should not be assessed in isolation — it needs to be compared against the real option set. We validate Azure Hybrid Benefit before it influences the commercial case, because Hybrid Benefit can materially change the business case and should be checked before the recommendation depends on it. We connect platform review with migration and support, so assessment, design, cutover and support stay connected and the platform decision is grounded in what can actually be delivered and operated after the change. And we will say when Azure Local is not the best fit: if Nutanix, Proxmox, retained VMware, AVS, direct Azure migration or a simpler refresh gives the business a stronger outcome, that is stated clearly.
Azure Local is credible. It is not universal. The recommendation follows the estate, not the platform.
If Azure Local made the shortlist because of the renewal date rather than the workload profile, licensing position and post-cutover support model, the fit has not been tested yet.
Test it inside an infrastructure refresh review →What this usually leads to next.
Azure Local usually connects to a broader infrastructure decision.
- If Azure Local looks like the right direction — the next step is usually a structured review against the real option set. See Infrastructure Refresh.
- If Azure Local and Nutanix are both on the shortlist — see Azure Local vs Nutanix.
- If VMware renewal pressure is driving the decision — see Broadcom VMware renewal and VMware exit strategy.
- If workload placement is unclear — see VMware workload placement and Azure vs on-prem vs hybrid.
- If migration sequencing is the main risk — see hybrid infrastructure workload migration.
Azure Local questions we hear most.
Is Azure Local the new name for Azure Stack HCI?
Is Azure Local public cloud?
How is Azure Local billed?
Does Azure Local require cloud connectivity?
What does Azure Hybrid Benefit do for Azure Local?
What workloads is Azure Local good for?
Is Azure Local just for edge sites?
Can existing hardware be reused?
Is Azure Local cheaper than Nutanix or VMware?
Where does Azure Local sit in Inlight IT's Cloud and Infrastructure structure?
If Azure Local is on the shortlist, check before you commit.
Confirm whether it fits the workloads, recovery model and team.
Talk through your infrastructure refresh options