Microsoft has shipped a public preview of a native VM Conversion extension for Windows Admin Center, taking aim at one of the most stubborn challenges in datacenter operations: moving virtual machines from VMware vSphere to Hyper-V with minimal hassle. The extension, quietly introduced into the Windows Admin Center gallery, promises agentless, change-block-tracking (CBT)-backed replication, automatic boot-type mapping, and the ability to synchronize up to 10 VMs in a single batch—all from a familiar GUI console.

For administrators weighed down by legacy conversion utilities like the retired Microsoft Virtual Machine Converter (MVMC) or the heft of System Center Virtual Machine Manager (VMM), the new extension offers a lighter, integrated alternative. It arrives at a time when many organizations are reevaluating their virtualization strategies, driven by licensing shifts and a desire to consolidate on-premises stacks. The tool is free to install, requires only a Windows Admin Center gateway, and speaks directly to vCenter environments running versions 6.x, 7.x, and 8.x.

What the VM Conversion Extension Delivers

The core value proposition is simplicity. After installing the extension in Windows Admin Center (WAC), administrators connect to a target Hyper-V host and a source vCenter. The extension auto-discovers VMs, runs a series of prechecks, and then orchestrates a two-phase migration: an initial full synchronization while the source VM stays online, followed by a final delta sync during a scheduled cutover window.

Key technical highlights include:
- Agentless operation: No agent needs to be installed inside the guest VM. The extension relies on VMware’s Virtual Disk Development Kit (VDDK) and PowerCLI on the WAC gateway to read source disks and orchestrate replication.
- CBT-backed replication: Change Block Tracking identifies only the blocks that have changed since the last sync, dramatically reducing the data transferred during the final migration and cutting downtime.
- Automatic boot-type mapping: BIOS-based VMs become Hyper-V Generation 1, while UEFI VMs are created as Generation 2, preserving boot configuration and simplifying post-migration remediation.
- Batch migration: Groups of up to 10 VMs can be synchronized together, with cluster‑aware logic that distributes them appropriately on failover clusters. This is critical for multi-tier applications or rack-aligned workloads.
- Static IP preservation: The tool retains static IP configurations, reducing network reconfiguration steps after cutover.
- Multi-disk support and prechecks: All attached virtual disks are migrated, and a precheck phase catches common failure points—active snapshots, insufficient storage, incompatible disk types—before replication starts.
- VMware Tools cleanup: In the preview, the extension can remove VMware Tools from Windows VMs post-migration, lowering the risk of driver conflicts.

According to Microsoft’s documentation, the extension supports migrating Windows Server 2025/2022/2019/2016/2012 R2, Windows 10/11, and a range of Linux guests: Ubuntu 20.04/24.04, Debian 11/12, AlmaLinux, CentOS, and Red Hat Linux 9.0. Linux VMs, however, require Hyper-V integration drivers to be present before migration to avoid boot failures.

How the Migration Works Under the Hood

The workflow is divided into synchronization and migration phases. During synchronization, the extension connects to vCenter, creates a temporary snapshot on the source VM to enable CBT, and performs an initial full copy of all virtual disks to VHDX files on the Hyper-V host. The source VM continues to run, so business operations aren’t disrupted. Administrators can choose the target storage path and schedule the cutover at a convenient time.

When it’s time to finalize the migration, the administrator powers down the source VM—either manually or by consenting within the tool—and triggers the migration phase. The extension then performs a final delta sync using CBT to grab any blocks that changed since the initial copy. Once that sync completes, it imports the VM into Hyper-V with the correct CPU, memory, and network settings. The imported VM remains in an offline state, ready for post-migration checks and first boot.

Microsoft recommends deploying the Windows Admin Center gateway in the same site as the ESXi and Hyper-V hosts to minimize WAN traffic and latency. The extension creates thin-provisioned (dynamically expanding) VHDX files by default; administrators who prefer fixed-size disks can convert them afterward using PowerShell.

Installation and Prerequisites

Bringing the VM Conversion extension into production demands careful preparation. The Windows Admin Center gateway must run the generally available V2 release. On that gateway, administrators need:
- VMware PowerCLI installed via Install-Module VMware.PowerCLI.
- VMware VDDK 8.0.3 (or the version specified in the docs) extracted to C:\Program Files\WindowsAdminCenter\Service\VDDK.
- The Microsoft Visual C++ Redistributable packages.
- Network connectivity from the gateway to vCenter and Hyper-V hosts, with appropriate administrative credentials.

Source VMs must be free of active snapshots; the precheck will fail if any exist. This is a known limitation that can disrupt environments heavily reliant on snapshots during maintenance windows. After installation from the WAC Extensions feed, the extension appears as a new tool in the left navigation when connected to a Hyper-V host.

The Migration Workflow Step by Step

  1. Connect to vCenter: Provide FQDN and credentials; the extension enumerates all VMs.
  2. Select VMs and storage location: Choose up to 10 VMs and designate the Hyper-V path for the initial replica files.
  3. Run prechecks: Address any issues—snapshots, disk type mismatches, insufficient space.
  4. Start synchronization: The full initial copy begins; progress is shown via WAC notifications.
  5. Final delta sync and import: When ready, power off the source VM and trigger the migration. The extension captures residual changes, creates a Hyper-V VM, and registers it.
  6. Post-migration tasks: Remove VMware Tools (if the automated cleanup didn’t run), install Hyper-V integration services on Linux, verify networking, and optionally convert VHDX to fixed size.

Limitations and Caveats in the Preview

The extension is in public preview, and Microsoft makes it clear that it may change substantially before general availability. Several limitations are worth noting:

  • Snapshot dependency: Active snapshots must be removed before synchronization. In environments where snapshots are routine, this can complicate scheduling.
  • Resync unsupported: The preview lacks a resync option; if an initial sync is interrupted or fails, administrators must restart the process manually. This reduces fault tolerance for large migrations.
  • Dynamic VHDX default: Thin-provisioned disks are created, which may not satisfy performance-sensitive applications accustomed to thick provisioned storage. Post-migration conversion adds steps.
  • Linux driver readiness: Linux guests often fail to boot after migration if Hyper-V integration services are absent. Planning must include pre-staging drivers or having rescue ISOs ready.
  • Performance variability: While Microsoft’s demos suggest migrations complete “in a few minutes,” actual cutover windows depend heavily on VM size, change rate, network throughput, and storage speed. Large, I/O-intensive VMs will take considerably longer.
  • Preview stability: As with any prerelease software, organizations should test thoroughly in isolation before trusting it with production workloads.

Enterprise Implications and Strategic Context

The arrival of a first-party, GUI-driven VMware-to-Hyper-V migration tool inside Windows Admin Center fills a gap that has existed for years. MVMC, the previous free tool, was retired, leaving VMM’s conversion wizard or third-party utilities as the primary paths. The new extension modernizes the experience and aligns with the broader Windows Admin Center strategy: providing a unified, browser-based management plane for Windows Server and hybrid infrastructure.

For organizations evaluating a move off VMware—whether driven by Broadcom licensing changes, consolidation goals, or a desire to align with Azure hybrid services—the extension reduces technical friction. It doesn’t replace contractual or licensing analysis, and it doesn’t auto-magically resolve the operational complexities of a platform shift, but it does remove the need for custom scripts or expensive third-party converters.

Datacenter architects should also consider the tool’s role in disaster recovery planning. Because the synchronization phase creates an up-to-date replica on Hyper-V without disrupting the source, it can serve as a low-cost DR mechanism for VMware workloads, even if full migration isn’t imminent.

Comparison with Older Tools and Cloud Paths

  • MVMC (Retired): A legacy standalone converter that lacked CBT support and had limited guest OS compatibility. The WAC extension is its spiritual successor but with modern replication and UI.
  • System Center VMM: Offers deep integration for larger fabric management, but its conversion capabilities are part of a heavier infrastructure. WAC’s extension is ideal for shops that don’t already run VMM or want a simpler tool.
  • Azure Migrate / Azure VMware Solution: These remain the recommended paths for cloud migrations. The WAC extension is explicitly designed for on-premises Hyper-V targets, not cloudization. Organizations with hybrid goals can still use Azure Migrate for assessment, but the extension handles the actual V2V move.

Best Practices for a Successful Migration

Based on community feedback and Microsoft’s guidance, administrators should:
- Pilot with non-critical VMs: Test the complete sequence—sync, cutover, boot, and app validation—in a lab or with low-stakes workloads.
- Document a runbook: Include prechecks, backup verification, final sync triggers, and post-migration steps (driver installs, tools removal, network validation).
- Time the cutover carefully: Use maintenance windows, and ensure that the final delta sync won’t exceed the window due to high change rates.
- Prepare Linux guests in advance: Install Hyper-V drivers or ensure the latest integration services are baked into the image.
- Monitor logs: The extension writes detailed logs (VMConversion_log.txt) that should be fed into existing monitoring systems.
- Plan for rollback: Keep source VMs (or backups) until the migrated VM is confirmed stable.

What’s Next for the Extension

Microsoft has not announced a general availability date, but the features listed—Secure Boot configuration based on OS type, localization support, multiple vCenter connections—suggest a product nearing maturity. The roadmap likely includes support for resync, broader Linux compatibility, and possibly integration with Azure Arc for post-migration governance. Community feedback will shape priorities.

For Windows administrators and platform owners, this extension represents a pragmatic tool that lowers the technical barrier to VMware-to-Hyper-V migration. It’s not a magic bullet, but with proper planning and realistic expectations, it can streamline a historically painful process. As the preview matures and more organizations kick the tires, the collective experience will validate whether it fulfills its promise of simplifying datacenter modernization.