How to Migrate From VMware to Hyper-V With Minimal Downtime

Overview

This guide outlines a pragmatic, low-risk approach to move workloads from VMware vSphere/ESXi to Microsoft Hyper-V while keeping downtime to an absolute minimum. It combines pre-seeding data, repeatable validation, and a short, scripted cutover window.

1) Prerequisites & Planning

  • Inventory: list VMs, OS versions, CPU/RAM, disks, NICs, VLANs/portgroups, IPs, dependencies, backup/DR status.
  • Target design: choose Hyper-V host versions, cluster or standalone, storage (CSV/S2D/SAN), and vSwitch layout.
  • Maintenance window: pick a cutover slot; define acceptable downtime (e.g., <5–15 minutes per VM).
  • Backups & rollback: verified backup or snapshot on VMware, plus a tested revert plan.
  • Tools ready: disk conversion utility (e.g., StarWind V2V or qemu-img), file replication (Robocopy/Rsync), and scripts.

2) Prepare Hyper-V & Convert Disks

  • Create matching virtual switches and VLAN tagging on Hyper-V.
  • For each VM, convert VMDK → VHDX (fixed or dynamic). Prefer Generation 2 VMs for UEFI-capable OS; use Generation 1 for legacy BIOS OS.
  • Attach converted VHDX files to a placeholder VM on Hyper-V (do not boot yet).
  • Pre-create VM settings (CPU/Memory, checkpoints disabled for cutover, static MAC if needed).

3) Pre-Seed Data to Minimize Downtime

  • Windows guests: Use Robocopy with multi-threading to pre-copy application/data volumes to attached VHDX (e.g., from a helper or via SMB). Example: robocopy D:\\Data \\HyperVHost\\Share\\VM\\Data /MIR /Z /R:1 /W:1 /MT:32 /XD Temp
  • Linux guests: Use rsync for initial sync to the VHDX mount, preserving ownership and ACLs. Example: rsync -aHAX --numeric-ids --info=progress2 /data/ /mnt/hv/data/
  • Repeat the sync (incremental) right before cutover to reduce delta size.

4) Prepare OS for Hyper-V

  • Uninstall VMware Tools on the source VM (or plan to remove on first boot). Hyper-V uses its own integration services (in-box for modern Windows; Linux uses LIS/virtio equivalents).
  • Change NIC type expectations: vmxnet3 → Hyper-V synthetic adapter. Note current IP settings for re-apply.
  • Ensure bootloader compatibility (UEFI/BIOS). For Gen2, confirm GPT/UEFI support; otherwise use Gen1.

5) Isolated Test Boot

  • Boot the converted VM on Hyper-V in an isolated network (no production connectivity).
  • Verify: OS boots, disks & partitions correct, services start, app logs clean, time sync, RDP/SSH works.
  • Install/verify Hyper-V integration services as applicable; remove residual vSphere agents.
  • Shut down the test VM after validation; keep it ready for final delta sync.

6) Cutover Runbook (Per VM)

  • Announce maintenance start; freeze changes at application layer (stop app services or set read-only).
  • Take a final VMware snapshot or backup (rollback point).
  • Power off the VMware VM.
  • Run a final incremental Robocopy/Rsync to sync the last delta to the VHDX on Hyper-V.
  • On Hyper-V, attach the up-to-date VHDX and configure NICs (VLAN, static MAC if needed). Apply the original IP/DNS.
  • Boot the VM on Hyper-V. Validate quickly: ping, RDP/SSH, app health checks, logs.
  • DNS, load balancer, and firewall updates (if IP or network changed). Flush ARP caches if necessary.
  • Hand back to users; monitor closely for the first 30–60 minutes.

7) Option: Use System Center VMM (Enterprise)

  • SCVMM can orchestrate VMware discovery and conversion to Hyper-V at scale.
  • Still plan a controlled cutover: pre-checks, window, rollback, and scripted validation.

8) Post-Migration Hardening

  • Re-enable backups on Hyper-V targets; run and verify restore tests.
  • Enable monitoring/alerts; update CMDB and diagrams.
  • Remove VMware snapshots and decommission old VMs only after a defined observation period.

Rollback Plan (If Needed)

  • Power off Hyper-V VM; revert DNS/LB/firewall to VMware endpoints.
  • Revert VMware snapshot; start services; announce service restoration.
  • Investigate issue offline; repeat conversion after fix.

Common Pitfalls & Tips

  • UEFI/BIOS mismatch (Gen2 vs Gen1) → choose correct VM generation.
  • Missing drivers after conversion → ensure integration services and storage/network drivers are present.
  • Time skew after cutover → verify NTP/Hyper-V time sync settings.
  • MAC/IP changes breaking licensing → preserve MAC or re-activate licenses as required.

Example Timeline (Per VM)

  • T-7 to T-2 days: initial conversion + test boot (isolated), fix issues.
  • T-1 hour: announce window, stop non-essential jobs, incremental sync.
  • T-0: power off VMware, final delta sync (1–5 min typical), boot on Hyper-V, quick checks (2–10 min).
  • T+30 min: user validation, monitoring, close change.