What's it gonna be: Classic Hyper-V or Azure Local?

1. Not an anti-cloud reflex

That is not an anti-cloud reflex. We build Azure environments, we run Arc where it fits, and we have customers for whom Azure Local is exactly the right answer. But the reasons people think they need Azure Local often do not match what they actually need.

2. Start with the runtime

Start with the runtime. A Hyper-V failover cluster on a SAN runs whether the internet is up or not. No registration, no external control plane, no subscription that expires. We have seen environments where an Azure outage on the other side of the world caused no ripple in production, simply because nothing in the chain had to talk to Azure. For a hospital, a production line, or a ship at sea, that is not a detail. That is the whole business case.

3. The cost: once versus every month

Then the cost. You buy Windows Server Datacenter once, perpetually, licensed per physical core, and on that host it covers unlimited VMs. However, with Azure Local you rent: about ten dollars per physical core per month, on top of your hardware, with guest Windows licensed separately. Take two nodes of 32 cores each. That is roughly 640 dollars a month in host fees alone, before you license a single VM, and it keeps running whether you grow or stand still. We model it in every advisory round, and for stable, predictable workloads the one-time purchase often wins. Not always, but more often than the slides suggest. One genuine exception, and it cuts the other way: if you already hold Software Assurance on Datacenter, Azure Hybrid Benefit can waive the Azure Local host fee, but only on a cloud-connected, Storage Spaces Direct deployment, not on a SAN and not disconnected. The buyer who wants to stay off Azure gets nothing from it.

4. Maturity and the people who know it

And maybe the most important one: maturity. Failover Clustering has been around since 2008. The pitfalls are known, the runbooks exist, and your people know the stack inside out. And you are not alone with it: there is an army of people who know Hyper-V and SAN out there. You can hire it, bring in a consultant, or search a forum and find someone who already solved your exact problem. Your storage team knows how the multipathing, the zoning, and the firmware of that SAN behave, because they have run it for years. With Azure Local you switch to a completely new update model, the so-called solution updates. On top of that come a new dependency on validated hardware from the catalog, and a far smaller pool of people who know it. All learnable, but it is a new stack with new ways to break, and you pay that bill in the first few years.

5. How long a classic cluster lasts

In our cluster assessments we mostly see how long a classic cluster lasts. Most enterprises depreciate servers over about five years. A well-built Hyper-V cluster on a decent SAN comfortably outlives that, running six or seven years on little more than firmware updates, patch rounds, and the odd replaced disk. That is not nostalgia for the old. It is a low TCO and few surprises. We name the downside too. You do those patch rounds yourself, node by node, with Cluster-Aware Updating and your own maintenance window. Your SAN is a design choice you have to get right, because the zoning, the multipathing, and the redundancy decide your uptime, and nobody catches that centrally for you. And you get no Azure control plane showing all your sites at a glance. Anyone who genuinely needs that last part is buying something real with Azure Local.

6. The disconnected argument

About the “but it runs disconnected now” argument, because it comes up every time. We checked it again. Azure Local's disconnected operations does let you run without a cloud connection, but it does that by hosting the entire Arc control plane locally, inside a virtual appliance. So it is still Arc, all the way down. You just run Arc on your own iron. And that appliance is not free: it needs physical machines, at least three for the management instance, hundreds of gigabytes of headroom, and it is still in preview. The marquee feature, AKS, does not work in a fully air-gapped deployment yet. So if your reason for wanting offline is that you do not want the Azure operating model in the first place, disconnected Azure Local does not remove that model. It moves it into your rack and hands you the bill for running it. A classic cluster has run offline since day one, no fine print.

7. Less final than it feels

Good news for the undecided: the choice is less final than it feels. Both platforms run Hyper-V. Your guests and their VHDX files move from one to the other, so if you start classic and want Azure Local in three years, you migrate the VMs, not your whole application estate.

8. Our advice

Our advice, short. Do you want to own the infrastructure, run offline, know your costs up front, and build on a stack your team already masters? Build the Hyper-V cluster on your own SAN, and keep the control plane in your own server room. Do you want to bring Azure services and central management to your edge, and do you knowingly accept the dependence on Arc and the monthly bill? Then Azure Local is a fine choice, as long as you make it for that reason. What we want to steer you away from: do not pick Azure Local because you actually mean the old Azure Stack HCI. It is gone. The question is not new HCI or old HCI. The question is whether you want to lift your infrastructure into Azure, yes or no.

So, your turn. You are facing the next refresh. Classic Hyper-V cluster on shared storage, Azure Local with Arc, or both for different jobs? Tell us where you land, and why. We put the same question to a vote on LinkedIn. Cast yours, add your reasoning in the comments, and we will fold the best arguments from both sides into a follow-up.