TL;DR — reviewed September 4, 2026: Windows Admin Center’s VM Conversion extension remains a preview. Microsoft’s current overview lists vCenter 6.x, 7.x, and 8.x sources for migration to Hyper-V, including batches of up to 10 VMs. Plan an isolated pilot, measured downtime, application validation, and a data-aware backout decision. Preview availability is not a production-support guarantee.
Plan the pilot around compatibility and recovery
Start with the current compatibility table, then review prerequisites, identity checks, preview-only post-cutover examples, and the data-aware backout plan.
Why this matters
- Bridge strategy: Evaluate this preview when Hyper-V is a candidate destination; validate the full workload and support requirements before committing a production migration.
- Deployment model: The conversion workflow runs through a WAC extension, with its gateway dependencies and target hosts still needing preparation.
- Downtime planning: Initial synchronization can reduce cutover transfer work, but actual outage duration depends on changed data, infrastructure, and application recovery. Measure it in the pilot.
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 and UEFI to Gen 2; validate the resulting generation and Secure Boot settings for the actual guest.
- Network continuity: credential-assisted static IP handling; verify every migrated guest’s network configuration.
- Multi-disk VMs supported.
Current limitations (Preview reality check)
- Sources: vCenter 6.x, 7.x, and 8.x are now listed. Check the installed extension release and exact guest/storage scenario.
- Storage and destination limits: Microsoft’s FAQ still excludes vSAN, Azure Local destinations, and WAC in the Azure portal.
- Operations: Keep the migration session active. The documented workflow does not provide an intermediate Resync option between initial and cutover replication.
- Landing configuration: Inspect disk type, memory, VM identity, VMware Tools, and network settings after migration instead of assuming every release behaves identically.
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)
| Area | Listed scenario or requirement |
|---|---|
| WAC gateway | Gateway 2410, build 2.4.12.10 or later; verify the current installation prerequisites and extension release. |
| Gateway dependencies | PowerCLI, the required Visual C++ redistributables, and VDDK 8.0.3 at C:\Program Files\WindowsAdminCenter\Service\VDDK. Do not substitute a different VDDK version without updated vendor guidance. |
| Sources | vCenter 6.x, 7.x, and 8.x; source storage and disk configuration must also meet the preview requirements. |
| Targets | Hyper-V standalone hosts or Windows Server Failover Clusters. Azure Local is not a target for this extension. |
| Guest OS | Windows and Linux guests listed in the current guest matrix, including Windows 11. Verify the exact guest release and Hyper-V drivers; a broad OS family name is not a compatibility test. |
| Batch size | Up to 10 VMs per operation; use application dependencies to decide whether a smaller wave is safer. |
| Networking | Validate guest credentials where used, virtual switch/VLAN mapping, IP, gateway, DNS, and application reachability. |
| Preview limitations | vSAN, WAC-in-Azure, and intermediate Resync remain outside the documented scenarios. |
Prerequisites
- Prepare the gateway and required dependencies using Microsoft’s installation guide; record the WAC, extension, PowerCLI, and VDDK versions tested together. Do not blindly replace a working PowerCLI installation.
- Verify the Hyper-V role, target permissions, chosen storage path, and CPU/RAM/disk headroom.
- Use approved scoped credentials and validate connectivity for the complete gateway/source/target workflow.
- Resolve existing snapshot and CBT issues before migration prechecks, coordinated with the backup owner. Do not clear snapshot chains merely to silence a precheck.
- Prepare the destination switch/VLAN, guest addressing, DNS, and application validation plan.
- Confirm an independent recoverable backup and an isolated pilot before scheduling production cutover.
How to playbooks by use case
A) Single VM → Standalone Hyper-V host
- Install the extension: WAC → Settings → Extensions → install VM Conversion (Preview).
- Connect endpoints: In the extension, connect to vCenter. In WAC, connect to the target Hyper-V host.
- Synchronize: Select the VM → Synchronize → choose destination Path → run.
- 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.
- 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
- Group related VMs (same app or service, or rack or OU) up to 10.
- Synchronize all selected VMs to seed data while online.
- Change window: notify stakeholders, plan a short outage per app.
- Migrate the batch in one go. Validate app smoke tests (web ports, DB, queue).
- Optimize disks and memory and remove tools as a post-wave task.
C) Cluster-aware to WSFC
- Connect WAC to the cluster object (not just a node).
- Set sync Path to CSV or clustered storage.
- 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)
- Record the source BIOS UUID and the workload’s actual identity requirements. Microsoft’s release notes describe UUID preservation, while the FAQ still discusses manual repair.
- Compare source and destination values in the tested extension release. Do not run a BIOS-editing script by default or copy an example GUID; a repair needs the verified source identity, an approved outage, and workload-owner validation.
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 is now listed; vSAN remains unsupported by this extension.
- 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: the overview, release notes, and FAQ describe different cleanup behavior. Inspect the migrated guest and use the supported cleanup path for your tested release.
- 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)
- Record the gateway and extension versions and confirm the current dependency checklist.
- Prepare the approved vCenter and Hyper-V target connections.
- Validate backup recovery, snapshot/CBT prechecks, destination capacity, and network mapping.
- Synchronize a pilot, then schedule the final delta/cutover with operator coverage.
- Verify guest identity, boot, applications, networking, monitoring, backups, and any necessary Tools cleanup.
- Approve disk or memory changes separately after migration acceptance; the PowerShell examples below are previews.
Security, Zero-Trust, and DR
- Least privilege: use approved accounts scoped to the required source and destination operations.
- Gateway hardening: use trusted certificates, controlled administrator access, and documented endpoint/port rules for the actual workflow, including required infrastructure services. Protect and review exported logs.
- Identity: compare the values that matter to licensing and applications; do not modify BIOS identifiers by default.
- Recovery: verify an independent backup and the restore decision before cutover. A snapshot is not a substitute, and source migration prechecks require no active snapshots.
Evidence checklist — not a compliance certification
- Keep the approved change, tested version matrix, accountable owners, and cutover/backout criteria.
- Record migration results, application acceptance, before/after configuration, and relevant logs without exposing credentials.
- Have the organization’s security and compliance owners set access, retention, and evidence requirements. These technical checks alone do not demonstrate compliance with any particular framework.
Post-cutover automation snippets (PowerShell)
Preview a dynamic-to-fixed VHDX conversion. Convert-VHD copies to a new disk file; it does not switch the VM to that file. For a real conversion, the source must be offline and unattached, destination capacity and a new path must be checked, and the later attachment/boot test must be separately planned. Preserve the original disk until recovery and acceptance requirements are satisfied. The command below uses -WhatIf; that preview is not a readiness test.
# Preview only. Replace the host and paths with the approved values. Hyper-V\Convert-VHD -ComputerName 'hyperv.example.com' -Path 'D:\VMs\App01\App01.vhdx' -DestinationPath 'D:\VMs\App01\App01_fixed.vhdx' -VHDType Fixed -WhatIf
Preview a reviewed memory configuration. Use Set-VMMemory for startup/minimum/maximum memory settings. The example refuses a running VM and never stops or starts it. The sample sizes are illustrative; validate the guest and application requirements before approving an outage or a real change.
$hyperVHost = 'hyperv.example.com'
$vmId = 'REPLACE_WITH_APPROVED_HYPERV_VM_GUID'
$vms = @(Hyper-V\Get-VM -ComputerName $hyperVHost -Id $vmId -ErrorAction Stop)
if ($vms.Count -ne 1) { throw 'Expected exactly one approved Hyper-V VM.' }
$vm = $vms[0]
if ($vm.State -ne 'Off') { throw 'Arrange the approved shutdown separately.' }
$vm | Select-Object Name, Id, State
Hyper-V\Set-VMMemory -VM $vm -DynamicMemoryEnabled $true -StartupBytes 2GB -MinimumBytes 1GB -MaximumBytes 8GB -WhatIf
Preview a Secure Boot template only when required for the guest. Set-VMFirmware applies to Generation 2 VMs. Confirm the actual Linux distribution and its boot requirements. This example requires an already powered-off VM, previews only the template change, and does not enable or disable Secure Boot.
$hyperVHost = 'hyperv.example.com'
$vmId = 'REPLACE_WITH_APPROVED_HYPERV_VM_GUID'
$vms = @(Hyper-V\Get-VM -ComputerName $hyperVHost -Id $vmId -ErrorAction Stop)
if ($vms.Count -ne 1) { throw 'Expected exactly one approved Hyper-V VM.' }
$vm = $vms[0]
if ($vm.Generation -ne 2) { throw 'This example requires Generation 2.' }
if ($vm.State -ne 'Off') { throw 'Arrange the approved shutdown separately.' }
$vm | Select-Object Name, Id, Generation, State
Hyper-V\Set-VMFirmware -VM $vm -SecureBootTemplate 'MicrosoftUEFICertificateAuthority' -WhatIf
Verify BIOS identity before considering a repair
Do not copy a sample BIOS GUID into a migrated VM. Follow the identity checks above; if the tested release produces a mismatch that affects the workload, agree on a version-appropriate repair with the application owner and preserve the verified source value. The former unconditional BIOS-editing command is intentionally omitted.
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.
Recovery rehearsal in an isolated lab
- Use only disposable pilot copies and a written recovery procedure for session-failure testing. Do not intentionally interrupt a live migration or the only recoverable copy of a workload.
- If a migration stalls, preserve logs and inspect source, target, and application state before following the version-appropriate troubleshooting procedure. Status-file or target-VM cleanup is a separate destructive action, not a harmless refresh.
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: verify independent backup recovery, nominate the authoritative data copy, and agree on the last point at which returning to the VMware source is acceptable.
- If validation fails before the target accepts writes: isolate the Hyper-V copy, confirm no target-side changes need preservation, and obtain approval before restoring service on the original source.
- If the Hyper-V target has accepted writes: do not simply power on the stale VMware copy. Pause traffic and use the application owner’s data-reconciliation or recovery procedure.
- Before retrying: retain logs and inspect both copies and migration task state. Plan any reseeding or cleanup deliberately; never allow duplicate production identities or delete a potentially authoritative copy.
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 this a production-support guarantee? No. The extension remains preview in the current documentation; establish the support and risk decision for the workload.
- What about vCenter 8.x and vSAN? vCenter 8.x is now listed. vSAN remains excluded; those are separate compatibility questions.
- What about Azure Local? This extension does not target Azure Local. Evaluate the documented Azure Migrate route for that destination.
What to do next
- Start with a small, isolated set of representative guests and measure the full migration and acceptance process.
- Group waves by application dependencies, staying within the documented per-operation limit.
- Maintain migration, validation, data-aware backout, and separately approved optimization runbooks.
- For excluded storage, guest, destination, or scale requirements, evaluate another migration approach against its own current support matrix. Do not reject vCenter 8.x merely because this article previously omitted it.
The Definitive Guide to Data Gravity: Mastering Performance, Compliance, and Architecture in Hybrid and Multi-Cloud
Table of Contents 1. What Is Data Gravity? Data gravity describes how large datasets create “inertia” that attracts applications, services, and other...