VMware to Hyper-V Cluster Migration: A 6-Step Pre-Migration Assessment

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 delivers a go/no-go recommendation, and on go a detailed migration plan that prevents rework in the migration phase. 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 On per 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 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.

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. We deliver 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:

1. Start with dev/test VMs and non-critical production. Build experience, validate scripts, refine runbooks. No critical workload in the first batch.
2. Then stateless production: web-tier servers, application-tier without local state. Cutover time per VM is low, rollback is cheap.
3. 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 for batch VMs and dev/test environments whenever we guide a migration.

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

1. 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.
2. 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.
3. 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 ClusterTriage approach

A pre-migration assessment starts from a measured baseline of the current cluster. 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 →