Migrate VMWare VMs with WAC

What does this extension give us?

• What: A new VM Conversion extension in Windows Admin Center (WAC) that copies VMware VMs to Hyper-V with minimal downtime.
• Why: Simple, no-cost, admin-friendly path off vSphere—great for consolidating into Hyper-V/Windows Server clusters.
• How: Online sync (initial + delta), quick cutover, and you’re managing the guest in Hyper-V/WAC minutes later.
• Status: Public Preview. Expect rough edges and keep a rollback plan.

Why this matters (and who it’s for)

If you’ve been eyeing a move from VMware to Microsoft’s stack (cost, licensing change, strategic alignment, insert-your-reason), you previously
bounced between tools, exports, and “fun” weekend cutovers. The new WAC extension brings a first-party experience to replicate and convert those workloads into Hyper-V—no expensive add-ons, No SCVMM (which I still always recommend for Hyper-V Environments) no mystery glue scripts, and far fewer “did we miss that driver?” moments.

What you get

• Minimal-downtime migration: Seed once, delta again, brief cutover.
• Batch up to 10 VMs per run, so you can slice by app stack, business unit, or change window.
• Cluster-aware: Target Windows Server Failover Cluster nodes directly.
• Multi-disk & multi-vCenter support, plus pre-checks to catch gotchas before you push the big button.
• Static IP carry-over (scripted) and Secure Boot/UEFI handling tuned by OS type.

Heads-up: Linux guests need Hyper-V drivers preinstalled. More on that below.

So… How do we get started? (don’t skip this)

On the WAC Gateway

• Windows Admin Center Gateway v2 (current preview build noted in docs)
• Install-Module VMware.PowerCLI
• Microsoft Visual C++ Redistributables (2013 + latest)
• VMware VDDK (the version specified in the docs) extracted to:
  C:\Program Files\WindowsAdminCenter\Service\VDDK
• Hyper-V role installed on the target host/cluster you’ll migrate into

VMWare Side

• vCenter 6.x or 7.x credentials + FQDN
• Remove active snapshots on VMs you plan to move
• Ensure CBT (Changed Block Tracking) is supported/enabled

Linux guests

• Install Hyper-V integration components in the source VM before you start (drivers required for a clean first boot on Hyper-V).

Install the extension

1. Open WAC → Settings > Extensions.
2. Find VM Conversion (Preview) and click Install.
3. Confirm it shows up under Extensions > VM Conversion (Preview).

How the workflow feels

1. Connect to vCenter inside the extension (FQDN + creds).
2. Select up to 10 VMs to synchronize; point at a storage path for the VHDX output.
3. Let the pre-checks run (space, CBT, snapshots, etc.). Fix anything it flags.
4. Initial sync churns away in the background while the VM stays online.
5. Cutover: pick a maintenance window, run delta sync, power off source, import on Hyper-V, and boot.
6. Post-flight: verify services, networking, and remove VMware Tools if they didn’t auto-clean.

Important: Keep your browser session active while a job runs; the UI session gates the process.

Hold up… any gotchas? Oh yeeeeaaaahhh

• Dynamic disks by design: Converted VHDX lands as dynamically expanding. If you need fixed, use
  Convert-VHD after you’re happy with the cutover.
• Memory comes over as static during migration. Flip back to Dynamic Memory later if that’s your standard.
• BIOS GUID changes: If you have tooling that keys off firmware IDs (licensing, inventory), plan to update the GUID post-migration.
• No vSAN & no “WAC in Azure portal” support (this is on-prem WAC only).
• Static IPs: The tool can persist them, but it will prompt for guest creds to capture/apply details.

When to use this vs. Azure Migrate vs. SCVMM

• Use WAC VM Conversion when you want a lightweight, first-party VMware → Hyper-V move with minimal downtime and no extra infrastructure.
• Use Azure Migrate if you’re targeting Azure or Azure Local end-states and want end-to-end assessment + migration orchestration.
• Use SCVMM if you already live in VMM land and need deep fabric control, policy, and bigger-scale scheduling.

Field notes: A quick app stack swing-over

Wait how you do this with no lab? I said I had no Hyper V Lab :-p I ended up batching a three-tier line-of-business app (web/app/DB) and synced during business hours—no one noticed. In the window,
I ran a final delta, cut power on the vSphere side, and booted on Hyper-V. App stayed happy, monitoring flipped green, and I
spent the remaining time looking like a wizard (RIP Ozzy). Your mileage may vary—test, snapshot (before you remove them for the tool), and have a back-out plan.

Useful commands & paths

# WAC gateway prereqs (run in elevated PowerShell)
Install-Module -Name VMware.PowerCLI

# VDDK folder (drop extracted VDDK here on the WAC gateway)
C:\Program Files\WindowsAdminCenter\Service\VDDK

# Convert disk to fixed size post-cutover (optional)
Convert-VHD -Path "C:\VMs\App01.vhdx" -DestinationPath "C:\VMs\App01_Fixed.vhdx" -VHDType Fixed

Troubleshooting breadcrumbs

• WAC Event Log: Applications and Services Logs > WindowsAdminCenter
• VM Conversion log: C:\Program Files\WindowsAdminCenter\Service\VMConversion_log.txt
• Stuck job? Stop the WAC service and clear the syncStatus.json/migrationStatus.json entries noted in the docs, then retry.