Compliance checkpoints (examples)

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)?

Cutover gates

  • 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.

Set-VMFirmware -VMName “Ubuntu01” -SecureBootTemplate “MicrosoftUEFICertificateAuthority”

# 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)

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.

Key capabilities

  • 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.

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

Artifacts to collect

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

Current limitations (Preview reality check)

Chaos with low blast radius

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

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

Convert dynamic VHDX to fixed

  • 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.

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).

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

Cons

  • 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.

Similar Posts