VMware naar Hyper-V cluster migratie: pre-migration assessment in 6 stappen

1. Waarom een pre-migration assessment het verschil maakt

De meeste mislukte VMware naar Hyper-V migraties die wij achteraf onderzoeken zijn niet kapot omdat de conversie-tool faalde. Ze zijn kapot omdat het Hyper-V cluster niet klaar was: te weinig RAM-headroom voor N-1, een netwerk-topologie die VMware's port groups niet 1-op-1 kon afbeelden, of een backup-strategie die op vCenter-snapshots leunde en op Hyper-V niet werkt.

De assessment doet vier dingen die de migratie-tool zelf niet doet. Het modelleert capaciteit tegen werkelijke load, niet tegen toegewezen waardes. Het identificeert configuratiebeslissingen op de doelomgeving die per-VM eigenschappen moeten zijn vóór cutover. Het brengt operationele kennis-gaten in kaart (monitoring, patching, backup-procedures). En het schrijft een rollback-criteria-document zodat het migratie-team weet wanneer ze stoppen.

De assessment levert een go/no-go advies, en als het go is een gedetailleerd migratie-plan dat dubbel werk in de migratie-fase voorkomt. Voor klanten die er klaar voor zijn, en voor klanten waar het beter eerst nog twee maanden Hyper-V cluster-hardening kost.

2. Stap 1, capacity en consolidatie-modellering

VMware en Hyper-V dimensioneren resources anders. Een vSphere VM met 8 vCPU en 32 GB RAM gebruikt zelden alle 8 vCPU's tegelijk, en VMware's CPU scheduler verbergt dat efficiënt. Wanneer je diezelfde VM verplaatst naar Hyper-V, krijg je dezelfde toewijzing maar zonder dezelfde scheduler-optimalisaties.

Wat we werkelijk meten:

• CPU usage als percentage van toegewezen waardes over een periode van 30 dagen, niet pieken maar P95. Een VM met 8 vCPU's die P95 op 12% draait, kan op Hyper-V comfortabel met 4 vCPU's draaien, en geeft het cluster 50% meer consolidatie-ruimte.
• Actief geheugen-gebruik (working set), niet toegewezen geheugen. VMware's memory ballooning maskeert overcommitment, Hyper-V's Dynamic Memory werkt anders. We modelleren consolidatie tegen werkelijke working set plus 20% headroom.
• Disk I/O patronen, gemiddeld en P99. Hyper-V op SAN-storage gedraagt zich anders dan VMware op vSAN, en sommige workloads (sterk metadata-zware Exchange, bepaalde database-engines) zijn gevoeliger voor CSV coordinator-load dan voor pure throughput.
• Netwerkverkeer per VM, niet alleen totalen. VM's met sterke oost-west traffic patronen profiteren van anti-affinity zodat ze niet op dezelfde host eindigen tijdens automatische balancing.

De N-1 vraag:

Een vier-node cluster moet bij verlies van één node alle workloads kunnen blijven draaien. Dat betekent dat 75% van de fysieke capaciteit het 100% van de workload moet kunnen dragen, met genoeg RAM-headroom voor consolidatie. Wij modelleren dit expliciet en documenteren de uitkomst. Als de N-1 toestand boven 90% RAM-gebruik uitkomt, is er onvoldoende headroom en wordt het advies óf meer nodes, óf minder workloads per node, óf accepteren dat je in N-1 toestand geen Live Migration-headroom hebt.

3. Stap 2, network parity en VLAN-mapping

VMware's port groups, distributed vSwitches, en NSX-segmenten moeten 1-op-1 worden afgebeeld op Hyper-V's virtuele switches, VLAN-tags, en eventueel SDN. Dit is meestal niet ingewikkeld, maar de catalogering moet exhaustief zijn vóór de migratie start.

Per port group documenteren we het VLAN-ID, de naamgevingsconventie die op Hyper-V gebruikt gaat worden, eventuele QoS-policies, en welke VM's eraan hangen. Voor distributed vSwitches met meerdere uplink-policies (LACP, failover-volgorde) bepalen we het Hyper-V equivalent: SET met dynamische load balancing, of een specifieke teaming-modus.

Voor klanten die NSX gebruiken voor microsegmentation, is dit het moment waarop de strategische keuze wordt gemaakt: Hyper-V Network Virtualization, Azure Arc-integratie met Azure Network Security Groups voor hybride scenario's, of accepteer dat microsegmentation post-migratie op een ander niveau (firewall, OS-level) wordt opgelost.

Wat we vinden bij netwerkparity:

• VMware-omgevingen met port groups die over de jaren heen "weesjes" zijn geworden, geen VM's meer aan, maar wel zorgvuldig gepland en gedocumenteerd. Migreren we die mee of laten we ze achter? Antwoord: laat achter, documenteer beslissing, voorkom dat een development-team over zes maanden vraagt waar VLAN 247 gebleven is.
• VLAN-tagging die op vSphere op port group-niveau zit en op Hyper-V op VM-NIC-niveau moet. Klinkt triviaal, breekt elke keer dat het zonder pre-check wordt gedaan.
• Promiscuous mode of MAC address changes die op vSphere zijn toegestaan voor specifieke security-tools, op Hyper-V moeten worden vertaald naar Set-VMNetworkAdapter -MacAddressSpoofing On per VM.

4. Stap 3, storage assessment en CSV-ontwerp

Het doel-Hyper-V cluster heeft CSV's, vSphere heeft VMFS datastores. De afbeelding is meestal niet 1-op-1, en dat is goed nieuws. Het is een kans om CSV-ontwerp opnieuw te doen op basis van wat je nu weet over de workloads.

Onze CSV-ontwerprichtlijnen tijdens een pre-migration assessment:

• CSV's per workload-type, niet per VMware datastore. Eén CSV voor file-server VM's, één voor database-VM's, één voor algemene Windows Server VM's. Dit maakt latere capaciteits-planning, snapshot-strategie en performance-tuning per CSV mogelijk.
• Aantal CSV's gelijk aan of net boven het aantal nodes, voor automatische balancing. Op een vier-node cluster werkt vier tot zes CSV's beter dan twaalf, omdat de balancer dan makkelijker een gelijkmatige verdeling vindt. Zie CSV ownership onbalans voor de gevolgen wanneer dit fout gaat.
• CSV-grootte rond 4 tot 8 TB voor SAN-attached clusters. Boven 10 TB worden volume-acties (chkdsk, backup-snapshot recovery) operationeel onhandelbaar.
• Anti-affinity en CSV-toewijzing samen plannen. Twee DC's op dezelfde CSV maar geforceerd op verschillende nodes, levert nog steeds een single-point-of-failure op de storage-laag. Documenteer beide.

Voor klanten met VMware vSAN die naar Hyper-V op SAN gaan:

Een fundamentele architecturele keuze: vSAN was hyperconverged, SAN-attached Hyper-V is niet. De storage- en compute-paden zijn nu apart, MPIO en zoning komen weer in beeld, en backup-strategieën die op vSAN-snapshots leunden moeten herzien worden. Voor klanten die liever hyperconverged blijven, is Azure Local een aanvullend traject met een eigen readiness-assessment.

5. Stap 4, guest readiness en driver-strategie

De VM's zelf moeten klaar zijn voor Hyper-V. De grootste valkuilen:

• VMware Tools moet verwijderd worden vóór conversie, of de eerste boot op Hyper-V gaat de mist in. Op Windows-guests werkt dit meestal via een geplande verwijdering tijdens een onderhoudsvenster, of via een script dat post-conversie automatisch draait.
• Hyper-V Integration Services moet aanwezig en up-to-date zijn na conversie. Voor moderne Windows-versies (2016 en hoger) zit dit in het OS, voor oudere Linux-versies of legacy Windows-versies kan handmatige installatie nodig zijn.
• Generation 1 vs Generation 2 keuze. VMware VM's komen typisch als BIOS-boot binnen, wat Generation 1 op Hyper-V is. Voor moderne workloads met UEFI en Secure Boot wil je Generation 2, maar dat vereist een herinstallatie van de bootloader of in sommige gevallen een complete OS-herinstallatie. We adviseren: laat bestaande VM's als Gen 1 binnenkomen, plan Gen 2 als toekomstige modernisering, niet als migratie-blokker.
• Linux-VM's met kernel ouder dan 3.10 of distributies zonder Hyper-V Linux Integration Services kunnen niet betrouwbaar gemigreerd worden zonder eerst de kernel of distributie te upgraden. Dit is op zichzelf een gerechtvaardigde reden om de VM in plaats van migratie te moderniseren.

6. Stap 5, backup, DR en runbook-pariteit

VMware-georiënteerde operations-teams hebben jaren aan procedurele kennis opgebouwd: hoe een snapshot terug te draaien, hoe vCenter-clusters te patchen zonder vMotion-stormen, hoe Site Recovery Manager te orkestreren. Die kennis is grotendeels niet overdraagbaar.

Wat we tijdens de assessment vastleggen:

• Het bestaande backup-product en of het Hyper-V-bewust is. Veeam, Commvault, Cohesity en Rubrik ondersteunen Hyper-V allemaal volwassen, maar configuratie en best practices zijn anders dan op vSphere. Verwacht een licentiewijziging als de huidige licentie alleen vSphere dekt.
• CSV backup-modus. Hardware VSS provider vs software VSS, en welke impact dat heeft op backup-windows en CSV-coordinator load tijdens de backup. Dit is een onderwerp dat veel teams pas leren tijdens het eerste productie-incident, en het is de moeite waard om vóór cutover te toetsen.
• Disaster recovery. Hyper-V Replica, Azure Site Recovery, of derde-partij replicatie? VMware Site Recovery Manager heeft geen directe equivalent op Hyper-V, en het runbook moet opnieuw worden geschreven. Wij leveren een DR-runbook-template als onderdeel van de assessment.
• Monitoring. Welke alarmen op vSphere zijn er, en welke Hyper-V equivalenten bestaan? Veel SCOM management packs hebben de afgelopen jaren weinig aandacht gekregen, en moderne keuzes zijn Windows Admin Center plus Azure Arc, of derde-partij tools (PRTG, ManageEngine, Site24x7).

7. Stap 6, cutover-strategie en rollback-criteria

Het laatste deel van de assessment is een cutover-plan met expliciete rollback-criteria. Niet "we kijken hoe het loopt", maar "als deze drie dingen waar zijn, draaien we terug naar vSphere".

De rollback-trigger-set die wij standaard hanteren:

• Een gemigreerde VM start niet binnen 30 minuten na cutover en heeft geen werkende remediation binnen 2 uur. Terug naar bron.
• P99 latency op een gemigreerde productie-workload is meer dan 2x slechter dan op vSphere, 72 uur na cutover. Terug naar bron tenzij oorzaak gevonden en oplossing aantoonbaar werkt.
• Authenticatie of Active Directory-issues die meer dan 5% van de gebruikers raken en niet binnen het eerste onderhoudsvenster zijn opgelost. Terug naar bron.

Cutover-volgorde:

1. Begin met dev/test-VM's en niet-kritieke productie. Ervaring opbouwen, scripts valideren, runbooks bijschaven. Geen kritieke workload mag in de eerste batch zitten.
2. Daarna stateless productie: web-tier servers, applicatie-tier zonder lokale state. Cutover-tijd per VM is laag, rollback is goedkoop.
3. Tot slot stateful productie: databases, fileservers, identity. Dit is waar de meeste pre-cutover validatie en de meeste rollback-zorgen zitten. Plan ruime maintenance windows, en plan ook reservedagen voor onverwachte issues.

VMware vCenter zelf decommissioneren is de laatste stap, niet de eerste. Een werkende vCenter naast het Hyper-V cluster voor zes weken na de laatste VM-migratie is goedkope verzekering, en wij adviseren het standaard.

8. De gereedschappen die werken in 2026

Microsoft Windows Admin Center VM Conversion Extension (preview op het moment van schrijven). Online migratie met minimale downtime, gratis bij Windows Admin Center. Ondersteunt Windows en moderne Linux-distributies. Vooral geschikt voor batches tot enkele tientallen VM's. Voor grotere migraties hebben we in productie betere resultaten gezien met SCVMM of Veeam.

System Center VMM 2025. Enterprise-schaal VMware-naar-Hyper-V conversie, tot 4x sneller dan eerdere versies. Vereist offline VM-conversie (bron-VM moet uit staan), dus de cutover-windows zijn langer. Het juiste gereedschap voor grote migraties (honderden VM's) waar batching en orkestratie belangrijker zijn dan downtime per VM.

Veeam Backup & Replication. Restore een vSphere-backup direct naar Hyper-V. Werkt onafhankelijk van conversie-tools, maakt rollback eenvoudiger (de bron blijft intact), en past goed bij omgevingen die Veeam al voor backup gebruiken. Vanaf Veeam 12.x is de Hyper-V target-ondersteuning volwassen.

PowerShell met Convert-VHD plus handmatige hookup. Voor low-volume migraties en alles wat zich niet leent voor de bovenstaande tools. Wij scripten dit standaard mee voor batch-VM's en dev/test-omgevingen wanneer we een migratie begeleiden.

Microsoft Virtual Machine Converter (MVMC) is end-of-life en niet meer ondersteund. Niet gebruiken voor nieuwe migraties, ongeacht hoeveel oude blogposts er nog naar verwijzen.

9. Drie valkuilen die we steeds zien

1. Onderschatting van guest OS-upgrade-werk. Klanten plannen de hypervisor-migratie alsof het puur infrastructuur is, maar Windows Server 2012 R2 en 2016 worden niet ondersteund op Windows Server 2025 Hyper-V. De OS-upgrade zit in 30 tot 60% van de VM's en moet in de migratie-planning.
2. Backup-licentie niet gecheckt vóór cutover. Veeam, Commvault en anderen rekenen vaak per workload-type. Een licentie die alleen vSphere dekt, dekt geen Hyper-V. Klanten ontdekken dit drie dagen vóór de eerste cutover, en moeten dan een procurement-cyclus van vier weken doorlopen.
3. Geen budget voor twee maanden parallel draaien. vCenter en de oude VMware-licentie blijven actief tot na de laatste VM-migratie, plus enkele weken voor rollback-veiligheid. Dat is in totaal 2 tot 4 maanden dubbele licentiekosten. Reken het mee in de business case.

De ClusterTriage aanpak

Een pre-migration assessment begint met een gemeten baseline van het huidige cluster. De oplevering bevat een capaciteits-model, een gedetailleerd migratie-plan per VM-batch, een go/no-go-advies, en de rollback-criteria.

Voor klanten die geen interne capaciteit hebben voor de migratie zelf, doen wij ook de uitvoering. Voor klanten die zelf willen migreren, leveren we het runbook en blijven we beschikbaar voor escalaties tijdens cutover-vensters.

Plan een VMware naar Hyper-V pre-migration assessment →