Microsoft has dropped a new first-party weapon into the virtualization battleground—a fully agentless VMware-to-Hyper-V conversion extension for Windows Admin Center. The public preview, released quietly, lets administrators replicate and import virtual machines directly from vCenter or ESXi hosts into Hyper-V on Windows Server, sidestepping the third-party converters and hand-crafted scripts that have long defined cross-platform migration. The move lands at a moment when many IT organizations are reevaluating VMware relationships in the wake of Broadcom’s licensing overhaul, and it gives Windows Server shops a clear, GUI-driven escape hatch that runs inside a management tool they already know.

Why a built-in VMware converter, and why now

Virtual machine migration has always been a sore spot in enterprise data centers. Third-party tools often demand per-VM agents, manual disk conversions, or dedicated appliances that inflate operational overhead. Scripting approaches work but demand deep expertise and carry the risk of fragile, one-off implementations. Microsoft’s new VM Conversion extension embeds the entire workflow directly into Windows Admin Center (WAC), with no agents to deploy and no separate infrastructure to spin up.

Timing is critical. Since Broadcom’s acquisition of VMware, licensing structure changes, per-core pricing shifts, and support policy adjustments have pushed many customers to reassess their hypervisor commitments. A zero-cost, first-party conversion tool inside WAC offers a low-friction route to Hyper-V—or, for those eyeing hybrid options, a convenient first step toward Azure. Community discussion around the release frames it as both a technical enabler and a strategic lever: IT teams that have been considering a move now have a supported, Microsoft-maintained path that eliminates the need to evaluate yet another third-party vendor.

What the VM Conversion extension actually does

The extension provides a two-phase, agentless replication and import workflow:

  • Agentless discovery and replication – WAC connects directly to vCenter, discovers VMs automatically, and reads disk data via VMware APIs without installing guest-side agents.
  • Change Block Tracking (CBT)-backed synchronization – An initial bulk copy occurs while the source VM stays online. After administrators approve a controlled shutdown, a final delta pass using CBT captures only the changes since the last sync, minimizing downtime.
  • Batch support – Up to 10 VMs can be synchronized in one operation.
  • Automatic boot mapping – BIOS/legacy VMs land as Hyper-V Generation 1, while UEFI guests become Generation 2, preserving boot semantics where possible.
  • Destination disk format – Disks are written as dynamically expanding VHDX (thin) by default, though post-migration conversion to fixed VHDX is fully supported.

Microsoft’s documentation explicitly targets organizations that must keep workloads on-premises for compliance, latency, or governance reasons, as well as shops that simply want a supported, GUI-driven alternative to VMware without deploying external converters.

Prerequisites: what you need before you start

The extension is lightweight but insists on a specific set of components on the Windows Admin Center gateway and the source/destination infrastructure:

  • Windows Admin Center gateway v2 (GA) installed and reachable.
  • Hyper-V role enabled on destination host(s).
  • VMware PowerCLI module present on the WAC gateway (Install-Module VMware.PowerCLI).
  • VMware Virtual Disk Development Kit (VDDK) version 8.0.3 downloaded and extracted into the WAC service folder (commonly C:\Program Files\WindowsAdminCenter\Service\VDDK).
  • Microsoft Visual C++ Redistributables (including older runtimes like 2013) installed on the gateway.
  • Source vCenter/ESXi versions 6.x and above (as stated for the preview).
  • No active snapshots on the source VM at initial synchronization—prechecks will fail if snapshots exist.

Critically, the conversion runs entirely from the WAC gateway, leveraging the VDDK for raw disk reads and PowerCLI to interact with vCenter. That means the gateway must be properly sized and hardened; a gateway compromise could expose sensitive migration artifacts or credentials.

Step-by-step migration walkthrough

Administrators can expect a clear, wizard-driven flow inside Windows Admin Center:

  1. Install the VM Conversion extension via Extensions > Available Extensions in WAC.
  2. Connect WAC to the target Hyper-V host(s).
  3. Add vCenter endpoints—FQDN and credentials—and let WAC auto-discover VMs.
  4. Select up to 10 VMs, then choose a destination storage path for the initial replica.
  5. Execute prechecks (boot configuration, CBT availability, disk format, free space, snapshots). Fix any flagged issues.
  6. Start Synchronize: the initial replication runs while the source VM remains operational. Progress and logs are displayed in WAC.
  7. When ready, perform Migrate: power down the source VM (admin consent mandatory), run the final delta sync via CBT, and import the VHDX into Hyper-V.
  8. Post-migration: manually remove VMware Tools if present (the preview does not automate this), install Hyper-V integration components on Linux guests, validate networking and DNS, and optionally convert VHDX to fixed type for performance-sensitive workloads.

The two-phase model—bulk copy followed by delta sync—enables the tool to claim “minimal downtime,” but the actual offline window hinges on the volume of changes made by the workload during the final pass. A high-transaction database server will inevitably take longer than a static web server.

Supported guest operating systems and gotchas

Microsoft documents support for a broad set of Windows Server versions (including 2025 and 2022 series) and Windows 10 for compatible workloads. The Linux list includes Ubuntu 20.04 and 24.04, AlmaLinux, CentOS, RHEL 9.0, and Debian 11/12. However, a critical caveat appears: Linux guests must have Hyper-V integration drivers installed before migration to ensure a clean first boot.

Multi-disk VMs and those with multiple vNICs are supported, but post-migration network validation and driver checks become essential. In real-world tests shared within the community, Linux guests consistently generate the most post-migration friction—driver mismatches, missing hypervisor services, or incorrect initramfs configurations can lead to unbootable systems. Treat Linux migrations as tasks that demand extra validation time.

Strengths: what makes this tool worth a look

  • First-party and integrated – Embedding conversion inside WAC reduces reliance on third-party utilities and consolidates governance under a single Microsoft management plane.
  • Agentless replication – No guest agents means less per-VM setup and no lingering agent cleanup after migration.
  • CBT-based synchronization – By copying the bulk of data while VMs remain online, the tool keeps downtime low for business-critical applications.
  • Low barrier for SMEs – Minimal infrastructure requirements and a familiar GUI make the extension accessible to small and mid-sized organizations that may lack dedicated migration specialists.

Limitations and reality checks

As a public preview, the extension comes with sharp edges that administrators must account for:

  • Preview status – Behavior may change, features might be removed, and bugs will appear. Do not bet production workloads on a preview without thorough testing.
  • No snapshots allowed at initial sync – VMware shops that rely on snapshot-based backups or short-term rollback workflows will need to alter policies or clean up before migration.
  • Thin-provisioned VHDX by default – Some teams require fixed VHDX for performance or management compliance; an extra conversion step must be planned.
  • Manual VMware Tools removal – The preview won’t uninstall VMware Tools automatically. Leaving them in a Hyper-V guest can cause driver conflicts and instability.
  • No resync support – If a migration fails after the initial sync, restarting the entire process may be necessary; plan manual fallback procedures.

Additionally, marketing statements that “migrations take only a few minutes” should be interpreted as best-case scenarios for tiny, low-I/O VMs. Expect migration time to scale linearly with used disk capacity, network bandwidth, and IOPS constraints. A 500 GB database VM over a 1 Gbps link will not finish in minutes.

Security, compliance, and operational governance

Migration is an auditable, privileged operation. Microsoft’s design places the WAC gateway in the role of orchestrator, reading raw disk data and handling credentials for both vCenter and Hyper-V. Hence:

  • Apply least-privilege principles to all accounts used by WAC and the VM Conversion extension. Rotate credentials after every migration window.
  • Harden the gateway itself—monitor it with existing SIEM infrastructure, maintain audit trails, and treat any compromise as a potential exposure of entire VM images.
  • Validate data sovereignty and regulatory obligations. Even though the extension targets on-premises moves, any use of network shares or hybrid connectivity must align with data residency and auditing requirements.

Migrations should be run in concert with compliance, legal, and procurement teams. The technical act of conversion is only one piece; the record of that conversion is what auditors will scrutinize.

A pilot plan and pre-migration checklist

A disciplined pilot avert surprises. Start with a lab-based runbook:

  1. Select three to five representative VMs: Windows, Linux, small/medium, multi-disk.
  2. Deploy WAC v2 on a lab gateway, install the VM Conversion extension, and confirm PowerCLI, VDDK 8.0.3, and the appropriate Visual C++ runtimes.
  3. Run the full migration workflow on a non-production VM. Record time for initial sync, final delta, and total offline window. Validate boot, drivers, network, DNS, and application functionality.
  4. Test rollback procedures—restore from backups and reattach original vSphere disks if needed.
  5. Measure resource impact on the gateway, network, and destination storage. Scale the gateway if pilot tests show CPU or I/O bottlenecks.
  6. Only after single-VM success, expand to clustered/HA scenarios.

For each VM, complete this checklist before initiating migration:

  • Confirm no active snapshots exist.
  • Verify CBT is enabled in vSphere VM settings.
  • Ensure adequate temporary storage on the target for the replica VHDX.
  • Preinstall Hyper-V integration drivers on Linux guests.
  • Take a final verified backup before cutover.
  • Notify application owners of the expected downtime window and the rollback plan.

Strategic implications: more than a migration tool

The VM Conversion extension lowers the technical barrier to leaving VMware, but platform decisions are rarely purely technical. Licensing inertia, staff training, tooling investments, and third-party integrations often anchor organizations. Even a free conversion tool carries hidden costs: temporary storage, network bandwidth, staff hours, application revalidation, and potential Hyper-V administration training.

Microsoft openly positions the extension as a building block for hybrid strategies, offering a staged pathway toward Azure for teams that later adopt cloud services. For shops specifically reacting to Broadcom’s commercial policies, the tool provides a practical exit ramp—but one that must be weighed against total cost of ownership and long-term platform strategy. Community discussions acknowledge that while the tool is welcome, it doesn’t erase contractual relationships or the need for a broader strategic review.

Practical verdict for Windows administrators

Microsoft’s VM Conversion extension is the most polished first-party vSphere-to-Hyper-V migration tool the company has shipped in years. By weaving agentless discovery, CBT replication, and batch operations directly into Windows Admin Center, it modernizes a longstanding pain point and consolidates the workflow into a supported management console.

For organizations committed to on-premises operations, constrained by regulation, or actively seeking a VMware exit, the extension materially reduces migration friction. That said, it remains a public preview—not a production-grade silver bullet. Operational realities around prechecks, driver compatibility, storage capacity, networking, and licensing still apply. Administrators should:

  • Validate the tool thoroughly in a lab and with realistic pilot migrations.
  • Treat optimistic downtime claims with skepticism and measure actual throughput for their workloads.
  • Engage legal and procurement early to understand the full implications of a platform shift beyond the technical conversion.

In an era where hypervisor loyalty is being tested by commercial upheaval, Microsoft has delivered a pragmatic tool that gives customers more choice—provided they approach it with eyes wide open.