VMware to Hyper-V Cluster Migration: A 6-Step Pre-Migration Assessment
VMware to Hyper-V migrations in 2026 are no longer something only Microsoft shops consider. Since the Broadcom acquisition, the subscription-only licensing model has become financially untenable for many organisations, and Hyper-V plus Windows Server is the most pragmatic alternative for Microsoft-oriented infrastructures. Gartner forecasts 35% of VMware workloads will move between now and 2028. A significant portion lands on Hyper-V.
But moving the VMs is not the hard step. The hard step is determining whether the target Hyper-V cluster is actually ready to receive the workloads, and which configuration decisions you need to take now that you do not want to undo two years later. This article is the pre-migration assessment CloudLabs runs before the first VM moves.
- Why a pre-migration assessment makes the difference
- Step 1, capacity and consolidation modelling
- Step 2, network parity and VLAN mapping
- Step 3, storage assessment and CSV design
- Step 4, guest readiness and driver strategy
- Step 5, backup, DR, and runbook parity
- Step 6, cutover strategy and rollback criteria
- The tools that work in 2026
- Three pitfalls we keep seeing
1. Why a pre-migration assessment makes the difference
Most failed VMware to Hyper-V migrations we investigate afterwards are not broken because the conversion tool failed. They are broken because the Hyper-V cluster was not ready: insufficient RAM headroom for N-1, a network topology that could not map VMware port groups 1-to-1, or a backup strategy that leaned on vCenter snapshots and does not work on Hyper-V.
The assessment does four things the migration tool itself does not do. It models capacity against actual load rather than allocated values. It identifies target-environment configuration decisions that need to be per-VM properties before cutover. It surfaces operational knowledge gaps (monitoring, patching, backup procedures). And it writes a rollback criteria document so the migration team knows when to stop.
The assessment typically takes four to six working days for an environment up to 100 VMs, delivers a go/no-go recommendation, and on go a detailed migration plan that speeds up the migration phase by roughly 30% through eliminated rework. For customers ready to migrate, and for customers better off spending two more months on Hyper-V cluster hardening first.
2. Step 1, capacity and consolidation modelling
VMware and Hyper-V size resources differently. A vSphere VM with 8 vCPU and 32 GB RAM rarely uses all 8 vCPUs simultaneously, and VMware's CPU scheduler hides that efficiently. Move the same VM to Hyper-V and you get the same allocation without the same scheduler optimisations.
What we actually measure:
- CPU usage as a percentage of allocated values over a 30-day window, not peaks but P95. A VM with 8 vCPUs running at P95 12% can comfortably run with 4 vCPUs on Hyper-V, giving the cluster 50% more consolidation room.
- Active memory usage (working set), not allocated memory. VMware memory ballooning masks overcommitment, Hyper-V Dynamic Memory works differently. We model consolidation against real working set plus 20% headroom.
- Disk I/O patterns, average and P99. Hyper-V on SAN storage behaves differently from VMware on vSAN, and some workloads (strongly metadata-heavy Exchange, certain database engines) are more sensitive to CSV coordinator load than to raw throughput.
- Network traffic per VM, not just aggregates. VMs with strong east-west traffic patterns benefit from anti-affinity so they do not land on the same host during automatic balancing.
The N-1 question:
A four-node cluster must keep all workloads running on loss of one node. That means 75% of physical capacity must carry 100% of the workload, with enough RAM headroom for consolidation. We model this explicitly and document the outcome. If the N-1 state pushes RAM utilisation above 90%, there is insufficient headroom, and the recommendation becomes either more nodes, fewer workloads per node, or accepting that in N-1 state you have no Live Migration headroom.
3. Step 2, network parity and VLAN mapping
VMware port groups, distributed vSwitches, and NSX segments need to be mapped 1-to-1 to Hyper-V virtual switches, VLAN tags, and possibly SDN. Usually not complicated, but the cataloguing must be exhaustive before migration starts.
Per port group we document the VLAN ID, the naming convention to use on Hyper-V, any QoS policies, and which VMs attach to it. For distributed vSwitches with multiple uplink policies (LACP, failover order) we determine the Hyper-V equivalent: SET with dynamic load balancing, or a specific teaming mode.
For customers using NSX for microsegmentation, this is when the strategic decision happens: Hyper-V Network Virtualization, Azure Arc integration with Azure Network Security Groups for hybrid scenarios, or accept that microsegmentation gets solved post-migration at a different layer (firewall, OS-level).
What we find during network parity work:
- VMware environments with port groups that have become orphans over the years, no VMs attached but carefully planned and documented. Do we migrate them or leave them? Answer: leave them, document the decision, prevent a development team asking six months later where VLAN 247 went.
- VLAN tagging done at port group level on vSphere that must be done at VM NIC level on Hyper-V. Sounds trivial, breaks every time it is done without a pre-check.
- Promiscuous mode or MAC address changes allowed on vSphere for specific security tools must be translated to
Set-VMNetworkAdapter -MacAddressSpoofing Onper VM on Hyper-V.
4. Step 3, storage assessment and CSV design
The target Hyper-V cluster has CSVs, vSphere has VMFS datastores. The mapping is usually not 1-to-1, which is good news. It is an opportunity to redesign CSV layout based on what you now know about the workloads.
Our CSV design guidelines during a pre-migration assessment:
- CSVs per workload type, not per VMware datastore. One CSV for fileserver VMs, one for database VMs, one for general Windows Server VMs. This enables later capacity planning, snapshot strategy, and per-CSV performance tuning.
- Number of CSVs equal to or just above the number of nodes, for automatic balancing. On a four-node cluster, four to six CSVs work better than twelve, because the balancer finds even distribution more easily. See CSV ownership imbalance for what happens when this goes wrong.
- CSV size around 4 to 8 TB for SAN-attached clusters. Above 10 TB, volume operations (chkdsk, backup snapshot recovery) become operationally unwieldy.
- Plan anti-affinity and CSV placement together. Two DCs on the same CSV but forced onto different nodes still leaves a single point of failure at the storage layer. Document both.
For customers moving from VMware vSAN to Hyper-V on SAN:
A fundamental architectural shift: vSAN was hyperconverged, SAN-attached Hyper-V is not. Storage and compute paths are now separate, MPIO and zoning come back into play, and backup strategies that leaned on vSAN snapshots need to be reworked. For customers preferring to stay hyperconverged, Azure Local is a parallel track with its own readiness assessment.
5. Step 4, guest readiness and driver strategy
The VMs themselves need to be ready for Hyper-V. Biggest pitfalls:
- VMware Tools must be removed before conversion, or the first boot on Hyper-V goes wrong. On Windows guests this typically works through scheduled removal during a maintenance window, or through a script that runs automatically post-conversion.
- Hyper-V Integration Services must be present and current after conversion. For modern Windows versions (2016 and newer) this lives in the OS, for older Linux versions or legacy Windows versions manual installation may be required.
- Generation 1 vs Generation 2 decision. VMware VMs typically arrive as BIOS-boot, which is Generation 1 on Hyper-V. For modern workloads with UEFI and Secure Boot you want Generation 2, but that requires bootloader reinstallation or in some cases a full OS reinstall. Our recommendation: bring existing VMs in as Gen 1, plan Gen 2 as future modernisation, not as a migration blocker.
- Linux VMs with kernels older than 3.10 or distributions without Hyper-V Linux Integration Services cannot be reliably migrated without upgrading the kernel or distribution first. That is on its own a justifiable reason to modernise the VM rather than migrate it.
A thorough pre-migration assessment for an environment of 50 to 100 VMs takes four to six working days and delivers the difference between a migration that runs over budget and schedule, and one that delivers on time.
CloudLabs runs this as a fixed-scope engagement, delivers the report in English or Dutch as a customer-facing .docx, and includes a detailed migration runbook plus rollback criteria.
6. Step 5, backup, DR, and runbook parity
VMware-oriented operations teams have built up years of procedural knowledge: how to roll back a snapshot, how to patch vCenter clusters without vMotion storms, how to orchestrate Site Recovery Manager. That knowledge is largely not transferable.
What we capture during the assessment:
- The existing backup product and whether it is Hyper-V aware. Veeam, Commvault, Cohesity, and Rubrik all mature Hyper-V support, but configuration and best practices differ from vSphere. Expect a license change if the current license only covers vSphere.
- CSV backup mode. Hardware VSS provider vs software VSS, and what impact that has on backup windows and CSV coordinator load during the backup. This is a topic many teams only learn during the first production incident, and worth testing before cutover.
- Disaster recovery. Hyper-V Replica, Azure Site Recovery, or third-party replication? VMware Site Recovery Manager has no direct equivalent on Hyper-V, and the runbook needs to be rewritten. CloudLabs delivers a DR runbook template as part of the assessment.
- Monitoring. Which vSphere alerts exist, and what Hyper-V equivalents are available? Many SCOM management packs have seen little attention over recent years, and modern choices include Windows Admin Center plus Azure Arc, or third-party tools (PRTG, ManageEngine, Site24x7).
7. Step 6, cutover strategy and rollback criteria
The final part of the assessment is a cutover plan with explicit rollback criteria. Not "we'll see how it goes", but "if these three things are true, we roll back to vSphere".
The rollback trigger set we use as standard:
- A migrated VM does not start within 30 minutes after cutover and has no working remediation within 2 hours. Roll back.
- P99 latency on a migrated production workload is more than 2x worse than on vSphere, 72 hours after cutover. Roll back unless root cause is found and the fix is demonstrably working.
- Authentication or Active Directory issues affecting more than 5% of users and not resolved within the first maintenance window. Roll back.
Cutover order:
- Start with dev/test VMs and non-critical production. Build experience, validate scripts, refine runbooks. No critical workload in the first batch.
- Then stateless production: web-tier servers, application-tier without local state. Cutover time per VM is low, rollback is cheap.
- Finally, stateful production: databases, fileservers, identity. This is where most pre-cutover validation and most rollback worries live. Plan generous maintenance windows, and plan reserve days for unexpected issues.
Decommissioning VMware vCenter itself is the last step, not the first. A working vCenter alongside the Hyper-V cluster for six weeks after the last VM migration is cheap insurance, and we recommend it as standard.
8. The tools that work in 2026
Microsoft Windows Admin Center VM Conversion Extension (preview at the time of writing). Online migration with minimal downtime, free with Windows Admin Center. Supports Windows and modern Linux distributions. Best suited for batches up to several dozen VMs. For larger migrations we have seen better production results with SCVMM or Veeam.
System Center VMM 2025. Enterprise-scale VMware to Hyper-V conversion, up to 4x faster than previous versions. Requires offline VM conversion (source VM must be powered off), so cutover windows are longer. The right tool for large migrations (hundreds of VMs) where batching and orchestration matter more than per-VM downtime.
Veeam Backup & Replication. Restore a vSphere backup directly to Hyper-V. Works independently of conversion tools, makes rollback easier (the source stays intact), and fits environments that already use Veeam for backup. From Veeam 12.x onwards, Hyper-V target support is mature.
PowerShell with Convert-VHD plus manual hookup. For low-volume migrations and anything that does not fit the tools above. We script this as a standard option in CloudLabs migration engagements for batch VMs and dev/test environments.
Microsoft Virtual Machine Converter (MVMC) is end-of-life and no longer supported. Do not use for new migrations, regardless of how many old blog posts still link to it.
9. Three pitfalls we keep seeing
- Underestimating guest OS upgrade work. Customers plan the hypervisor migration as if it is pure infrastructure, but Windows Server 2012 R2 and 2016 are not supported on Windows Server 2025 Hyper-V. The OS upgrade sits in 30 to 60% of the VMs and needs to be in the migration plan.
- Backup license not checked before cutover. Veeam, Commvault, and others often charge per workload type. A license covering only vSphere does not cover Hyper-V. Customers discover this three days before the first cutover, then need to run a four-week procurement cycle.
- No budget for two months of parallel running. vCenter and the old VMware license stay live until after the last VM migration, plus several weeks for rollback safety. That is 2 to 4 months of double licensing cost. Factor it into the business case.
The CloudLabs approach
A pre-migration assessment runs as a fixed-scope engagement, four to six working days for environments up to 100 VMs. The deliverable includes a capacity model, a detailed migration plan per VM batch, a go/no-go recommendation, and the rollback criteria.
For customers without internal capacity for the migration itself, we also handle execution. For customers running their own migration, we deliver the runbook and stay available for escalations during cutover windows.
Schedule a VMware to Hyper-V pre-migration assessment →
Frequently asked questions
For 50 to 100 VMs, typically three to four months including assessment (4 to 6 weeks), migration execution (8 to 12 weeks in batches), and post-migration validation. Larger environments (500+) run 9 to 18 months, depending on workload complexity and cutover window availability.
Gradual works better nearly always. We see big-bang migrations only in very specific cases (datacenter move, hardware end-of-life with hard deadline). A phased approach per workload cluster gives time to refine scripts and runbooks on low-risk VMs before touching critical workloads.
Four options. Hyper-V Network Virtualization (technically mature, rarely seen in production), Azure Arc plus Azure Network Security Groups for hybrid scenarios, third-party microsegmentation tools (Illumio, Akamai Guardicore), or accept that microsegmentation gets solved post-migration at a different layer (firewall, OS-level). Which choice fits depends on regulatory requirements and what the network team can operationalise.
No. Cross-hypervisor live migration does not exist. What does work is parallel running during cutover windows and moving VMs one at a time with scheduled downtime. The WAC VM Conversion Extension offers "online migration" but that is replication plus cutover, not vMotion-style live migration.
Yes. CloudLabs has led VMware to Hyper-V migrations for customers with 50 to 800 VMs. The approach scales; the assessment phase becomes longer and cutover windows get more complex. For environments above 500 VMs we recommend tooling around SCVMM 2025 or Veeam, not the WAC extension.
VMware naar Hyper-V cluster migratie: pre-migration assessment in 6 stappen
VMware naar Hyper-V migraties zijn in 2026 niet meer iets dat alleen Microsoft-shops overwegen. Sinds de Broadcom-overname is de subscription-only licentiestructuur voor veel organisaties financieel onhoudbaar geworden, en Hyper-V plus Windows Server is voor Microsoft-georiënteerde infrastructuren het meest pragmatische alternatief. Gartner voorspelt dat 35% van de VMware-workloads tussen nu en 2028 verhuist. Een aanzienlijk deel daarvan komt op Hyper-V terecht.
Maar het verplaatsen van VM's is niet de moeilijke stap. De moeilijke stap is bepalen of het doel-Hyper-V cluster werkelijk klaar is om de workloads op te vangen, en welke configuratiebeslissingen je nu moet nemen die je over twee jaar niet wilt terugdraaien. Dit artikel is de pre-migration assessment die CloudLabs uitvoert voordat de eerste VM verhuist.
- Waarom een pre-migration assessment het verschil maakt
- Stap 1, capacity en consolidatie-modellering
- Stap 2, network parity en VLAN-mapping
- Stap 3, storage assessment en CSV-ontwerp
- Stap 4, guest readiness en driver-strategie
- Stap 5, backup, DR en runbook-pariteit
- Stap 6, cutover-strategie en rollback-criteria
- De gereedschappen die werken in 2026
- Drie valkuilen die we steeds zien
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 kost typisch vier tot zes werkdagen voor een omgeving tot 100 VM's, levert een go/no-go advies, en als het go is een gedetailleerd migratie-plan dat de migratie-fase ongeveer 30% versnelt doordat dubbel werk wordt voorkomen. 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 Onper 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.
Een grondige pre-migration assessment voor een omgeving van 50 tot 100 VM's kost vier tot zes werkdagen en levert het verschil tussen een migratie die over budget en schema loopt, en een die op tijd opgeleverd wordt.
CloudLabs voert dit uit als opdracht met vaste scope, levert het rapport in Nederlands of Engels als .docx voor de klant, en bevat een gedetailleerd migratie-runbook plus rollback-criteria.
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. CloudLabs levert 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:
- 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.
- Daarna stateless productie: web-tier servers, applicatie-tier zonder lokale state. Cutover-tijd per VM is laag, rollback is goedkoop.
- 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 in CloudLabs migratie-opdrachten voor batch-VM's en dev/test-omgevingen.
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
- 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.
- 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.
- 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 CloudLabs aanpak
Een pre-migration assessment loopt als opdracht met vaste scope, vier tot zes werkdagen voor omgevingen tot 100 VM's. 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 →
Veelgestelde vragen
Voor 50 tot 100 VM's typisch drie tot vier maanden, inclusief assessment (4 tot 6 weken), migratie-uitvoering (8 tot 12 weken in batches), en post-migratie validatie. Grotere omgevingen (500+) lopen 9 tot 18 maanden, afhankelijk van workload-complexiteit en cutover-window-beschikbaarheid.
Geleidelijk werkt vrijwel altijd beter. Big-bang migraties zien wij alleen in zeer specifieke gevallen (datacenter-verhuizing, hardware-end-of-life met harde deadline). Een gefaseerde aanpak per workload-cluster geeft je tijd om scripts en runbooks te verfijnen op laagrisico-VM's voordat je kritieke workloads aanraakt.
Vier opties. Hyper-V Network Virtualization (technisch volwassen, weinig in productie), Azure Arc plus Azure Network Security Groups voor hybride scenario's, derde-partij microsegmentation-tools (Illumio, Akamai Guardicore), of accepteer dat microsegmentation post-migratie op een ander niveau (firewall, OS-level) wordt opgelost. Welke keuze het juiste is hangt af van wettelijke eisen en wat het netwerk-team kan operationaliseren.
Nee. Cross-hypervisor live migration bestaat niet. Wat wel werkt is parallel draaien tijdens cutover-windows en VM's één voor één overzetten met geplande downtime. De WAC VM Conversion Extension biedt "online migration" maar dat is replicatie plus cutover, niet vMotion-stijl live migration.
Ja. CloudLabs heeft VMware-naar-Hyper-V migraties geleid voor klanten met 50 tot 800 VM's. De aanpak schaalt; het is wel zo dat de assessment-fase langer wordt en de cutover-windows complexer. Voor omgevingen boven 500 VM's adviseren we een tooling-keuze van SCVMM 2025 of Veeam, niet de WAC extension.