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 hyperconverged Windows platform managed through Azure Arc, 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 CloudLabs walks through in an Azure Local Readiness Assessment, in the order that actually matters. Not the marketing order, the order in which you hit problems.
- First decision: is Azure Local the right target?
- Hardware compatibility, the non-negotiable part
- Network architecture and RDMA
- Identity: Entra ID, AD, and the new cluster identity model
- Licensing and cost reality
- The operational shift: Arc-managed everything
- Migration paths from Hyper-V and Azure Stack HCI
- Five gotchas we keep running into
- The pre-migration checklist
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, 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.
CloudLabs starts every Azure Local Readiness Assessment 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.
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 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 |
| 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? An Azure Local Readiness Assessment from CloudLabs delivers a go/no-go recommendation with explicit trade-offs in five working days, as a customer-facing .docx report.
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 CloudLabs 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:
- 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 in CloudLabs migration engagements.
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
CloudLabs delivers this as a customer-facing .docx after an Azure Local Readiness Assessment. The short version:
- 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 CloudLabs Azure Local Readiness Assessment runs as a fixed-scope engagement, delivers a readiness report in English or Dutch, and includes a written go/no-go recommendation with explicit trade-offs. For customers who are ready, for customers who are better off waiting, and for customers where the answer lands somewhere in between.
Schedule an Azure Local Readiness Assessment →
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.
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.
Up to 30 days of disconnected operation is supported. Beyond that, the cluster stops billing through Azure and connectivity must be restored. For strictly air-gapped environments, Azure Local is not the right choice.
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 usually lands in the low thousands of euros per month, 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.
Azure Local migratie readiness checklist: wat 2026 anders maakt
Azure Local is Microsofts huidige naam voor het besturingssysteem dat eerder Azure Stack HCI heette. Een hyperconverged Windows-platform beheerd via Azure Arc, gefactureerd per core per maand, en bedoeld voor productie-workloads die on-premises moeten blijven. Voor klanten die uit hun VMware-omgeving willen of een verouderd Hyper-V cluster vervangen, staat Azure Local opvallend hoog op de optielijst. Terecht.
Maar migreren vanuit traditionele Hyper-V clusters of vanaf oudere Azure Stack HCI-versies is technisch geen rocket science. De readiness-gap maakt meer projecten kapot dan de migratie zelf. Solution-catalog mismatches, switches zonder DCB, Entra ID tenant-keuzes die achteraf niet terug te draaien zijn, en kostenmodellen die op papier kloppen maar in productie 3x duurder uitvallen.
Deze checklist is wat CloudLabs in een Azure Local Readiness Assessment doorloopt, in de volgorde die er werkelijk toe doet. Niet de marketing-volgorde, maar de volgorde waarin je problemen tegenkomt.
- Eerste beslissing: is Azure Local het juiste doel?
- Hardware compatibiliteit, het niet-onderhandelbare deel
- Netwerkarchitectuur en RDMA
- Identity: Entra ID, AD en het nieuwe cluster-identiteitsmodel
- Licensing en kosten-realiteit
- De operationele shift: Arc-managed everything
- Migratiepaden vanuit Hyper-V en Azure Stack HCI
- Vijf gotchas die we steeds tegenkomen
- De pre-migratie checklist
1. Eerste beslissing: is Azure Local het juiste doel?
Azure Local is geen gratis upgradepad voor elk Hyper-V cluster. Het is het juiste antwoord bij hyperconverged storage met S2D, Arc-native operations, integratie met Azure-diensten (Site Recovery, Backup, AKS on Azure Local), en een duidelijke roadmap-aansluiting op Microsofts huidige koers. Het is het verkeerde antwoord bij een klein two-node cluster met shared SAN, een workload-mix die per-core licensing niet rechtvaardigt, of harde policy-beperkingen die Azure-connectivity blokkeren.
CloudLabs begint elke Azure Local Readiness Assessment met die vraag. Als het antwoord is "we blijven beter op Windows Server met Failover Clustering en Hyper-V," is dat een legitieme uitkomst, en eentje die wij voor meerdere klanten gedocumenteerd hebben waar de per-core economics niet uitkwamen.
2. Hardware compatibiliteit, het niet-onderhandelbare deel
Azure Local draait alleen op hardware uit de Azure Local Solutions Catalog. Niet de Windows Server HCL, de Azure Local catalogus. Dit is de grootste bron van projecten die ontsporen die wij zien. Een server die perfect werkte onder Windows Server 2022 en Failover Clustering staat soms helemaal niet op de Azure Local catalogus, of alleen met een specifiek firmware-niveau en een specifieke NIC.
Wat te verifiëren, in deze volgorde:
Chassis plus CPU plus drive bay-configuratie moet matchen met een gevalideerde solution van Dell, HPE, Lenovo, Supermicro of een andere OEM in de Azure Local catalogus. "Bijna hetzelfde" telt niet. Het cluster deployt wel, maar je verliest support en je krijgt geen solution-updates.
NIC's moeten RDMA-capable zijn voor het storage-netwerk. RoCEv2 (Mellanox/NVIDIA ConnectX-4 of nieuwer, Broadcom NetXtreme-E) of iWARP (Chelsio T5/T6, sommige Intel X722). De catalogus benoemt ondersteunde part numbers per solution. Een ConnectX-5 die in de ene solution staat is niet automatisch geldig in een andere.
Drives moeten all-NVMe, all-SSD, of een hybride zijn die expliciet voor dat chassis gevalideerd is. SSD-vendors mixen binnen een node mag, capaciteiten mixen binnen een tier is vragen om scheve slijtage en onvoorspelbare capacity planning.
TPM 2.0 en Secure Boot zijn verplicht. Vrijwel alle moderne hardware heeft het, maar BIOS-instellingen moeten expliciet gecontroleerd worden. Bij refurbished hardware staat TPM regelmatig uit.
Solution firmware baseline. Elke OEM publiceert er één, en je moet die matchen vóór deployment. Daarna lopen updates via Azure Update Manager. Een afwijkende BIOS- of NIC-firmware-versie op één node breekt de eerste Update Run.
3. Netwerkarchitectuur en RDMA
Azure Local heeft uitgesproken meningen over netwerktopologie. Het referentieontwerp is twee switches, twee NIC-poorten per node voor storage met RDMA, twee NIC-poorten voor management en compute. Network ATC (Automatic Cluster Networking) is de aanbevolen automatiseringslaag, die genereert de hele SET / vSwitch / QoS-configuratie uit een high-level intent.
De niet-onderhandelbare eisen:
- Storage-netwerk moet RDMA zijn (RoCEv2 of iWARP) met DCB en PFC geconfigureerd op switchzijde. Voor RoCEv2 betekent dit minimaal PFC op prioriteit 3 en ETS op prioriteit 3 met een gegarandeerd bandbreedtepercentage. Switches zonder DCB-support kun je niet gebruiken voor productie-grade Azure Local.
- Storage-netwerk moet geïsoleerd zijn, apart VLAN, aparte fysieke NIC-poorten van management. Storage-verkeer combineren met management is in sommige topologieën ondersteund maar reduceert altijd de resilience.
- Minimaal 10 GbE voor de kleinste productie-deployments, 25 GbE is de praktische ondergrens voor serieuze workloads. 100 GbE is normaal aan de grotere kant. We zien in 2026 nauwelijks meer nieuwe deployments onder 25 GbE.
- Switches moeten DCB ondersteunen. Veel oudere datacenter-switches doen dat, maar switch-firmware moet expliciet gecontroleerd worden. Cisco Nexus 9K, Arista 7050, Dell Z9264F, en Mellanox SN3700 zijn praktijkkeuzes die wij vaak zien werken.
Test het vóór je je vastlegt:
# Verifieer of RDMA werkelijk werkt tussen twee kandidaat-nodes
Test-RDMA -PfcEnabled $true -IfIndex (Get-NetAdapter 'Storage1').ifIndex `
-RemoteIpAddress 10.20.0.12
# Check de onderhandelde snelheid en RDMA-capability op elke cluster-NIC
Get-NetAdapterRdma | Select-Object Name, Enabled
Get-NetAdapter | Select-Object Name, Status, LinkSpeed, MediaTypeKomt RDMA niet door deze test, dan stopt het project hier tot de switch-zijde is opgelost. Doorgaan en "later regelen" is in de praktijk een garantie voor performance-issues die tot na go-live verborgen blijven.
4. Identity: Entra ID, AD en het nieuwe cluster-identiteitsmodel
Dit is waar veel bestaande Hyper-V beheerders verrast worden. Azure Local nodes worden domain-joined aan je on-premises Active Directory én geregistreerd in Microsoft Entra ID voor Arc-management. Het cluster heeft een eigen Entra ID service principal, en meerdere Azure RBAC-rollen moeten correct toegekend zijn voordat de deployment überhaupt start.
Pre-deployment identity-checklist:
- Een dedicated OU in Active Directory voor het Azure Local cluster, met inheritance geblokkeerd en Group Policy gefilterd. Inheritance niet blokkeren is de meest voorkomende reden dat een succesvolle deployment na de eerste GPO-refresh kapot gaat.
- Een deployment user-account met lokale admin-rechten op alle nodes en het recht om computerobjecten in die OU aan te maken.
- Een Entra ID tenant waarin het cluster geregistreerd wordt. Bij multi-tenant organisaties: dit vooraf beslissen. Het is achteraf niet makkelijk te wijzigen.
- Een Azure subscription in dezelfde Entra-tenant, met de resource providers
Microsoft.AzureStackHCI,Microsoft.HybridConnectivityenMicrosoft.Kubernetesgeregistreerd. - Azure RBAC-rollen op die subscription: Azure Connected Machine Onboarding, Azure Stack HCI Administrator, en een Reader-rol op resource group-niveau voor de cluster-identiteit.
5. Licensing en kosten-realiteit
Azure Local wordt per fysieke core per maand gefactureerd via je Azure-subscription. Er is geen perpetual-licentie voor het OS zelf. Guest-workloads worden apart gelicentieerd. Windows Server VM's worden meestal gedekt door Windows Server Datacenter met Software Assurance, of door Azure Hybrid Benefit.
| Kostencomponent | Model | Opmerking |
|---|---|---|
| Azure Local OS | Per fysieke core per maand | Via Azure-subscription, geen perpetual optie |
| Windows Server guests | Datacenter SA of AHB | Onbeperkte Windows-VM's op de node bij Datacenter |
| Azure-diensten (Arc, Monitor, Defender) | Consumptie | Optioneel maar in de meeste deployments verwacht |
| Hardware | CapEx | Solution-pricing varieert per OEM |
| Egress / connectivity | Variabel | Materieel in Backup- en Site Recovery-scenario's |
Voor een four-node cluster met 32 cores per node en bestaande Datacenter SA wordt de meerprijs ten opzichte van Windows Server gedomineerd door de per-core OS-fee en de Azure-dienstconsumptie. Modelleer het vóór de commitment. Wij zien in onze opdrachten regelmatig dat de Azure Monitor- en Log Analytics-consumptie in steady state 3x hoger uitvalt dan tijdens deployment ingeschat.
De vier secties hierboven (hardware, netwerk, identity, licensing) bepalen of een Azure Local project überhaupt mogelijk is. De drie secties hieronder bepalen of het operationeel houdbaar is.
Voordat je je vastlegt, lees ook onze analyse van de gedocumenteerde gebreken en het exitpad. Deze checklist helpt je het goed te doen; dat artikel helpt je beslissen of je het wel moet doen.
Twijfel je of jouw omgeving er klaar voor is? Een Azure Local Readiness Assessment van CloudLabs geeft binnen vijf werkdagen een go/no-go advies met expliciete trade-offs, in een .docx-rapport voor de klant.
6. De operationele shift: Arc-managed everything
De grootste niet-technische shift is operationeel. Day-2 management van Azure Local loopt primair via Azure Portal, Azure Arc en Azure Update Manager. Failover Cluster Manager werkt nog, maar is niet de primaire interface. PowerShell blijft volledig ondersteund en is wat wij voor vrijwel alles gebruiken tijdens een CloudLabs opdracht.
Wat verandert in de dagelijkse operatie:
- Patching verhuist naar Azure Update Manager. Je plant update-runs vanuit de portal, het systeem patcht OS, firmware, drivers en solution-componenten in één gecoördineerde run. Geen
Invoke-CauRunmeer, geen handmatige firmware-flashes per node tijdens een onderhoudsvenster. - Monitoring via Azure Monitor en Insights for Azure Local. Bestaande SCOM of third-party tooling kan blijven, maar de first-party ervaring zit in Azure. Voor organisaties met sterk geïnvesteerde on-premises monitoring is dit een dubbele rekening tijdens de transitie-periode.
- VM-management verschuift richting Arc-enabled VMs en de Azure-portal. Hyper-V Manager en Failover Cluster Manager werken nog, maar de nieuwe lifecycle (provisioning, backup, replicatie) is portal-gedreven. Beheerders die alles via PowerShell of WAC deden, krijgen er een nieuwe interface bij.
- Backup via Azure Backup for Azure Local, of third-party tools die expliciet Azure Local support hebben toegevoegd. Veeam, Commvault en Cohesity doen dat op het moment van schrijven. Een bestaande Veeam-deployment werkt door, maar moet bijgewerkt naar een Azure Local-bewuste versie.
7. Migratiepaden vanuit Hyper-V en Azure Stack HCI
Er is geen in-place upgrade van Windows Server Hyper-V naar Azure Local. Je bouwt een nieuw cluster, migreert workloads ernaartoe, en decommissioneert het oude. Vanaf Azure Stack HCI 22H2 bestaat er wel een in-place upgrade-pad naar Azure Local 23H2 en hoger, met prerequisites die zorgvuldige controle vereisen.
Migratie-opties voor workloads, in volgorde van afnemende voorkeur voor de meeste productie-VM's:
- Hyper-V Replica werkt tussen Hyper-V en Azure Local zolang Hyper-V Replica is geconfigureerd. Cutover vereist een korte uitval (typisch onder een minuut per VM), en je kunt batches plannen tijdens een onderhoudsvenster.
- Storage Migration Service voor fileserver-rollen. Specifiek voor bestand-data, niet voor algemene VM-workloads.
- Backup-and-restore via Azure Site Recovery, Veeam of Commvault. De traagste optie, maar werkbaar voor grote omgevingen met strikte cutover-vensters waar Hyper-V Replica geen optie is.
- VHD copy plus register. Handmatig, scriptable, werkt prima voor laag-belang VM's. Acceptabel voor batch-workloads, dev/test, en alles wat een paar uur downtime mag hebben. Wij scripten dit standaard mee in CloudLabs migratie-opdrachten.
8. Vijf gotchas die we steeds tegenkomen
- NIC's die RoCE-capable zijn maar niet op de solution-NIC lijst staan. Solution-validatie gebeurt op part number, niet op capability. Een ConnectX-6 die elders prima werkt is niet automatisch geldig in jouw specifieke solution.
- Switches zonder DCB op het storage-VLAN. Het cluster deployt en draait, performance is stilletjes gedegradeerd. We zien dit nog steeds bij DCB-geconfigureerde switches waar de configuratie alleen op management-poorten staat, niet op de poorten richting de Azure Local nodes.
- OU-inheritance niet geblokkeerd. Group Policy breekt de deployment dan op subtiele manieren na de eerste patch-cyclus. Symptoom: cluster werkt, Arc-registratie werkt, na een week vallen Update Runs uit met access-denied fouten waar niemand een logische oorzaak voor vindt.
- Entra ID tenant-mismatch. Cluster geregistreerd in de ene tenant, subscription in een andere. Verplaatsen is pijnlijk en in sommige scenario's vereist het opnieuw uitrollen van het cluster.
- Kostenverrassing op egress en Azure Monitor-data. Geschat op deployment-datavolumes, realiteit is 3x zoveel in steady state. Modelleer kosten op basis van werkelijke log-volumes van een bestaand Hyper-V cluster, niet op basis van Microsofts calculator-defaults.
9. De pre-migratie checklist
CloudLabs levert dit als .docx voor de klant na een Azure Local Readiness Assessment. De korte versie:
- Gevalideerde solution geselecteerd uit Azure Local Solutions Catalog
- Firmware-baseline gematcht op alle nodes
- TPM 2.0 en Secure Boot geverifieerd in BIOS op iedere node
- RDMA end-to-end getest tussen alle nodes op het storage-VLAN
- DCB en PFC geconfigureerd op alle storage-switches
- Dedicated OU in AD met inheritance geblokkeerd
- Deployment-user met vereiste AD-rechten
- Entra ID tenant-beslissing gedocumenteerd
- Azure-subscription met vereiste resource providers geregistreerd
- Azure RBAC-rollen toegewezen
- Licentiemodel besloten en gebudgetteerd inclusief Azure Monitor consumptie
- Backup-product gevalideerd voor Azure Local
- Monitoring-stack besloten (alleen Azure Monitor of hybride)
- Migratie-aanpak per workload gedocumenteerd
- Cutover-vensters per workload-groep ingepland
- Rollback-procedure geschreven en gereviewd
Een Azure Local Readiness Assessment van CloudLabs loopt als opdracht met vaste scope, levert een readiness-rapport in Nederlands of Engels, en bevat een geschreven go/no-go advies met expliciete trade-offs. Voor klanten die er klaar voor zijn, voor klanten die het beter even niet kunnen doen, en voor klanten waar het antwoord ergens daartussen ligt.
Plan een Azure Local Readiness Assessment →
Veelgestelde vragen
Azure Local is sinds eind 2024 de nieuwe naam voor wat eerder Azure Stack HCI heette. Het is hetzelfde product, met een verbrede scope (ook edge en kleinere deployments) en duidelijker positionering binnen Microsofts Arc-strategie. Bestaande Azure Stack HCI 22H2-clusters kunnen in-place upgraden naar Azure Local 23H2 en hoger.
Ja. Er is geen in-place upgrade van Windows Server Hyper-V naar Azure Local. Je bouwt een nieuw cluster op gevalideerde hardware en migreert workloads ernaartoe.
Tot 30 dagen disconnected operation wordt ondersteund. Daarna stopt het cluster met factureren via Azure en moet de connectivity hersteld zijn. Voor strict air-gapped omgevingen is Azure Local niet de juiste keuze.
Beperkt. SCVMM 2025 ondersteunt management van Azure Local clusters, maar de Arc-portal is de primaire interface volgens Microsofts roadmap. Voor klanten met een grote bestaande VMM-investering werken beide naast elkaar tijdens de transitie.
Per-core, per-maand pricing varieert per regio. Voor een four-node cluster met 32 cores per node komt de OS-component meestal op een paar duizend euro per maand uit, exclusief Azure-dienstconsumptie en exclusief Windows Server-licenties voor de guests. Modelleer met de Azure pricing calculator én met werkelijke log-volumes uit een vergelijkbare bestaande omgeving.