TL;DR:
Microsoft’s new VM Conversion extension in Windows Admin Center (WAC) v2 provides a no-cost, agentless way to convert VMware VMs (vCenter 6.x and 7.x) to Hyper-V with minimal downtime using CBT seeding plus a delta cutover. It supports batches up to 10, is cluster-aware, persists static IPs, and auto-maps BIOS to Gen 1 and UEFI to Gen 2. Because it is Public Preview, plan tight validation, explicit rollback, and a few post-cutover cleanups (VMware Tools removal, dynamic to fixed disks, memory settings).

Why this matters

• Bridge strategy: If you are standardizing on Windows Server and Hyper-V while keeping workloads on-prem for compliance or latency, this provides a supported, fast V2V route without extra appliances.
• Minimal infra lift: Runs as a WAC extension, no separate migration server farm.
• Predictable downtime: Seed live, then short cutover with delta replication.

What is VM Conversion (Preview)?

Key capabilities

• Agentless discovery of vCenter VMs.
• Minimal downtime: initial sync while source is online, then final delta after powering down at cutover.
• Up to 10 VMs per batch to accelerate waves.
• Cluster-aware: target a Hyper-V failover cluster (WSFC) or standalone host.
• Boot mapping: BIOS to Gen 1, UEFI to Gen 2; Secure Boot handled appropriately.
• Network continuity: static IP persistence through capture and apply.
• Multi-disk VMs supported.

Current limitations (Preview reality check)

• Sources: vCenter 6.x and 7.x (8.x not listed).
• Storage: vSAN not supported.
• Target: Hyper-V only (not Azure Local). Not available in WAC-in-Azure.
• UX and ops: Migration requires an active signed-in browser session. There is no resync between initial and delta replication.
• Landing config: Disks arrive as dynamic VHDX. Memory is set to static during migration. You can re-enable Dynamic Memory post-cutover.

Architecture at a glance

Flow: vCenter → VDDK and PowerCLI on WAC gateway → Hyper-V host or cluster (VHDX) → import VM → post-cutover cleanup.

Compatibility and supported matrix (Preview)

Prerequisites

• WAC v2 Gateway (2410 GA) installed and reachable.
• On the WAC gateway:
  • VMware PowerCLI (Install-Module VMware.PowerCLI).
  • Visual C++ Redistributables (2013 plus latest).
  • VDDK 8.0.3 extracted to ...ServiceVDDK.
• Hyper-V role on the destination host or cluster. Storage path (CSV or volume) ready.
• vCenter credentials (FQDN, user, password).
• No snapshots on sources. CBT enabled. Destination has CPU, RAM, and storage headroom.
• Networking: desired vSwitch or VLAN present. IP plan validated.

How to playbooks by use case

A) Single VM → Standalone Hyper-V host

1. Install the extension: WAC → Settings → Extensions → install VM Conversion (Preview).
2. Connect endpoints: In the extension, connect to vCenter. In WAC, connect to the target Hyper-V host.
3. Synchronize: Select the VM → Synchronize → choose destination Path → run.
4. Migrate (cutover): Migrate tab → select VM → Migrate. The tool runs prechecks, performs delta replication, powers off the source, performs a final delta, then imports to Hyper-V. Keep the browser session active.
5. Post-cutover:
   • Verify boot, services, and NIC or vSwitch mapping.
   • If static IP, confirm it persisted.
   • Disks: convert to fixed if policy requires (script below).
   • Memory: re-enable Dynamic Memory if desired.
   • Tools: remove VMware Tools if still present.

B) Batch wave (up to 10 VMs) for an app stack

1. Group related VMs (same app or service, or rack or OU) up to 10.
2. Synchronize all selected VMs to seed data while online.
3. Change window: notify stakeholders, plan a short outage per app.
4. Migrate the batch in one go. Validate app smoke tests (web ports, DB, queue).
5. Optimize disks and memory and remove tools as a post-wave task.

C) Cluster-aware to WSFC

1. Connect WAC to the cluster object (not just a node).
2. Set sync Path to CSV or clustered storage.
3. Use the same Synchronize → Migrate flow. The tool imports the VM to the cluster.

D) Linux guests

• Ensure Hyper-V drivers are present. Modern kernels include them. Older distros may need LIS.
• For Gen 2 Linux, set the UEFI CA Secure Boot template if Secure Boot is enabled.
• After import, check grub and initramfs. Validate networking and time sync.

E) Static IP persistence

• When prompted, supply guest OS credentials so the tool can capture and apply the static IP at cutover.
• Validate IP, subnet, gateway, and DNS suffix after boot.

F) Identity-sensitive workloads (BIOS GUID)

• If licensing or identity keys off the BIOS GUID, update it post-cutover using Microsoft’s provided script. Test carefully.

Pros, cons, and gotchas

Pros

• Free, agentless, appliance-free. Installs as a WAC extension.
• Minimal downtime using CBT and delta cutover.
• Batching up to 10 and cluster-aware targeting.
• Static IP persistence and boot mapping handled.

Cons

• Preview status brings production risk and evolving UX.
• vCenter 8.x not listed. vSAN unsupported.
• Active browser session required during migration. No resync between seed and delta.
• VMs land as dynamic VHDX. Memory forced static during migration.

Gotchas to watch

• VMware Tools: preview docs are inconsistent, so plan for manual removal post-cutover for Windows guests.
• Linux drivers: confirm Hyper-V drivers, or LIS for older distros, before migrating.
• Storage governance: dynamic VHDX is space-efficient but may violate quota or chargeback. Convert to fixed if required.
• Ports and reachability: WAC listening port varies. Ensure inbound and outbound rules and internal WAC ports are allowed.
• Session dependency: if your session times out, migration can stall. Plan operator coverage until completion.

Implementation checklist (operators)

1. Upgrade WAC to v2 (2410 GA).
2. On the WAC gateway, install PowerCLI, VC++ 2013 plus latest, and VDDK 8.0.3 at ...ServiceVDDK.
3. Install the extension in WAC.
4. Add vCenter and connect Hyper-V target (host or cluster).
5. Prechecks: no snapshots, CBT present, capacity OK, vSwitch prepared.
6. Synchronize to seed, then Migrate for delta and cutover.
7. Post-cutover: VMware Tools clean-up if needed, disk conversions, memory policy, monitoring baselines.

Security, Zero-Trust, and DR

• Least privilege: use scoped migration accounts for vCenter and Hyper-V.
• WAC hardening: use CA-issued certs, lock the gateway, restrict inbound to the chosen port, restrict outbound to vCenter and Hyper-V only, forward WAC logs to SIEM.
• Identity continuity: if BIOS GUID matters, update it after cutover.
• Backups: ensure recent backups or snapshots before migration. Validate restore on the destination.

Compliance checkpoints (examples)

• SOC 2 and PCI DSS change management: RFC approval and evidence (WAC notifications and migration logs).
• HIPAA and PCI logging: centralize WindowsAdminCenter event logs and VMConversion_log.txt.
• FedRAMP and CJIS: MFA to WAC, network segmentation, role separation. Retain logs at least one year.

Post-cutover automation snippets (PowerShell)

Convert dynamic VHDX to fixed

Convert-VHD -Path "D:VMsApp01App01.vhdx" `
  -DestinationPath "D:VMsApp01App01_fixed.vhdx" -VHDType Fixed

Re-enable Dynamic Memory

Stop-VM App01
Set-VM -Name App01 -DynamicMemoryEnabled $true `
  -MemoryStartupBytes 2GB -MinimumBytes 1GB -MaximumBytes 8GB
Start-VM App01

Secure Boot template for Gen 2 Linux (UEFI CA)

Set-VMFirmware -VMName "Ubuntu01" -SecureBootTemplate "MicrosoftUEFICertificateAuthority"

Update BIOS GUID if required

# After saving Microsoft's script as Update-VMBiosInfo.ps1
.Update-VMBiosInfo.ps1 -VMName "Contoso" -BiosGuid "{423A2700-F96D-561B-B421-C3088111A97B}"

Validation and testing (pre-prod first)

Pre-cutover gates

• Tool prechecks pass (CBT, capacity, no snapshots).
• A representative pilot VM seeds and migrates, boots cleanly, and app smoke tests pass.

Cutover gates

• Boot and services OK. Time sync and EDR healthy.
• Network: correct switch, IP persisted, DNS registered. AD secure channel intact.
• App smoke tests for HTTP 200, DB connect, and queues.

Chaos with low blast radius

• As a controlled drill, sign out the browser during a pilot to confirm stall behavior and your operator handoff or runbook for recovery.

Artifacts to collect

• WAC notifications export, Event Viewer WindowsAdminCenter logs, VMConversion_log.txt, and before or after VM configuration captures.

Backout plan (keep this simple)

• Before cutover: confirm latest backup, declare authoritative data source, schedule a short maintenance window.
• If post-cutover fails:
  1. Power off the Hyper-V VM to avoid IP or MAC conflicts.
  2. Power on the original VMware VM and validate services.
  3. Collect logs and plan a retry. There is no resync, so re-seed.

FinOps and Sustainability quick hits

• Dynamic VHDX reduces initial storage footprint but may surprise chargeback, so normalize to fixed where policy demands.
• Use cutover windows that align with off-peak energy or carbon intensity if your data center or utility publishes it.
• Validate host consolidation targets to avoid over-provisioning post-migration, and re-enable Dynamic Memory where appropriate.

FAQs you will get from leadership

• Is it production-ready? Not yet. It is Public Preview. Use for pilots and targeted migrations with explicit rollback.
• Can we use it for vCenter 8.x or vSAN? It is not listed. Treat as unsupported today.
• What about Azure Local? Not supported by this tool. Use Azure Migrate for Azure or Azure Local moves.

What to do next

1. Pilot 3 to 5 VMs, both Windows and Linux, through the full flow.
2. Wave planning: group up to 10 VMs per window aligned to business services.
3. Runbooks: migration, validation, backout, and post-cutover optimization.
4. Decision gate: if you hit preview limits such as vCenter 8.x or vSAN or scale, pivot those subsets to SCVMM or a third-party V2V tool.

The post VM Conversion in Windows Admin Center (Public Preview): A Field Guide for VMware to Hyper-V appeared first on Digital Thought Disruption.