ClusterTriage / Blog / Azure Local
Azure Local Migration Readiness Checklist: What's Different in 2026
Azure Local is Microsoft's current name for the operating system formerly known as Azure Stack HCI. A Windows platform managed through Azure Arc, hyperconverged by origin and since 2026 also available on external SAN storage, billed per core per month, and intended for production workloads that must stay on-premises. For customers looking to leave VMware or replace an aging Hyper-V cluster, Azure Local sits prominently on the shortlist. Justifiably.
But migrating from traditional Hyper-V clusters or from older Azure Stack HCI versions is technically not rocket science. The readiness gap breaks more projects than the migration itself. Solution-catalog mismatches, switches without DCB, Entra ID tenant choices that cannot be undone after the fact, and cost models that look fine on paper but come in three times higher in production.
This checklist is what we walk through when Azure Local is on the table, in the order that actually matters. Not the marketing order, the order in which you hit problems.
1. First decision: is Azure Local the right target?
Azure Local is not a free upgrade path for every Hyper-V cluster. It is the right answer for hyperconverged storage with S2D, or since release 2604 for a supported SAN array you want to keep, combined with Arc-native operations, integration with Azure services (Site Recovery, Backup, AKS on Azure Local), and clear alignment with Microsoft's current direction. It is the wrong answer for a small two-node cluster on shared SAN, a workload mix that does not justify per-core licensing, or hard policy constraints that block Azure connectivity.
We start every conversation about Azure Local with that question. If the answer is "we are better off staying on Windows Server with Failover Clustering and Hyper-V," that is a legitimate outcome, and one we have documented for multiple customers where the per-core economics did not work out.
2. Hardware compatibility, the non-negotiable part
Azure Local only runs on hardware from the Azure Local Solutions Catalog. Not the Windows Server HCL, the Azure Local catalog. This is the single biggest source of derailed projects we see. A server that worked perfectly under Windows Server 2022 and Failover Clustering sometimes is not on the Azure Local catalog at all, or only at a specific firmware level with a specific NIC.
What to verify, in this order:
Chassis plus CPU plus drive bay configuration must match a validated solution from Dell, HPE, Lenovo, Supermicro, or another OEM in the Azure Local catalog. "Nearly the same" does not count. The cluster deploys, but you lose support and you do not receive solution updates.
NICs must be RDMA-capable for the storage network. RoCEv2 (Mellanox/NVIDIA ConnectX-4 or newer, Broadcom NetXtreme-E) or iWARP (Chelsio T5/T6, some Intel X722). The catalog lists supported part numbers per solution. A ConnectX-5 valid in one solution is not automatically valid in another.
Drives must be all-NVMe, all-SSD, or a hybrid explicitly validated for that chassis. Mixing SSD vendors within a node is fine, mixing capacities within a tier asks for uneven wear and unpredictable capacity planning.
Using a SAN next to or instead of local drives? Supported since release 2604 for Fibre Channel and 2607 for iSCSI, but only with an array from Microsoft's supported SAN list, Windows Server 2025 certified HBAs or catalog-compliant iSCSI NICs on every node, and identical zoning and MPIO settings across the cluster. The whole cluster then bills at the L2 price tier. The details are in SAN vs S2D vs Azure Local.
TPM 2.0 and Secure Boot are mandatory. Nearly all modern hardware has both, but BIOS settings must be explicitly verified. On refurbished hardware, TPM is regularly disabled.
Solution firmware baseline. Each OEM publishes one, and you must match it before deployment. Afterwards updates run through Azure Update Manager. A deviating BIOS or NIC firmware version on a single node breaks the first Update Run.
3. Network architecture and RDMA
Azure Local has strong opinions about network topology. The reference design is two switches, two NIC ports per node for storage with RDMA, two NIC ports for management and compute. Network ATC (Automatic Cluster Networking) is the recommended automation layer, it generates the entire SET / vSwitch / QoS configuration from a high-level intent.
The requirements below apply to Azure Local with S2D. A SAN-only (disaggregated) deployment has no S2D storage network, but its FC fabric or iSCSI network deserves the same care. In a hybrid cluster, iSCSI needs its own physical ports, outside Network ATC.
The non-negotiables:
- Storage network must use RDMA (RoCEv2 or iWARP) with DCB and PFC configured switch-side. For RoCEv2 that means at minimum PFC on priority 3 and ETS on priority 3 with a guaranteed bandwidth percentage. Switches without DCB support cannot be used for production-grade Azure Local.
- Storage network must be isolated, separate VLAN, separate physical NIC ports from management. Combining storage traffic with management is supported in some topologies but always reduces resilience.
- Minimum 10 GbE for the smallest production deployments, 25 GbE is the practical floor for serious workloads. 100 GbE is normal at the larger end. We rarely see new deployments below 25 GbE in 2026.
- Switches must support DCB. Many older datacenter switches do, but switch firmware must be explicitly verified. Cisco Nexus 9K, Arista 7050, Dell Z9264F, and Mellanox SN3700 are practical choices we frequently see working.
Test it before you commit:
# Verify that RDMA actually works between two candidate nodes
Test-RDMA -PfcEnabled $true -IfIndex (Get-NetAdapter 'Storage1').ifIndex `
-RemoteIpAddress 10.20.0.12
# Check negotiated speed and RDMA capability on each cluster NIC
Get-NetAdapterRdma | Select-Object Name, Enabled
Get-NetAdapter | Select-Object Name, Status, LinkSpeed, MediaTypeIf RDMA does not pass this test, the project stops here until the switch side is fixed. Proceeding and "sorting it out later" is in practice a guarantee for performance issues that stay hidden until after go-live.
4. Identity: Entra ID, AD, and the new cluster identity model
This is where many existing Hyper-V administrators get caught off guard. Azure Local nodes are domain-joined to your on-premises Active Directory and registered in Microsoft Entra ID for Arc management. The cluster has its own Entra ID service principal, and several Azure RBAC roles must be assigned correctly before deployment can even start.
Pre-deployment identity checklist:
- A dedicated OU in Active Directory for the Azure Local cluster, with inheritance blocked and Group Policy filtered. Not blocking inheritance is the most common reason a successful deployment breaks after the first GPO refresh.
- A deployment user account with local admin rights on all nodes and permission to create computer objects in that OU.
- An Entra ID tenant in which the cluster is registered. For multi-tenant organisations: decide this beforehand. Changing it after the fact is not easy.
- An Azure subscription in the same Entra tenant, with resource providers
Microsoft.AzureStackHCI,Microsoft.HybridConnectivity, andMicrosoft.Kubernetesregistered. - Azure RBAC roles on that subscription: Azure Connected Machine Onboarding, Azure Stack HCI Administrator, and a Reader role at the resource group level for the cluster identity.
5. Licensing and cost reality
Azure Local is billed per physical core per month through your Azure subscription. There is no perpetual license for the OS itself. Guest workloads are licensed separately. Windows Server VMs are usually covered by Windows Server Datacenter with Software Assurance, or by Azure Hybrid Benefit.
| Cost component | Model | Notes |
|---|---|---|
| Azure Local OS | Per physical core, per month | Through Azure subscription, no perpetual option. Tier L1 for S2D on local storage, L2 (about twice L1) once SAN or multi-rack is used, L3 for disconnected operations |
| Windows Server guests | Datacenter SA or AHB | Unlimited Windows VMs on the node with Datacenter |
| Azure services (Arc, Monitor, Defender) | Consumption | Optional but expected in most deployments |
| Hardware | CapEx | Solution pricing varies per OEM |
| Egress / connectivity | Variable | Material in Backup and Site Recovery scenarios |
For a four-node cluster with 32 cores per node and existing Datacenter SA, the uplift over Windows Server is dominated by the per-core OS fee and Azure service consumption. Model it before committing. In our engagements we regularly see Azure Monitor and Log Analytics consumption come in three times higher in steady state than estimated during deployment.
The four sections above (hardware, network, identity, licensing) determine whether an Azure Local project is even feasible. The three sections below determine whether it is operationally sustainable.
Before you commit, also read our analysis of the documented flaws and the exit path. This checklist helps you do it right; that article helps you decide whether to do it at all.
Not sure if your environment is ready? A ClusterTriage cluster assessment records the measured state of your current cluster, and that is the starting point for a reasoned go/no-go.
Contact us →6. The operational shift: Arc-managed everything
The biggest non-technical shift is operational. Day-2 management of Azure Local runs primarily through Azure Portal, Azure Arc, and Azure Update Manager. Failover Cluster Manager still works, but is not the primary interface. PowerShell remains fully supported and is what we use for nearly everything during a ClusterTriage engagement.
What changes in daily operations:
- Patching moves to Azure Update Manager. You schedule update runs from the portal, the system patches OS, firmware, drivers, and solution components in one coordinated run. No more
Invoke-CauRun, no more manual firmware flashes per node during a maintenance window. - Monitoring through Azure Monitor and Insights for Azure Local. Existing SCOM or third-party tooling can stay, but the first-party experience lives in Azure. For organisations with heavy on-premises monitoring investments, this is a double bill during the transition period.
- VM management shifts toward Arc-enabled VMs and the Azure portal. Hyper-V Manager and Failover Cluster Manager still work, but the new lifecycle (provisioning, backup, replication) is portal-driven. Administrators who did everything through PowerShell or WAC gain an additional interface.
- Backup through Azure Backup for Azure Local, or third-party tools that have explicitly added Azure Local support. Veeam, Commvault, and Cohesity all do at the time of writing. An existing Veeam deployment continues to work, but must be updated to an Azure Local-aware version.
7. Migration paths from Hyper-V and Azure Stack HCI
There is no in-place upgrade from Windows Server Hyper-V to Azure Local. You build a new cluster, migrate workloads to it, and decommission the old one. From Azure Stack HCI 22H2 there is an in-place upgrade path to Azure Local 23H2 and higher, with prerequisites that require careful checking.
Migration options for workloads, in order of decreasing preference for most production VMs:
- Azure Migrate is Microsoft's own route and the only one that lands VMs as Azure Local VMs managed from the portal. The Hyper-V source path is still in preview in September 2026 and only takes VMs whose disks sit on Cluster Shared Volumes; the VMware path has been generally available since October 2025. Since May 2026 it can also target Azure Local on SAN storage.
- Hyper-V Replica works between Hyper-V and Azure Local as long as Hyper-V Replica is configured. Cutover requires a brief outage (typically under a minute per VM), and you can schedule batches during a maintenance window.
- Storage Migration Service for fileserver roles. Specifically for file data, not for general VM workloads.
- Backup-and-restore through Azure Site Recovery, Veeam, or Commvault. The slowest option, but workable for large environments with strict cutover windows where Hyper-V Replica is not an option.
- VHD copy plus register. Manual, scriptable, works fine for low-importance VMs. Acceptable for batch workloads, dev/test, and anything that can tolerate a few hours of downtime. We script this as a standard option whenever we guide a migration.
VMs that arrive through Hyper-V Replica, a restore or a VHD copy are ordinary Hyper-V VMs on the cluster. Azure does not manage them as Azure Local VMs until you deal with that separately, so plan for it per workload.
8. Five gotchas we keep running into
- NICs that are RoCE-capable but not on the solution NIC list. Solution validation is per part number, not per capability. A ConnectX-6 that works fine elsewhere is not automatically valid in your specific solution.
- Switches without DCB on the storage VLAN. The cluster deploys and runs, performance is silently degraded. We still see this with DCB-configured switches where the configuration only exists on management ports, not on the ports facing the Azure Local nodes.
- OU inheritance not blocked. Group Policy then breaks the deployment in subtle ways after the first patch cycle. Symptom: cluster works, Arc registration works, after a week Update Runs fail with access-denied errors that nobody can find a logical cause for.
- Entra ID tenant mismatch. Cluster registered in one tenant, subscription in another. Moving is painful and in some scenarios requires redeploying the cluster.
- Cost surprise on egress and Azure Monitor data. Estimated from deployment data volumes, reality is three times that in steady state. Model costs based on actual log volumes from an existing Hyper-V cluster, not on Microsoft's calculator defaults.
9. The pre-migration checklist
The short version of the checklist we use:
- Validated solution selected from the Azure Local Solutions Catalog
- Firmware baseline matched on all nodes
- TPM 2.0 and Secure Boot verified in BIOS on every node
- RDMA tested end to end between all nodes on the storage VLAN
- DCB and PFC configured on all storage switches
- Dedicated OU in AD with inheritance blocked
- Deployment user with required AD permissions
- Entra ID tenant decision documented
- Azure subscription with required resource providers registered
- Azure RBAC roles assigned
- Licensing model decided and budgeted including Azure Monitor consumption
- Backup product validated for Azure Local
- Monitoring stack decided (Azure Monitor only or hybrid)
- Migration approach per workload documented
- Cutover windows per workload group scheduled
- Rollback procedure written and reviewed
A ClusterTriage cluster assessment measures the current environment read-only and delivers a report in English, Dutch or German. With that measured state in hand, the go/no-go for Azure Local becomes a reasoned decision instead of a feeling. For customers who are ready, for customers who are better off waiting, and for customers where the answer lands somewhere in between.
Frequently asked questions
Azure Local is the new name since late 2024 for what was previously called Azure Stack HCI. It is the same product, with broadened scope (now including edge and smaller deployments) and clearer positioning inside Microsoft's Arc strategy. Existing Azure Stack HCI 22H2 clusters can in-place upgrade to Azure Local 23H2 and higher.
The hosts, yes. There is no in-place upgrade from Windows Server Hyper-V to Azure Local. You build a new cluster on validated hardware and migrate workloads to it. The storage not necessarily: since 2026 Azure Local can use a supported SAN array, so an array with years left can stay, at the L2 price tier.
Standard Azure Local must sync with Azure at least once every 30 days. After that the cluster goes out of policy: running VMs keep running, but you cannot create new ones until it syncs again. For strictly air-gapped environments Microsoft now offers disconnected operations, but that requires an eligible agreement, approval, a dedicated management cluster and the L3 price tier. For most organisations it is not a realistic route.
To a limited extent. SCVMM 2025 supports management of Azure Local clusters, but the Arc portal is the primary interface per Microsoft's roadmap. For customers with a heavy existing VMM investment, both run side by side during the transition.
Per-core, per-month pricing varies by region. For a four-node cluster with 32 cores per node, the OS component lands at a little over a thousand euros per month on tier L1 and about twice that on L2 (SAN attached), excluding Azure service consumption and excluding Windows Server licenses for the guests. Model with the Azure pricing calculator and with actual log volumes from a comparable existing environment.