Microsoft has released a public preview of a long-awaited, first-party VM Conversion extension inside Windows Admin Center. The new capability gives administrators a built-in, agentless path for migrating virtual machines from VMware vCenter and ESXi to Hyper-V—without third-party tools, scripts, or separate appliances. The extension lands in Windows Admin Center v2 (generally available) under the Extensions panel and is aimed squarely at on-premises modernization, not cloud lift-and-shift.

For years, moving VMs off VMware onto Microsoft’s hypervisor has meant relying on community scripts, costly vendor utilities, or complex deployments. By embedding conversion directly into the Windows Admin Center management plane, Microsoft is eliminating that friction. The tool is free and GUI-driven, making it accessible to IT generalists who may not have deep virtualization migration experience. However, the preview label means administrators should avoid production workloads until the feature reaches general availability.

What the VM Conversion Extension Delivers

The extension provides a complete workflow from discovery to cutover. It is built around a two-phase replication model that uses VMware’s Change Block Tracking (CBT) and the Virtual Disk Development Kit (VDDK) to copy used blocks while the source VM stays online. Key capabilities include:

  • Agentless replication – No guest-side agent required for the bulk of the migration, cutting operational overhead.
  • CBT‑based sync – Initial full copy runs while the VM is live; a brief shutdown is needed only for the final delta pass, keeping downtime to minutes in ideal conditions.
  • Batch migrations – Up to 10 VMs can be synchronized in one batch, with the gateway handling parallel processing.
  • Cross‑guest support – Both Windows and mainstream Linux distributions are supported. Linux guests should have Hyper‑V integration services (LIS) installed for reliable first boot.
  • Multi‑disk and boot mapping – The tool handles multiple virtual disks and automatically maps BIOS/Generation 1 or UEFI/Generation 2 boot types. Disks are written as dynamically expanding VHDX by default.
  • No separate appliance – All conversion logic runs on the Windows Admin Center gateway, leveraging VMware VDDK and PowerCLI. No extra VMs or hardware are required.

These features centralize discovery, prechecks, replication, conversion, and Hyper‑V import into a single pane, designed to make on‑premises moves faster and less error‑prone.

Prerequisites: What You’ll Need Before You Start

The preview imposes a specific set of requirements. Administrators must satisfy all of them before attempting a migration:

  • Windows Admin Center gateway V2 (GA) installed and reachable.
  • Hyper‑V role present on the destination host(s).
  • VMware PowerCLI installed on the gateway: Install-Module -Name VMware.PowerCLI.
  • VMware VDDK unpacked into the gateway service folder; the preview explicitly calls out VDDK 8.0.3.
  • Microsoft Visual C++ and older runtime components on the gateway, as required by the VDDK.
  • vCenter/ESXi source versions supported: vCenter/ESXi 7.x is noted in the guidance.
  • No active snapshots on source VMs during initial sync—these will cause precheck failures.

Additionally, ensure sufficient temporary storage on the destination for the initial replica, proper credential handling for vCenter and Hyper‑V hosts, and log integration (VMConversion_log.txt) into SIEM and audit pipelines if required by your compliance regime.

How the Migration Flow Works Step by Step

The conversion follows a clear, two-phase process:

  1. Install the extension in Windows Admin Center under Extensions > Available Extensions.
  2. Add and connect to the target Hyper‑V host(s) and one or more vCenter instances using FQDN and credentials. WAC auto‑discovers VMs from connected vCenter servers.
  3. Select up to 10 VMs for synchronization, choose a storage path for the initial replica, and run the automated prechecks. Fix any red flags (snapshots, CBT availability, storage, boot config, disk format).
  4. Start Synchronize – The gateway uses CBT and VDDK to copy used blocks into dynamically expanding VHDX files on the destination while the source VM continues to run.
  5. Final cutover – Once initial sync completes and readiness checks pass, schedule or perform the cutover: the source VM is powered off, a final CBT delta pass captures last changes, and WAC imports and configures the VM on Hyper‑V.
  6. Post‑migration steps – Uninstall VMware Tools if you didn’t beforehand, confirm Hyper‑V Integration Services are enabled (or install Hyper‑V drivers for Linux), verify network and DNS settings, and convert VHDX to fixed size if performance demands it.

This two‑phase approach minimizes visible downtime: the bulk of data transfers while the VM is live, and only the final delta requires a brief shutdown. The offline window depends on the active write rate during the cutover period and the speed of your storage and network.

Where the Extension Shines

The tool’s strengths make it particularly attractive for SMEs and departmental IT teams running smaller vSphere clusters:

  • First‑party integration – Conversion happens within Microsoft’s supported management plane, reducing reliance on third‑party tools and centralizing governance.
  • Agentless, appliance‑free architecture – No guest agents or separate conversion appliances lower deployment complexity and ongoing maintenance.
  • CBT and batch sync – Change Block Tracking avoids re‑copying unchanged data, and batch support lets you migrate multiple workloads in parallel.
  • Mixed workload support – Native handling of both Windows and popular Linux distributions fits heterogeneous datacenter environments.
  • Automated boot mapping and disk handling – The tool reduces manual steps during import, automatically mapping BIOS to Gen 1 and UEFI to Gen 2, and handling multiple disks.

For organizations that want a lower‑friction route to standardize on Hyper‑V while retaining hybrid options for Azure integration later, this extension is a welcome addition.

Important Limitations in the Preview

Despite its promise, the public preview has significant gaps that demand careful planning:

  • Preview status – The feature is not feature‑complete and may change before GA. Do not assume feature parity with mature conversion products yet.
  • Strict prechecks – Failures on checks for active snapshots, incompatible disk types, or insufficient storage will block synchronization. These must be remediated before proceeding.
  • Thin provisioning by default – Disks are created as dynamically expanding VHDX. Administrators who prefer fixed VHDX must run a post‑migration conversion that consumes additional time and I/O.
  • No automatic VMware Tools removal – The preview does not uninstall VMware Tools during or after conversion. Leftover tools can cause driver conflicts; you must manually remove them and then install Hyper‑V Integration Services.
  • Performance variability – Marketing claims of “migration in a few minutes” are best‑case. Large disks, heavy I/O on the source, and limited network or storage bandwidth will significantly extend sync and cutover times.
  • No resync or recovery features – Some recovery workflows, such as Resync, are not supported in the current preview, limiting your ability to recover from transfer errors without manual intervention.

These caveats mean the extension is best used initially in lab or pilot projects to build institutional knowledge and documented runbooks before any production‑scale migration.

Practical Migration Checklist and Runbook

A disciplined runbook reduces surprises. The following condensed checklist reflects the extension’s documented behavior:

  1. Inventory – Identify VMs to migrate and capture configuration (disk count, boot type, OS, installed tools).
  2. Lab test – Deploy WAC v2 and the VM Conversion extension in a lab; perform a full test migration on a non‑critical VM.
  3. Validate prerequisites – Confirm PowerCLI, the correct VDDK in the gateway service folder, Visual C++ runtimes, Hyper‑V role, and network reachability.
  4. Address snapshots – Remove or consolidate snapshots on source VMs; re‑run prechecks until green.
  5. Schedule sync windows – Plan the initial sync during low‑I/O periods and the final cutover during maintenance windows.
  6. Monitor logs – Capture VMConversion_log.txt and integrate with monitoring; watch for precheck and replication warnings.
  7. Post‑migration validation – Uninstall VMware Tools, confirm Hyper‑V Integration Services, verify network/DNS/IP configuration, and run application smoke tests.
  8. Rollback plan – Keep a snapshot or backup outside the migration operation to allow rollback if the final cutover fails. Note that the tool’s preview limitations may force manual recovery.

Following this sequence separates technical conversion steps from organizational approvals (procurement, licensing) that often drive the overall migration timeline.

Security, Compliance, and Credential Management

The extension requires privileged credentials for vCenter and Hyper‑V targets and writes sensitive logs to the WAC gateway. This introduces several high‑risk areas:

  • Enforce least‑privilege accounts for the extension and rotate credentials after migration.
  • Harden the Windows Admin Center gateway and its service account; a compromised gateway could expose migration artifacts and credentials.
  • Integrate logs into your SIEM and maintain an auditable trail for compliance reviews; log retention should meet organizational policies.
  • Confirm data sovereignty and compliance obligations where migration operations cross jurisdictional boundaries, especially if using remote storage or hybrid Azure services later.

A migration is not just a technical operation—it is a privileged activity with downstream governance implications. Treat it accordingly.

Performance Sizing: Set Realistic Expectations

Change Block Tracking helps by focusing on used blocks, but total migration time still hinges on:

  • Actual used disk capacity and the active write rate during initial sync.
  • Network capacity between source datastores, the WAC gateway, and destination storage.
  • Storage throughput and IOPS available on the destination (and for any thin‑to‑fixed conversion).
  • Concurrency—10 VMs in parallel increases aggregate load.

Run capacity tests in a staging environment. Treat any “minutes” time claims as best‑case and calibrate schedules to measured throughput from your pilot runs.

How This Fits Microsoft’s Broader Migration Story

The VM Conversion extension is a pragmatic companion to Microsoft’s cloud migration portfolio. It targets on‑premises modernization—replatforming on Hyper‑V while keeping options open for Azure integration later. Support for Azure Arc‑enabled scenarios is hinted at for future updates, underscoring Microsoft’s hybrid posture for customers bound by regulatory or latency constraints.

This capability complements cloud‑oriented paths such as Azure Migrate and Azure VMware Solution. Organizations should choose the path that aligns with strategic goals: lift‑and‑shift to Azure, gradual replatforming, or hybrid models. A first‑party, GUI‑driven conversion tool lowers the technical barrier for VMware‑to‑Hyper‑V moves but does not eliminate contractual, licensing, or ecosystem considerations from Broadcom’s recent VMware changes.

A controlled pilot accelerates confidence and uncovers edge cases. Start with these steps:

  1. Identify 3–5 low‑risk VMs that represent your variety (Windows, Linux, multi‑disk, networked).
  2. Deploy WAC v2 in a lab or on a dedicated gateway and install the VM Conversion extension.
  3. Validate all prerequisites (VDDK, PowerCLI, Hyper‑V role, runtimes).
  4. Execute full migrations and document timelines, failure modes, manual fixes, and post‑migration steps.
  5. Review results with application owners and update the runbook and rollback procedures before any production migrations begin.

Piloting lets you quantify network throughput requirements, understand driver/boot recovery scenarios (common with Linux), and build muscle memory for the extension’s quirks.

Practical Verdict for Windows Administrators

The Windows Admin Center VM Conversion extension is a meaningful addition to Microsoft’s on‑premises management toolkit. It delivers an integrated, agentless, CBT‑backed path to migrate VMware workloads to Hyper‑V and reduces reliance on third‑party converters and bespoke scripts. For organizations pursuing on‑premises consolidation or hybrid strategies that favor Microsoft’s stack, it materially lowers the technical bar and shortens operational workflows.

Yet the feature remains a public preview, not a silver bullet. Operational risks—precheck mismatches, storage and network bottlenecks, and licensing considerations—must be managed through disciplined testing, runbook development, and least‑privilege security practices. Administrators should treat the extension as an enabling tool that simplifies technical steps but does not replace thorough migration planning.

For IT teams willing to adopt preview software in a controlled manner, the VM Conversion extension is a welcome innovation that will likely accelerate on‑prem modernization and reduce migration friction. The sensible path forward is measured adoption: pilot, document, and scale only after organizational safeguards, capacity planning, and contingency procedures are fully validated.

The arrival of this capability inside Windows Admin Center signals a practical shift: migration from VMware to Hyper‑V is now a first‑class scenario in Microsoft’s management plane for on‑prem customers. The preview gives administrators the tools to modernize infrastructure with less overhead, but success will depend on realistic expectations, careful testing, and clear runbooks.