From Storage Spaces Direct to Azure Local: what changed, and what did not

There is a naming history here that is worth getting right, because it changes how you read older documentation.

Storage Spaces Direct arrived in Windows Server 2016 as a way to build a hyperconverged cluster from internal drives. Azure Stack HCI appeared as a separate, subscription-licensed operating system built around the same technology. On 19 November 2024, Microsoft renamed Azure Stack HCI to Azure Local, bringing its distributed infrastructure portfolio under a single brand.

The rename was a rename. Existing deployments continued to work without action, and pricing, licensing, service levels, certifications and support were unchanged. What it does mean is that any document, certification or project record predating that date correctly says “Azure Stack HCI”, and it should stay that way — my own hands-on work with this technology at Dell between 2020 and 2021, and at Microsoft between 2021 and 2024, was Azure Stack HCI and Windows Server with Storage Spaces Direct. Backdating the current name onto older work makes the history harder to read, not easier.

The problem the comparison has to answer

You have an existing Windows Server cluster using Storage Spaces Direct, or you are choosing a platform for a new on-premises estate. The question is whether Azure Local is a different product or a different licensing arrangement for the same one.

The honest answer is that the storage technology is substantially shared, and the operating model is genuinely different. Almost all of the decision lives in the second half.

What did not change

The storage stack. Storage pools, virtual disks, resiliency types, the storage bus layer cache and ReFS behave as they always have. If you understand how a three-way mirror distributes copies across fault domains, that knowledge transfers directly.

The clustering foundation. Failover Clustering, cluster shared volumes, quorum and witness behaviour. Everything in failover cluster witness choices applies to both.

The failure modes. Drives fail, a node goes down for patching, a storage job runs for longer than anyone expected, and the cluster’s health service reports it. The diagnostic approach in Storage Spaces Direct: what actually breaks is the same on both.

The design mistakes. Failure domain planning, capacity reserve, and the relationship between node count and viable resiliency are unchanged. A two-node cluster has the same constraints it always had.

Hyper-V. The virtualisation layer and its behaviour, including the live migration problems in Hyper-V live migration failures.

That is a large amount of transferable knowledge, and it is the reason an engineer with Storage Spaces Direct experience is not starting over.

What did change, and why it matters more

Licensing and billing. Windows Server with Storage Spaces Direct requires Datacenter edition, licensed per core, bought outright. Azure Local is subscription-billed through an Azure subscription. This is a procurement and finance change as much as a technical one, and in my experience it is the item that most often decides the outcome.

A required Azure connection. Azure Local registers with Azure and expects connectivity. It is an Azure service that runs on your hardware, not a disconnected product. For organisations with genuinely isolated networks, this is the constraint to examine first — before hardware, before design.

Deployment and lifecycle. Azure Local is deployed and managed through the Azure portal and Azure Arc, with a defined release cadence and a validated update path across firmware, drivers and the operating system. Windows Server clustering leaves that integration to you and your hardware vendor. For a team without deep clustering experience, this is a real reduction in operational burden. For a team with strong existing practice, it is a change in who controls the schedule.

Hardware validation. Azure Local expects validated hardware from a defined catalogue. Windows Server with Storage Spaces Direct is more permissive, which sounds like an advantage and is frequently the origin of a difficult support case.

Release naming. Azure Local releases are versioned by date rather than by Windows Server version, and the underlying operating system version moves with them. Documentation is version-filtered, so read the page for your release rather than the default.

Azure service integration. Arc-enabled virtual machines, Azure Kubernetes Service, Azure Virtual Desktop and Azure Arc management extend onto the platform in a way that has no direct Windows Server equivalent.

The decision, stated plainly

Azure Local fits when you want Azure’s operating model on premises, you have or want an Azure commercial relationship, connectivity is not a problem, you intend to use Arc-enabled services, and you would rather Microsoft define the validated update path than own it yourself.

Windows Server with Storage Spaces Direct fits when the environment is disconnected or connectivity-constrained, when perpetual licensing is a firm requirement, when you already have Datacenter licences with life in them, when the hardware is outside the validated catalogue, or when the cluster does one job well and does not need the Azure services.

Neither fits when the workload does not need hyperconverged storage at all. A two-node cluster for a handful of virtual machines may be better served by simpler shared storage, or by moving the workload to Azure. Hyperconvergence is not free complexity, and the most common mistake I see is adopting it because it is current rather than because the workload needs it.

Implementation considerations

Migration is not an upgrade. Moving an existing Storage Spaces Direct cluster to Azure Local is a migration with a defined path, not an in-place operating system upgrade in the ordinary sense. Read the current guidance for your source version and plan it as a project.

Check connectivity requirements early, including required endpoints and what happens during an extended disconnection. This is the constraint that most often invalidates the choice, and it is cheap to check first.

Validated hardware means validated. Confirm your intended hardware appears in the catalogue before designing around it, including drive models and network adapters. An almost matching configuration is not a matching configuration.

Budget the subscription properly. Model the ongoing cost against the perpetual licence it replaces over the expected life of the hardware, and include the Azure services you intend to run. A subscription that looks cheaper per year may not be over five.

Keep the naming honest in your own records. Historical projects keep their historical names, current designs use the current one. Anyone reading your documentation in three years will need to know which product was actually deployed.

Verification and limits

The 19 November 2024 rename of Azure Stack HCI to Azure Local, the continuity of existing deployments, pricing, licensing and support through the rename, the date-based release versioning, Azure portal deployment and Arc integration were checked against current Microsoft documentation on 20 September 2026. The comparison of operating models and the decision guidance are my own judgement.

Nothing here was deployed or migrated for this article. My hands-on work with this technology was with Azure Stack HCI and Windows Server with Storage Spaces Direct, in the periods stated above; I am not claiming operational experience of Azure Local releases under that name. Releases, supported hardware and connectivity requirements change frequently — confirm all three against current documentation for your intended release before planning.

References

• Renaming Azure Stack HCI to Azure Local
• What’s new in Azure Local
• Deploy an Azure Local instance using the Azure portal
• Storage Spaces Direct overview