Organizations eyeing a move from VMware to Hyper-V no longer need to pay for third-party converters or cobble together manual workarounds. Microsoft has released a first-party VM Conversion extension for Windows Admin Center, now in public preview, that promises an agentless, appliance-free path from vCenter to on-premises Windows Server with Hyper-V. The tool discovers virtual machines, runs prechecks, replicates disks using change block tracking, and handles final cutover with minimal downtime—all from within the familiar Windows Admin Center console.

Administrators who have grappled with heterogeneous hypervisor migrations will recognize the significance: for the first time, Microsoft delivers a native, zero-license-cost migration utility integrated directly into its management platform. The extension fills a gap that previously forced IT teams toward cloud-centric migration services, manual VHDX conversions, or commercial offerings like StarWind V2V Converter. But as with any preview-grade tool, the reality of deploying it in production demands careful planning and measured expectations.

What’s New: The VM Conversion Extension

The VM Conversion extension appears in the public feed of Windows Admin Center v2 (GA) and requires no separate appliance. Its core mission is straightforward: move virtual machines from VMware vCenter/ESXi to a Hyper-V host while keeping the source VM online until the final cutover delta sync. Microsoft’s design emphasizes operational simplicity: after connecting to vCenter, the extension auto-discovers VMs, lets administrators select up to ten at a time, and walks them through a series of validation checks before replication begins.

Replication is built around VMware’s Change Block Tracking (CBT) technology. An initial full copy of the VM’s disks streams across the network to dynamically expanding VHDX files on the destination storage. When the team is ready to switch, the tool performs a second delta replication—the VM is powered off, the last changes are synced, and the machine is imported into Hyper-V with the correct generation (BIOS→Gen1, UEFI→Gen2). The promise is downtime measured in minutes rather than hours, though actual durations depend heavily on data size and network throughput.

Windows and Linux guests are both supported, and VMs with multiple virtual disks are handled transparently. For Linux, the only strict requirement is that Hyper-V integration drivers must be pre-installed to ensure a successful boot after migration—something that matches standard guidance for any Hyper-V Linux workload.

How It Works: Agentless, Two-Phase Replication

The migration flow follows a logical, hands-on sequence:

  1. Discovery and selection: The admin points the extension at one or more vCenter endpoints, supplying FQDN and credentials. The tool automatically enumerates VMs.
  2. Prechecks: Before any bits move, the extension validates boot configuration, disk types, CBT availability, destination storage capacity, memory requirements, and the absence of active snapshots. Any failures must be resolved manually.
  3. Initial sync: While the source VM stays online, the extension uses the VMware Virtual Disk Development Kit (VDDK) and CBT to create a full replica on the Hyper-V host. Destination virtual disks are written as dynamically expanding VHDX files by default.
  4. Cutover: When ready, the administrator initiates the final migration. The tool runs a delta replication, powers down the source VM, performs one last sync, and imports the VM into Hyper-V, applying the correct generation and boot settings automatically.

Critically, the process is browser-session-dependent: closing the Windows Admin Center interface can pause or abort the operation. This design keeps things simple but demands patience and a stable network connection during the final sync.

Prerequisites and Setup

Getting the extension running is not a one-click affair. The Windows Admin Center gateway must meet these explicit requirements, drawn from the preview documentation:

  • Windows Admin Center Gateway V2 (GA) installed and running.
  • Hyper-V role enabled on target hosts.
  • VMware PowerCLI installed on the gateway (Install-Module -Name VMware.PowerCLI).
  • Microsoft Visual C++ redistributables, including the 2013 runtime, present on the gateway.
  • VMware VDDK (the preview requires version 8.0.3) downloaded and extracted into the gateway’s service folder (typically C:\Program Files\WindowsAdminCenter\Service\VDDK).
  • Source vCenter version 6.x or 7.x.
  • Source VMs must have change block tracking enabled and no active snapshots during initial sync.

Missing any one of these will cause precheck failures or block synchronization entirely. For environments accustomed to snap-and-forget backup strategies, the snapshot prohibition alone can add days to a migration project while consolidation and cleanup are performed.

What It Does Well: Strengths for IT Admins

The extension’s immediate appeal lies in its integration. Instead of hopping between multiple tools, administrators can manage discovery, validation, replication, and import from a single pane of glass—Windows Admin Center itself. This reduces the cognitive load of a migration and keeps audit trails centralized.

Agentless operation eliminates the need to install temporary migration agents inside every guest, lowering both security surface and deployment overhead. The two-phase CBT-driven approach genuinely minimizes cutover downtime; production VMs can continue serving users until the very moment of switchover, with only the final delta requiring an outage.

Batch awareness (up to ten VMs per synchronization batch) and Hyper-V cluster awareness mean that multi-tier applications can be moved together and placed directly into failover clusters. Mixed OS support (Windows + Linux) and multi-disk handling cover most enterprise scenarios without custom scripting.

Perhaps most attractive is the cost: the extension is free to use with Windows Admin Center, eliminating the licensing expense of third-party migration tools. For small and medium businesses or cost-conscious enterprise teams, that can be the difference between moving forward and staying put.

Where It Falls Short: Limitations and Risks

Experienced administrators will immediately spot a few rough edges that demand caution.

Preview Status: Microsoft explicitly labels this as a public preview. Buggy behavior, incomplete features, and breaking changes before general availability are all real possibilities. No mission-critical VM should be migrated without thorough lab testing first.

Performance is Not Magic: Claims that a full migration takes “just a few minutes” reflect ideal conditions—small, lightly used virtual disks over high-speed, low-latency networks. In practice, a 1 TB database VM over a 1 GbE link could take hours, and multiple concurrent migrations will compete for bandwidth and storage I/O. Always measure your environment’s effective throughput using the formula: replication time ≈ (used data size) ÷ (sustained transfer rate).

Thin Provisioning by Default: The extension creates dynamically expanding VHDX files, which saves initial space but may not match the performance profile of fixed-size disks. Converting to fixed VHDX post-migration demands additional time and storage I/O, a task often overlooked until after cutover.

Snapshot Strictness: Active snapshots on the source VM are a hard blocker for initial sync. Teams that routinely snapshot for backups or testing must first consolidate and remove snapshots—a process that can be time-intensive and risky on busy VMs.

VMware Tools Cleanup Uncertainty: Preview documentation has been inconsistent on whether VMware Tools are automatically removed after migration. Early indications suggest they are not; later references hint at some cleanup. Administrators should verify this in a lab and plan for a manual post-migration step to remove VMware Tools and install Hyper-V integration services.

Identity and Licensing Artifacts: The migration may change the VM’s BIOS GUID, potentially breaking software that binds licenses to hardware IDs. Microsoft provides scripts to adjust the GUID afterward, but this adds another step. Licensing implications—both for the source hypervisor and for guest OSes—should be reviewed before proceeding.

On-Prem Only, No Azure Integration Yet: The preview lives solely in on-premises Windows Admin Center; the Azure portal’s Windows Admin Center does not host the extension. Future support for Azure Arc servers is mentioned as a roadmap item but is not available today.

Hidden Operational Costs: While the extension itself is free, the associated labor—precheck remediation, snapshot cleanup, application testing, post-migration conversion, network scheduling—can mount quickly. Storage for temporary replicas and bandwidth consumption should be budgeted, and temporary licensing overlaps may occur.

A Practical Migration Playbook

To navigate these pitfalls, a structured plan is essential. Here is a condensed checklist based on the extension’s documented capabilities:

Pre-Project

  • Inventory candidate VMs, noting disk sizes, I/O profiles, snapshots, and network dependencies.
  • Review VMware support contracts and Hyper-V licensing requirements.
  • Select representative test VMs for a pilot (small, medium, and large).

Gateway and Environment Setup

  • Deploy/upgrade Windows Admin Center v2 GA. Install PowerCLI and the VDDK.
  • Confirm Hyper-V role, available storage, and network paths between vCenter datastores and the gateway.

Per-VM Preparation

  • Remove or consolidate all snapshots; verify CBT is enabled.
  • Install Hyper-V integration services on Linux guests prior to migration.
  • Document static IP configurations; for Windows, Windows Admin Center can preserve them, but for Linux, manual reconfiguration may be needed.

Migration Execution (per batch ≤ 10 VMs)

  1. Connect to vCenter and select VMs. Run synchronization and address all precheck failures.
  2. Allow initial replica to complete fully and verify VHDX creation.
  3. Initiate cutover migration—keep the browser session active until finished.
  4. Power on the migrated VM in Hyper-V, validate boot, networking, and application health.
  5. Remove VMware Tools if still present; install or update Hyper-V guest services.
  6. Convert VHDX to fixed type if required, adjust BIOS GUID as needed, and apply any post-migration scripts.
  7. Run functional acceptance tests before removing the source VM.

Rollback Plan

  • Retain the source VM and replication artifacts until post-migration signoff is complete. Test fallback procedures in the pilot phase.

Strategic Implications and Future Hybrid Integration

The VM Conversion extension is part of a broader Microsoft push to make on-premises Hyper-V and Azure Stack HCI more attractive to VMware customers. By removing a technical hurdle—the lack of a first-party migration tool—Microsoft lowers the barrier to entry for organizations that want to remain on-premises but reduce VMware dependency.

Hybrid management is clearly on the roadmap. Windows Admin Center already integrates with Azure Arc for server management, and while the VM Conversion tool does not yet support Azure Arc servers, Microsoft has indicated that such support will come. When it does, administrators may be able to orchestrate migrations from a cloud pane, bridging on-prem and cloud management planes.

For now, the extension is a solid on-premises tactical tool. It fits neatly into strategies that prioritize local control, compliance, or cost reduction, while leaving the door open for future cloud extension. But it is not a wholesale replacement for Azure Migrate, which remains the recommended path for large-scale cloud migrations and assessments.

Conclusion: A Worthwhile Preview, With Caveats

The Windows Admin Center VM Conversion extension is the most direct on-premises migration path Microsoft has ever offered from VMware to Hyper-V. Its agentless design, tight integration, and zero-cost model make it instantly compelling for Windows-centric shops. For test/dev workloads or smaller production VMs, it can drastically simplify what was once a multi-tool chore.

Yet the preview label must be taken seriously. Inconsistent documentation, performance variability, and the need for manual post-migration tasks mean that this is not yet a turnkey enterprise solution. IT teams should pilot the extension now, feed back to Microsoft, and prepare for a future where agentless VMware-to-Hyper-V moves are a routine part of the Windows Admin Center experience. Until then, careful planning and lab validation remain the difference between a smooth migration and a weekend spent in the data center.