Is Azure Local the same thing as Azure Stack HCI?

Yes. Microsoft renamed it, and you can verify that yourself in one step: the old documentation URL, learn.microsoft.com/en-us/azure-stack/hci/, now returns a redirect to learn.microsoft.com/en-us/azure/azure-local/. That matters practically rather than academically, because any evaluation you did before the change, any vendor deck in your file, and any internal business case will still carry the old name. One caveat worth knowing: the rename applies to the solution, not to every component. Microsoft's current documentation still refers to downloading the Azure Stack HCI OS image, so the operating system retains the old name even though the product does not.

How is Azure Local licensed compared to VMware?

The metric is different, and on a VMware exit the metric usually matters more than the rate. Microsoft states that Azure Local is priced per physical core on your on-premises machines, plus consumption-based charges for any additional Azure services you use, and that all charges roll up to your existing Azure subscription. Compare that to the Broadcom model, where subscription pricing applies a 16-core-per-CPU minimum per socket. That minimum is what turns a bad renewal into a shocking one for an estate running 8-core or 10-core CPUs, because you start paying for 16 regardless. Neither model is automatically cheaper — but if the core-minimum is what broke your VMware renewal, a per-physical-core metric with no socket floor is a different shape of bill, and it is worth modelling against your actual core counts rather than assuming.

When does Azure Local beat plain Hyper-V on Windows Server?

When you need something Windows Server Hyper-V does not give you, and you are willing to buy validated hardware to get it. Azure Local brings an Azure-managed control plane with Azure Arc as the unifying layer, cloud-native management through the Azure portal, Azure CLI and ARM templates, and the ability to onboard Azure Policy, Microsoft Defender for Cloud, Azure Monitor and Copilot for Azure against on-premises infrastructure. If none of those are on your requirements list, plain Hyper-V on Windows Server Datacenter is the cheaper answer and you have probably already paid for it. Azure Local earns its place when the hybrid management story, the hardware validation, or the vSAN-class hyperconverged storage parity is the actual requirement.

Does Azure Local require a constant connection to Azure?

No. Microsoft documents that the solution supports deployments that are connected or disconnected from the cloud. That is a meaningful detail for the environments that most often need on-premises compute in the first place — Microsoft's own examples include sovereignty and regulatory requirements where data must stay local, mission-critical continuity for systems that must run through a network outage, and near-real-time control systems with extreme latency requirements. If you dismissed the platform because you assumed an always-on Azure dependency, that assumption is worth rechecking against the current documentation.

Is Azure Local a good fit for a mid-market VMware estate?

Sometimes, and the deciding factor is usually storage parity plus hardware timing. It is the closest like-for-like to vSAN in the Microsoft stack, which makes it a natural destination for an estate that was genuinely using vSAN rather than a SAN. But it requires validated hardware from Microsoft's partner catalog, so it lands best when a hardware refresh and a VMware renewal coincide. If your hardware has three years left and you were running traditional shared storage, Hyper-V on the existing fleet is usually the more honest recommendation, and we say so.

Field notes · 4 min read · August 18, 2026

Azure Local as a VMware exit: what it is, what it costs

Azure Local is what Microsoft used to call Azure Stack HCI — the old documentation URL now redirects to the Azure Local docs. If you evaluated it under the old name, the quotes and vendor decks in your file still say Azure Stack HCI. It is the same product.

If you are planning a VMware exit and someone has put Azure Local on the shortlist, two things are probably true. You have seen it before under a different name, and you are not sure how the licensing compares to the Broadcom bill you are trying to escape.

This post handles both, using Microsoft's own documentation rather than vendor comparison decks.

The 60-second version: Azure Local is the product Microsoft used to call Azure Stack HCI — the old docs URL redirects to the new one, so you can confirm the rename in one click. It is licensed per physical core on your on-prem machines with consumption charges rolling into your existing Azure subscription. It supports disconnected as well as connected deployments. And it earns its place over plain Hyper-V only when the Azure-managed control plane or vSAN-class storage parity is a real requirement — not by default.

First, the name

Microsoft renamed Azure Stack HCI to Azure Local. You do not have to take that on trust: learn.microsoft.com/en-us/azure-stack/hci/ now redirects to learn.microsoft.com/en-us/azure/azure-local/. A vendor pointing its old product's documentation at a new product's documentation is the clearest signal available that they are the same thing.

The caveat that will trip up your engineers: the rename covers the solution, not every component. Microsoft's current documentation still refers to downloading the Azure Stack HCI OS image. So the platform is Azure Local and the operating system it runs is still named Azure Stack HCI. If someone tells you the old name is simply gone, they have not read the deployment docs.

What it actually is

In Microsoft's framing, Azure Local is a distributed infrastructure solution that extends Azure capabilities to customer-owned environments, using Azure Arc as the unifying control plane. Stripped of the positioning, that means: your hardware, in your building, managed through Azure's control plane rather than through a separate on-premises management stack.

Concretely, Microsoft documents that it gives you:

Provisioning and management through the Azure portal, Azure CLI and ARM templates — the same tooling as your cloud resources.
The ability to onboard Azure Policy, Microsoft Defender for Cloud, Azure Monitor and Copilot for Azure against on-premises infrastructure.
Connected or disconnected deployment. This is the detail most people get wrong.
A partner hardware catalog with prescriptive Bills of Materials — you buy validated configurations, not whatever is in the rack.

The licensing metric is the story

On a VMware exit, the thing that actually moved your bill was rarely the rate. It was the metric.

Microsoft states that Azure Local is priced per physical core on your on-premises machines, plus consumption-based charges for any additional Azure services you use, with everything rolling up to your existing Azure subscription.

Set that against the Broadcom model, where the subscription applies a 16-core-per-CPU minimum per socket. As we covered in VMware after Broadcom, that minimum is usually the difference between a bad renewal and a shocking one: an estate on 8-core or 10-core CPUs starts paying for 16 per socket regardless of what it is using, which is why smaller and older estates often absorb the largest multiples.

What this does and does not tell you: a per-physical-core metric with no socket floor is a different shape of bill, not automatically a smaller one. The only number that settles it is your own core count run against both models. That is an afternoon of work and it is the first thing worth doing — before anyone builds a slide about platforms.

Where it beats plain Hyper-V — and where it does not

This is the question that decides most mid-market cases, because Hyper-V is effectively free if you already run Windows Server Datacenter.

Azure Local earns the premium when you need the Azure-managed control plane against on-prem hardware, when you need vSAN-class hyperconverged storage parity because you were genuinely using vSAN, or when hardware validation is a requirement rather than a nuisance. Microsoft's own use cases point the same direction: local AI inferencing where data must be processed at source, mission-critical continuity through network outages, near-real-time control systems, and strict sovereignty requirements.

It does not earn the premium when the honest answer is "we are a Microsoft-stack shop with traditional shared storage and three years left on the hardware." That is a Hyper-V case, and the validated-hardware requirement makes Azure Local an expensive way to arrive at the same place.

The clean test: if your reason for considering Azure Local is anything other than the control plane, the storage parity, or a hardware refresh that already had to happen — it is probably not the destination.

How this fits a VMware exit

Model your core counts against both metrics before comparing platforms. The metric is the variable that moved.
Check whether you were actually using vSAN. If you were on a SAN, the storage-parity argument for Azure Local largely evaporates and Hyper-V gets cheaper.
Check your hardware clock. Validated hardware is a real constraint; the case is far stronger when a refresh was already due.
Test the disconnected assumption if that was your objection. Microsoft documents disconnected deployments; your requirement may already be met.
Search your own documents for "Azure Stack HCI" — that is where your prior evaluation lives, and it is probably still valid.

We do not resell any of these platforms, so the recommendation in any specific case is not paying us anything extra either way. If you want the core-count modelling and the destination decision done as a bounded piece of work, that is our VMware exit and server modernization engagement — scope it with us.

Questions we get asked

Is Azure Local the same thing as Azure Stack HCI?: Yes. Microsoft renamed it, and you can verify that yourself in one step: the old documentation URL, learn.microsoft.com/en-us/azure-stack/hci/, now returns a redirect to learn.microsoft.com/en-us/azure/azure-local/. That matters practically rather than academically, because any evaluation you did before the change, any vendor deck in your file, and any internal business case will still carry the old name. One caveat worth knowing: the rename applies to the solution, not to every component. Microsoft's current documentation still refers to downloading the Azure Stack HCI OS image, so the operating system retains the old name even though the product does not.
How is Azure Local licensed compared to VMware?: The metric is different, and on a VMware exit the metric usually matters more than the rate. Microsoft states that Azure Local is priced per physical core on your on-premises machines, plus consumption-based charges for any additional Azure services you use, and that all charges roll up to your existing Azure subscription. Compare that to the Broadcom model, where subscription pricing applies a 16-core-per-CPU minimum per socket. That minimum is what turns a bad renewal into a shocking one for an estate running 8-core or 10-core CPUs, because you start paying for 16 regardless. Neither model is automatically cheaper — but if the core-minimum is what broke your VMware renewal, a per-physical-core metric with no socket floor is a different shape of bill, and it is worth modelling against your actual core counts rather than assuming.
When does Azure Local beat plain Hyper-V on Windows Server?: When you need something Windows Server Hyper-V does not give you, and you are willing to buy validated hardware to get it. Azure Local brings an Azure-managed control plane with Azure Arc as the unifying layer, cloud-native management through the Azure portal, Azure CLI and ARM templates, and the ability to onboard Azure Policy, Microsoft Defender for Cloud, Azure Monitor and Copilot for Azure against on-premises infrastructure. If none of those are on your requirements list, plain Hyper-V on Windows Server Datacenter is the cheaper answer and you have probably already paid for it. Azure Local earns its place when the hybrid management story, the hardware validation, or the vSAN-class hyperconverged storage parity is the actual requirement.
Does Azure Local require a constant connection to Azure?: No. Microsoft documents that the solution supports deployments that are connected or disconnected from the cloud. That is a meaningful detail for the environments that most often need on-premises compute in the first place — Microsoft's own examples include sovereignty and regulatory requirements where data must stay local, mission-critical continuity for systems that must run through a network outage, and near-real-time control systems with extreme latency requirements. If you dismissed the platform because you assumed an always-on Azure dependency, that assumption is worth rechecking against the current documentation.
Is Azure Local a good fit for a mid-market VMware estate?: Sometimes, and the deciding factor is usually storage parity plus hardware timing. It is the closest like-for-like to vSAN in the Microsoft stack, which makes it a natural destination for an estate that was genuinely using vSAN rather than a SAN. But it requires validated hardware from Microsoft's partner catalog, so it lands best when a hardware refresh and a VMware renewal coincide. If your hardware has three years left and you were running traditional shared storage, Hyper-V on the existing fleet is usually the more honest recommendation, and we say so.

Related service

VMware Exit & Server Modernization

Written by the team at Pro IT NW · Senior-led Microsoft project consultancy · Seattle / USA-wide.

Share on LinkedIn Follow Pro IT NW