Azure Local migratie readiness checklist: wat 2026 anders maakt

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, of sinds release 2604 bij een ondersteunde SAN-array die je wilt houden, gecombineerd met 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.

Wij beginnen elk gesprek over Azure Local 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.

Een SAN naast of in plaats van lokale drives? Ondersteund sinds release 2604 voor Fibre Channel en 2607 voor iSCSI, maar alleen met een array van de ondersteuningslijst van Microsoft, voor Windows Server 2025 gecertificeerde HBA's of catalogus-conforme iSCSI-NIC's op elke node, en identieke zoning en MPIO-instellingen in het hele cluster. Het hele cluster wordt dan afgerekend op prijsniveau L2. De details staan in SAN vs S2D vs Azure Local.

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.

Onderstaande eisen gelden voor Azure Local met S2D. Een deployment die alleen op SAN draait (disaggregated) heeft geen S2D-storagenetwerk, maar het FC-fabric of iSCSI-netwerk verdient dezelfde zorg. In een hybride cluster vraagt iSCSI eigen fysieke poorten, buiten Network ATC.

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, MediaType

Komt 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.HybridConnectivity en Microsoft.Kubernetes geregistreerd.
• 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.

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.

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 ClusterTriage 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-CauRun meer, 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:

• Azure Migrate is de route van Microsoft zelf en de enige die VM's binnenbrengt als Azure Local VM's die vanuit de portal beheerd worden. Het pad vanaf Hyper-V is in september 2026 nog preview en neemt alleen VM's mee waarvan de disks op Cluster Shared Volumes staan; het VMware-pad is sinds oktober 2025 generally available. Sinds mei 2026 kan het ook naar Azure Local op SAN-storage migreren.
• 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 wanneer we een migratie begeleiden.

VM's die binnenkomen via Hyper-V Replica, een restore of een VHD-kopie zijn gewone Hyper-V VM's op het cluster. Azure beheert ze niet als Azure Local VM's zolang je dat niet apart regelt, dus plan dat per workload.

8. Vijf gotchas die we steeds tegenkomen

1. 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.
2. 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.
3. 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.
4. 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.
5. 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

De korte versie van de checklist die wij hanteren:

• 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 cluster assessment van ClusterTriage meet de huidige omgeving uitsluitend lezend en levert een rapport in het Nederlands, Engels of Duits. Met die gemeten toestand in de hand is het go/no-go voor Azure Local een onderbouwde beslissing in plaats van een gevoel. 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 kennismaking →