Microsoft VM Conversion: Migrate VMware to Hyper-V with Windows Admin Center

Microsoft’s new VM Conversion extension for Windows Admin Center arrives as a pragmatic, first‑party option to move workloads from VMware vCenter/ESXi to on‑premises Hyper‑V, promising an agentless, appliance‑free migration workflow that minimizes downtime and keeps administrative control inside the Windows Admin Center management plane.

Background​

For years, organizations that wanted to leave VMware for Hyper‑V faced a mix of third‑party converters, manual reconfiguration, or cloud‑centric migration paths. Microsoft’s VM Conversion extension, released into public preview in Windows Admin Center v2, is explicitly built to address that gap: it discovers VMs from one or more vCenter endpoints, performs prechecks, replicates virtual disks using change‑block tracking (CBT), and completes a final delta sync after a controlled shutdown of the source VM. The feature set is positioned for on‑premises migrations rather than cloud lift‑and‑shift, giving enterprises and SMEs a native tool to reduce technical friction when moving workloads back into the Microsoft stack.
This feature article breaks down what the VM Conversion extension does, what it requires, where it shines, and where IT teams should be cautious. It verifies technical specs and operational claims against official documentation and independent reporting, highlights strengths and limitations, and provides a practical migration checklist for administrators preparing to evaluate the preview.

---

Overview of the VM Conversion extension​

What it is and what it does​

• The VM Conversion extension is an add‑on for Windows Admin Center (WAC) v2 that enables migration of virtual machines from VMware vCenter / ESXi to Windows Server with Hyper‑V.
• It is described as agentless and appliance‑free: no guest‑side agent installation is required to perform the replication, and there is no separate appliance to deploy.
• The migration flow is a two‑phase replication:
• An initial replication (while the source VM remains online).
• A final delta replication after the source VM is powered down for cutover.
• Replication uses change‑block tracking (CBT) to minimize the amount of data copied during delta sync.
• Administrators can discover VMs automatically after connecting to vCenter, select up to 10 VMs for synchronization in a batch, and then migrate them to Hyper‑V.
• Boot type mapping is automatic: BIOS → Hyper‑V Generation 1, UEFI → Hyper‑V Generation 2.
• The tool supports Windows and Linux guest OSes (Linux guests require Hyper‑V integration drivers preinstalled for a successful post‑migration boot).
• Disks can be migrated even when multiple virtual disks are attached, and the default destination format is dynamically expanding VHDX (thin provisioning).

These behaviors are consistent with the published Windows Admin Center migration documentation and independent coverage of the preview.

Key prerequisites and environment requirements​

To install and run the extension, the Windows Admin Center gateway must meet a short list of prerequisites:

• Windows Admin Center Gateway V2 (WAC v2 – GA) must be installed and running.
• Hyper‑V role installed on the target host(s).
• PowerCLI installed on the Windows Admin Center gateway (Install‑Module -Name VMware.PowerCLI).
• Microsoft Visual C++ redistributables and the older Visual C++ 2013 runtime present on the gateway host.
• The VMware VDDK (Virtual Disk Development Kit) version required by the extension must be downloaded and extracted into the gateway’s service folder (the preview specified VDDK 8.0.3).
• Source vCenter should be version 6.x or 7.x (the extension supports these versions).
• The source VM must not have active snapshots during initial synchronization — snapshots cause precheck failures.
• CBT support on the source VM is required for efficient delta replication.

These prerequisites are explicit and non‑optional; missing items will block synchronization prechecks.

---

How the migration flow works — step by step​

Discovery and synchronization​

• Connect WAC to the target Hyper‑V host and add one or more vCenter endpoints (FQDN + credentials).
• Windows Admin Center auto‑discovers VMs in the connected vCenter; you can select up to 10 VMs per synchronization batch.
• Before replication begins, the extension runs a series of prechecks (boot configuration, disk types, CBT availability, available disk and memory on the destination host, no active snapshots, etc.). Any failed precheck requires manual remediation.
• The extension creates an initial replica of the VM using the VMware VDDK and CBT mechanisms, writing destination VHDX files to the specified storage location while the source VM remains running.
• When ready for cutover, the administrator initiates migration: the tool performs a delta replication pass, the source VM is powered off, a final delta sync is executed, and the VM is imported into Hyper‑V and configured with the proper generation/boot settings.

What stays automated and what must be handled manually​

• The extension automates discovery, replication, disk conversion to VHDX (thin by default), generation selection, and import into Hyper‑V.
• Precheck failures, driver or integration‑service installs for Linux guests, networking and firewall adjustments, and any necessary cleanup (for example, removal of VMware Tools) may require manual administrator intervention.
• The session requires an active browser session to complete migration; closing the browser or timing out can pause or stop progress.

---

Strengths: why this matters to Windows administrators​

• Integrated, first‑party tool: Migration inside Windows Admin Center removes a third‑party dependency and centralizes the workflow within Microsoft’s management plane.
• Agentless operation reduces operational risk and simplifies initial replication because IT teams do not have to install and manage agents on each guest.
• CBT‑driven replication and the two‑phase approach minimize downtime during cutover — the VM only needs to be powered down for the final delta sync.
• Batch‑aware and cluster‑aware migration enables grouping of related VMs and migration into cluster or failover setups, which is useful for application stacks that require coordinated moves.
• Support for mixed workloads (Windows + Linux) and multiple disks per VM helps cover the most common enterprise scenarios.
• Low infrastructure overhead: There’s no separate appliance; the extension is lightweight and installed inside Windows Admin Center, making it accessible for SMEs as well as larger organizations.

These characteristics make the extension a practical tool for organizations that are committed to on‑premises infrastructure or hybrid strategies that are not yet ready for cloud migration.

---

Limitations, risks, and important caveats​

Preview status — treat as experimental for production​

The VM Conversion extension is released as a public preview. Production environments should treat it as an early preview: expect bugs, incomplete features, and behavioral changes before general availability. Migration in mission‑critical systems should not rely solely on preview tools without thorough testing.

Performance claims are workload dependent​

Statements that whole‑VM migration can take “just a few minutes” are contextual and optimistic. Migration time depends heavily on:

• Source VM’s used disk capacity (not the provisioned size) and I/O rate.
• Available network bandwidth between vCenter datastore and the Windows Admin Center gateway/destination storage.
• Storage throughput and latency on both source and destination.
• Number and size of VMs migrated concurrently.

The “few minutes” scenario is realistic for small, low‑I/O VMs over a fast network, but not for multi‑terabyte databases or disk‑heavy workloads. Treat advertised timeframes as best‑case examples and plan tests with representative workloads.

Thin‑provision default and post‑migration storage work​

The extension writes dynamically expanding VHDX files on the destination by default — i.e., thin provisioning based on used blocks. That saves immediate destination space, but many administrators prefer fixed‑size (preallocated) VHDX for performance predictability. Post‑migration, converting to fixed VHDX is an extra step and consumes time and storage I/O:

• Convert-VHD -Path "C:\VMs\MyDisk.vhdx" -DestinationPath "C:\VMs\MyDisk_Fixed.vhdx" -VHDType Fixed

Plan storage capacity to accommodate this conversion if required.

Snapshots, snapshots, snapshots​

The tool fails initial sync if the source VM has active snapshots. Many VMware environments use snapshots for backups or test workflows; for those shops the migration planning must include snapshot removal, consolidation, and validation, which may extend project timelines.

VMware Tools removal — documentation inconsistency​

Documentation and preview notes have different lines about whether VMware Tools are automatically uninstalled after migration. Some early guidance indicated tools are not removed automatically; later or other documentation references a cleanup step. This inconsistency means administrators must verify behavior in lab tests and include a manual post‑migration task to remove VMware Tools and replace them with Hyper‑V integration components as needed.

BIOS GUID and identity implications​

The migration may result in a different BIOS GUID on the destination VM unless adjusted manually. That can affect licensing or software that relies on hardware/firmware identifiers. Microsoft provides scripts to update the BIOS GUID post‑migration, but this is an extra step and should be part of the migration checklist.

No Azure portal (WAC in Azure) availability for the tool — on‑prem only​

As of the public preview, the VM Conversion extension is available in Windows Admin Center on‑premises only; WAC in the Azure portal does not host the extension. Plans for Azure Arc‑led integration were mentioned in reporting, but this specific capability isn’t present in the preview and appears to be a roadmap item rather than shipped functionality.

Hidden operational costs and licensing considerations​

While the extension itself is available in the WAC feed at no additional software charge, migration projects incur hidden operational costs:

• Temporary storage capacity for replication data and VHDX files.
• Network bandwidth and possible scheduling of transfers to avoid interfering with production.
• Labor for prechecks, remediation, application testing, and post‑migration conversions.
• Possible licensing implications (support contracts, hypervisor licensing revisions) and vendor lock‑in considerations.

Budget accordingly rather than assuming a “free” migration.

---

Practical migration checklist and recommended process​

The following checklist converts the extension’s capabilities into an actionable, repeatable migration playbook.

Pre‑project: environment and governance​

• Inventory and classification
• Identify candidate VMs and classify by business criticality, I/O profile, disk used size, network dependencies, and snapshots.
• Licensing and contract review
• Evaluate VMware contracts, support windows, and Hyper‑V licensing needs.
• Test and pilot plan
• Choose representative test VMs (small, medium, and large) to validate performance and behavior in a lab.

Gateway and prerequisites (implementation tasks)​

• Ensure Windows Admin Center v2 GA gateway is installed and patched.
• Install PowerCLI on the gateway: Install‑Module -Name VMware.PowerCLI.
• Download and extract the VDDK to the path required by WAC (e.g., C:\Program Files\WindowsAdminCenter\Service\VDDK).
• Confirm Visual C++ redistributables are installed.
• Confirm Hyper‑V role and sufficient destination storage and vCPU resources.

Pre‑migration validation (per‑VM)​

• Remove or consolidate snapshots; verify no active snapshots on source VMs.
• Ensure CBT is enabled and supported for each VM.
• Install Hyper‑V integration drivers on Linux guests prior to migration (Linux Integration Services).
• Capture static IPs and network configuration. For Windows VMs, WAC can persist static IP settings; for Linux, manual steps may be necessary.

Migration execution (per batch, up to 10 VMs)​

• Connect to vCenter from the VM Conversion extension and select VMs to synchronize (up to 10).
• Run synchronization and monitor prechecks; fix any issues reported before proceeding.
• Allow initial replica to complete to 100% and validate VHDX creation on destination storage.
• Initiate migration (final delta sync + cutover). Keep the browser session active until migration finishes.
• After migration, validate boot, networking, drivers, and application functionality.
• Remove VMware Tools if not automatically removed; install Hyper‑V guest services.
• If required, convert VHDX to fixed size and correct BIOS GUID or other identity artifacts.
• Run functional tests and scheduled acceptance testing before removing the source VM or altering production routing.

Rollback and recovery planning​

• Maintain the source VM and replication artifacts until post‑migration validation is complete and acceptance is signed.
• Test fallback procedures in the pilot and confirm timelines for rollback (remember that re‑failover may require time-intensive data sync).

---

Operational examples and a simple sizing heuristic​

Estimating replication duration is essential for scheduling and user expectations. A simple heuristic:

• Replication time (initial sync) ≈ (Used data size to copy) / (Effective throughput)

Where effective throughput is the sustained transfer rate between your source datastores and destination storage (measured in MB/s). For example:

• A VM with 50 GB used disk data:
• Over sustained 100 MB/s transfer: ~500 seconds (~8.5 minutes) plus overhead.
• A VM with 1 TB used data:
• Over 200 MB/s transfer: ~5120 seconds (~1.4 hours) plus overhead.
• Large, highly active VMs will also incur additional delta sync time and I/O contention.

These are simplified examples — real environments must measure actual throughput, storage latency, and contention for an accurate schedule.

---

Roadmap and hybrid management implications​

Microsoft has signaled that hybrid management and Azure Arc are strategic priorities for Windows Admin Center. Windows Admin Center is already integrated with Azure Arc for server management, and Windows Admin Center extensions can be deployed to Arc‑enabled servers in supported regions.
That said, the VM Conversion extension preview is currently targeted at on‑premises migrations inside Windows Admin Center running on local infrastructure. Any statements about adding Azure Arc server support for VM Conversion should be treated as future roadmap items unless explicitly published in Microsoft’s official release notes for the extension. Administrators who need cloud or Arc‑enabled migration paths today should plan to use Azure Migrate and Azure Arc tooling where appropriate, while keeping an eye on Windows Admin Center release notes for changes.

---

Strategic considerations for organizations​

• Short‑term: For operations teams that need an on‑premises, integrated migration path without buying additional third‑party converters, the VM Conversion extension offers a compelling, lower‑friction option to move test/dev and low‑to‑medium‑sized production VMs.
• Medium‑term: The extension reduces the technical barriers to leaving VMware, but migration is only one part of a larger organizational decision that includes staffing, tooling, support contracts, and application compatibility.
• Long‑term: Hybrid strategies that mix on‑premises Hyper‑V, Azure Stack HCI, and Azure itself will benefit from Microsoft’s broader investments in Windows Admin Center and Azure Arc, but teams should validate the operational model and governance implications before committing to a large‑scale migration.

---

Final verdict and recommendations​

The VM Conversion extension is a welcome addition to Windows Admin Center and fills a long‑standing operational gap — a lightweight, no‑cost migration path from vCenter to Hyper‑V that reduces dependency on third‑party tools. It is especially attractive for organizations prioritizing on‑premises control, compliance, or hybrid flexibility.
However, this is a public preview and not a finished enterprise migration product. The most important takeaways for IT teams are:

• Validate everything in a lab with production‑representative VMs before touching production workloads.
• Plan for prechecks, snapshots consolidation, and post‑migration tasks (drivers, VMware Tools removal, VHDX conversions).
• Do not treat optimistic migration time claims as universal; measure network and storage throughput first.
• Expect additional steps for identity‑sensitive workloads (BIOS GUID, licensing).
• Budget for hidden operational costs and keep source VMs available until acceptance testing concludes.

If the migration project is properly scoped and tested, Windows Admin Center’s VM Conversion extension can significantly simplify VMware→Hyper‑V moves — but only when used as part of a deliberate, well‑measured migration plan rather than as a last‑minute, one‑shot conversion tool.

---

The VM Conversion extension represents the most direct, first‑party attempt by Microsoft to lower the technical barrier for migrating away from VMware while preserving on‑premises control. For Windows administrators, it’s a tool worth piloting now; for production rollouts, cautious planning and incremental validation remain essential.

---

Source: Techzine Global Microsoft launches VM Conversion tool

Microsoft has opened public preview of a long‑requested, first‑party VM Conversion extension inside Windows Admin Center, giving administrators a built‑in, agentless way to convert and migrate virtual machines from VMware vCenter/ESXi to Hyper‑V with minimal downtime and streamlined tooling. The feature is included in Windows Admin Center v2 (GA) under Extensions and is positioned for on‑premises modernization projects and hybrid readiness rather than cloud lift‑and‑shift scenarios. years, moving VMs off VMware and onto Hyper‑V required third‑party utilities, custom scripts, or complex appliance deployments. Microsoft’s new VM Conversion extension attempts to close that gap by embedding conversion capabilities directly into the Windows Admin Center (WAC) management plane. The extension is released as a public preview, so it should be considered experimental for production workloads until it reaches general availability.
Enterprises and smazations that keep workloads on‑premises for compliance, latency, or governance reasons now have a zero‑cost, GUI‑driven path to standardize on Microsoft’s virtualization stack while retaining potential pathways to Azure in future updates. Microsoft has emphasized quick setup and a lightweight footprint, but the operational and contractual realities of migration still require careful planning.

---

Overview of what the VM Conversi extension delivers a full conversion workflow inside WAC with the following headline capabilities and behaviors:​

• Agentless replication: No guest‑side agent is required for the bulk of the migration flow, reducing operational overhead.
• Change Block Tracking (CBT) based sync: Initial replicaM remains live; only a brief shutdown is required for final cutover, minimizing downtime.
• Batch migrations: Administrators can select up to 10 VMs per synchronizarate in one batch.
• Cross‑guest support: Both mainstream Windows and several Linux distributions are supporteat Linux guests should have Hyper‑V integration drivers available for a reliable first boot.
• Multi‑disk and boot mapping: The tool supports multiple virtual disks and performs automatic boot‑type mapping (BIn 1, UEFI → Generation 2). Disks are written as dynamically expanding VHDX by default.
• No additional appliance: The conversion logic runs on the Windows Admin Center gateway, leveraging VMware VDDK and PowerCLI; no separate coneeded.

These capabilities are designed to make on‑premises moves faster and less error‑prone by centralizing discovery, prechecks, replication, conversion, and import into a s​

Technical requirements and prerequisites​

The preview imposes a targeted set of prerequisites that administrators must satisfy before they can start converting VMs. These are explici the current build:

• Windows Admin Center Gateway V2 (GA) installed and reachable.
• Hyper‑V role present on the destination host(s).
• PowerCLI installed on the WAC gateway (Install‑Module -Name VMware.PowerCLI) for vCenter interaction.
• VMware VDDK unpacked into the WAC g(preview called out VDDK 8.0.3).
• **Microsoft Visual C and older runtime components present on the gateway where required.
• vCenter/ESXi source versions suppd 7.x as noted in the preview guidance.
• No active snapshots on source VMs during initial sots will cause precheck failures.

Administrators should also ensure sufficient temporary storage on the destinati planning for initial replication, and proper credential handling for vCenter and Hyper‑V hosts. Logs pon (for example, VMConversion_log.txt) should be integrated into SIEM and audit pipelines for regulated environmentigration flow works — step by step
The conversion workflow follows a clear, two‑phase replication model designed to minimize downtime while preserving data integrity:

• Install the VM Conversion extension inside Windows Admin Center (Extensions > Available Extensions > Install).
• Add and connect to the target Hyper‑V host(s) and one ors (FQDN + credentials). WAC auto‑discovers VMs in connected vCenter instances.
• Select up to 10 VMs for synchronization and choose a storage path for the initial replica. Run the extension’s automated prechecks (snapshots, CBT availability, storage capacity, boot config, disk format). Fix any repStart Synchronize: the gateway uses VMware’s CBT with the VDDK to copy used blocks into dynamically expanding VHDX on the destination while the source VM remai the initial synchronization is complete and readiness checks pass, schedule or perform the final cutover: the source VM is powered down, a delta replication (final CBT pass) runs to capture last changes, and WAC then imports and confi‑V.
• Post‑migration steps: uninstall VMware Tools if necessary, confirm Hyper‑V integration services (or install Hyper‑V drivers for Linux), verify network and DNS settings, anVHDX to fixed size for performance.

This two‑phase approach is the heart of the extension’s low‑downtime promise: by copying most data while the VM is running and only pausing the VM for the final delta, the visible service interruption is kept to a minimum. Administratorthe offline window varies with workload characteristics.

---

Strengths — where the extension shines​

• First‑party integration: Having conversion inside Windows Admin Center reduces the need for third‑party tools and centralws in Microsoft’s supported management plane. This simplifies governance and reduces the number of moving parts.
• Agentless, appliance‑free architecture: No guest agents and no separate conversion appliance lowers deployment complexity and ongoing maintenance.
• CBT and batch sync: The use of change bo 10 VMs per batch enables practical, low‑downtime migrations for many common scenarios.
• Mixed workload support: Native support for Windows and popular Linux distributions makes the tool usable across heterogeneous datacenter environments.
• Automated boot mapping and disk handling: Automated BIulti‑disk support reduce manual steps during import.

These strengths make the extension particularly attractive for SMEs and departmental IT teams that ruructure and want a lower‑friction route to standardize on Hyper‑V while retaining hybrid options for Azure integration later.

---

Important limitations as​

While promising, the preview release has meaningful limitations and operational considerations that require attention:

• Preview status: As a public pre not feature complete and may change. Do not assume parity with mature conversion or vendor tools until GA is announced and community exp*Precheck strictness**: Failures on prechecks (active snapshots, incompatible disk types, insufficient storage) will block synchronization; these checks are strict by design and must be remediated before proceeding.
• Thin provisioning default disks as dynamically expanding VHDX by default. Administrators preferring fixed VHDX will need a post‑migration conversion step that consumes time and I/O. Plan storage capacity accordingly.
• No automatic VMware Tools removal (preview): The preview does not automatically uninstall VMware Tools post‑migration; leaving legacy tools in place can cause driver conflicts. Uninstall ‑V integration services as part of post‑migration cleanup.
• Performance variability: Claims of “migration in a few minutes” are context dependent. Large disks, heavy I/O, and limited network or storage throughput wc and cutover times significantly. Treat time estimates as best‑case scenarios.
• Resync and recovery features: Some recovery workflows such as Resync are not supported in the current preview, limiting certain re‑synchronization or error recal contingency procedures.

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 (recommended)​

A dinbook reduces surprises. The following checklist is a condensed operational sequence that reflects the extension’s behavior and documented requirements:

• Inventory: Identify VMs to migrate and capture configuration (disk count, boot type, OS, installed tools). WAC v2 and the VM Conversion extension in a lab; perform a full test migration on a non‑critical VM.
• Validate prerequisites: Confirm PowerCLI, required VDDK in the gateway service folder, Visual C++ runtimes, Hrk reachability.
• Address snapshots: Remove or consolidate snapshots on source VMs; re‑run prechecks until green.
• Schedule sync windows: Plan initial sync during low‑I/inal cutover during maintenance windows.
• Monitor logs: Capture VMConversion_log.txt and integrate with monitoring; watch for precheck and replication warnings.
• Post‑migration validation: Uninstall VMware Tools, confirm Hyper‑V Integration Services, verify network, DNS, and IP configuration, run application‑level smoke tests.
• Rollback plashot or backup outside the migration operation to allow rollback if the final cutover fails. Note that the tool’s preview limanual recovery.

Following this sequence maintains separation of concerns between technical conversion steps and organizational approvals (procurement, lhat often determine the overall migration schedule.

---

Security, compliance and credential mana extension requires privileged credentials for vCenter and Hyper‑V targets and writes sensitive logs to the WAC gateway. Ts high‑risk areas:​

• Enforce least‑privilege for accounts used by the extension and rotate credentials after the migrati the Windows Admin Center gateway and its service account are hardened and monitored; gateway compromise could expose migration artifacts and credentials.
• Integrate the SIEM and maintain an auditable trail for compliance reviews; log retention policies should match organizational requirements.
• Confirm data sovereignty and compliance obligations where migration opctional boundaries, particularly if using remote storage or hybrid Azure services as follow‑on steps.

These security practices are essential because a migration is not only a technical operation but also a privdownstream governance implications.

---

Performance sizing and realistic expectations​

Change Block Tracking reduces repeated copying by focusing on used blocks, but total migration time will still hinge on:

• Actual used disk capacity and active write rate during initial sync.
• Network capacity between source datastores, WAC gateway, andbandwidth and latency).
• Storage throughput and IOPS available on the destination (and temporary space for thin→fixed conversions if applicable).
• Concurrent 10 VMs in parallel increases aggregate load).

Estimate expected transfer volumes and run capacity tests in a staging environment. Treat marketing‑style time claims a calibrate schedules to measured throughput in pilot runs.

---

How this fits with Microsoft’s broader migration story​

The VM Conversion extension is a pragmatic companion to Microsoft’s cloud t targets on‑premises modernization — enabling teams to replatform on Hyper‑V while keeping options open for Azure integration in the future. Support for Azure Arc‑enalled for future updates, underscoring Microsoft’s hybrid posture for customers that must keep workloads on‑premises for regulatory or latency reasons.
This new capability also complements cloud‑oriented paths such as Azure Migrate and Azure VMware s should choose the migration path that aligns with strategic goals: lift‑and‑shift to Azure, gradual replatforem, or hybrid models that mix both approaches. The presence of a first‑party, GUI‑driven conversion path lowers the technical solidation decisions but does not eliminate contractual, licensing, or ecosystem con# Recommended pilot plan for early adopters
A practical pilot accelerates confidence and uncovers edge cases before broad rollouts. Recommended pilot steps:

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

Piloting in a controlled environment allows teams to quantify neirements and build playbooks for driver/boot recovery scenarios that commonly surface with Linux and specialized Windows workloads.

---

Final assessment — practical verdict for Windows administrators​

The Windows Admin Center VM Conversion extension is a meaningful addition to Microsoft’s on‑premises management toolkit. It brings an integrated, agentless, CBT‑backed path to migrate VMware workloads to Hyper‑V and reduces reliance on third‑party converters and bespoke scripts. For organizpremises consolidation or hybrid strategies that favor Microsoft’s stack, it materially lowers the technical bar for conversion and shortens operational workflows.
At the same time, the feature is a public preview and not a silver bullet. Operational risks — prec mismatches, storage and network bottlenecks, and licensing or contractual considerations anaged through disciplined testing, runbook development, and least‑privile Administrators should treat the extension as an enabling tool that simplifies technical steps but does not migration planning.
For IT teams willing to adopt preview software in a controlled manner, the VM Conversion extension is a welc that will likely accelerate on‑prem modernization and reduce migration friction. The sensible path forward is measured adoption: pilot, document, and then scale once organizational safeguards, capacity planning, and con fully validated.

---

The arrival of this capability inside Windows Admin Center signals a practical shift: migration 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 disciplined testing, clear runbooks, and realistic performance expectations.

---

Source: Windows Report Microsoft Launches Preview of VM Conversion Tool in Windows Admin Center

Microsoft has quietly released a first‑party, agentless VM Conversion extension for Windows Admin Center that converts VMware vCenter/ESXi virtual machines into Hyper‑V VMs on Windows Server — a move that promises a low‑friction on‑premises path away from VMware while surfacing important operational, licensing, and security tradeoffs administrators must plan for now. (techspot.com)

Background: why this matters now​

Virtual machine conversion and migration has long been one of the more painful tasks in enterprise IT. Legacy utilities, third‑party converters, and custom scripts have filled the gap for years, but they often required per‑VM agents, manual disk conversions, or separate appliances that increased operational overhead. Microsoft’s new VM Conversion extension embeds a conversion workflow directly into Windows Admin Center (WAC), offering a GUI‑driven, agentless process that aims to reduce those frictions for on‑premises modernization efforts. (learn.microsoft.com)
At the same time, the market context is important. Many organizations are reconsidering VMware after recent changes to VMware’s licensing and commercial policies; vendors and customers alike have cited contract complexity and price pressure as reasons to evaluate alternatives. Microsoft’s timing — providing a no‑cost conversion path inside WAC — naturally positions Hyper‑V (and Azure hybrid options) as simpler alternatives for customers rethinking their virtualization strategy. Tech press and community discussion have framed the release as both pragmatic and strategically motivated. (techspot.com) (techcommunity.microsoft.com)

---

Overview: what the VM Conversion extension does​

The VM Conversion extension is a public preview feature that runs inside Windows Admin Center and provides a two‑phase, agentless replication and import workflow from vCenter/ESXi to Hyper‑V on Windows Server.
Key technical attributes:

• Agentless discovery and replication — WAC connects to vCenter, auto‑discovers VMs, and uses VMware APIs to extract disk data without installing guest‑side agents. (learn.microsoft.com)
• Change Block Tracking (CBT)‑backed synchronization — an initial bulk copy happens while the source VM remains running, followed by a final delta pass after a controlled shutdown to minimize downtime. (learn.microsoft.com)
• Batch migration support — up to 10 VMs can be synchronized in a single batch operation. (learn.microsoft.com)
• Automatic boot mapping — BIOS/legacy guests are created as Hyper‑V Generation 1; UEFI guests become Generation 2, preserving boot semantics where possible. (learn.microsoft.com)
• Destination format — migrated disks are written as dynamically expanding VHDX (thin) by default; admins can convert to fixed VHDX after migration. (learn.microsoft.com)

Microsoft’s official documentation and preview blog make the intended audience explicit: organizations that must keep workloads on‑premises for compliance, latency, or governance reasons and those that want a supported, GUI‑driven route to Hyper‑V without deploying third‑party converters. (learn.microsoft.com) (techcommunity.microsoft.com)

---

Required prerequisites and environment checklist​

The VM Conversion extension is lightweight, but it expects certain components on the Windows Admin Center gateway and on the source/destination infrastructure. Verify these exactly before testing:

• Windows Admin Center Gateway v2 (GA) installed and reachable. (learn.microsoft.com)
• Hyper‑V role installed on destination host(s). (learn.microsoft.com)
• PowerCLI module present on the WAC gateway: Install‑Module VMware.PowerCLI. (learn.microsoft.com)
• VMware VDDK (Virtual Disk Development Kit) version required by the preview — VDDK 8.0.3 — downloaded and extracted into the WAC service folder (typically C:\Program Files\WindowsAdminCenter\Service\VDDK). (learn.microsoft.com)
• Microsoft Visual C++ Redistributables (including older runtimes like 2013) installed on the gateway. (learn.microsoft.com)
• Source vCenter/ESXi at supported versions (vCenter/ESXi 6.x and higher for the preview). (learn.microsoft.com)
• Ensure no active snapshots exist on the source VM at initial synchronization — active snapshots cause precheck failures. (learn.microsoft.com)

These dependencies mean the conversion flow runs from the WAC gateway, leveraging the VDDK for raw disk reads and PowerCLI to interact with vCenter; there is no separate conversion appliance to deploy, but the gateway itself must be hardened and properly sized for the workload.

---

How the migration flow works — step by step​

Administrators can expect a clear, GUI‑driven workflow inside Windows Admin Center. The high‑level steps are:

• Install the VM Conversion extension inside Windows Admin Center (Extensions > Available Extensions > Install). (learn.microsoft.com)
• Connect WAC to the target Hyper‑V host(s). (learn.microsoft.com)
• Add vCenter endpoints (FQDN and credentials); WAC auto‑discovers VMs. (learn.microsoft.com)
• Select up to 10 VMs and choose a storage path on the destination for the initial replica. (learn.microsoft.com)
• Run prechecks (boot configuration, CBT availability, disk format, free space, snapshots). Fix any flagged issues. (learn.microsoft.com)
• Start Synchronize — initial replication runs while the VM stays operational. Progress and logs appear in WAC. (learn.microsoft.com)
• When ready, perform Migrate: power down the source VM (admin consent), run final delta sync (CBT), and import the VHDX into Hyper‑V. (learn.microsoft.com)
• Post‑migration: remove VMware Tools if present, install Hyper‑V integration components on Linux guests, validate networking and DNS, and optionally convert VHDX to fixed type for performance. (learn.microsoft.com)

This two‑phase model — bulk copy then final delta — is the core reason the tool can claim minimal downtime while transferring whole VM images from vSphere to Hyper‑V. However, the actual offline window depends entirely on workload behaviour and the volume of delta changes during the final pass.

---

Supported guest OSes and special cases​

Microsoft documents explicit support for a range of Windows Server and major Linux distributions, but with caveats:

• Supported Windows versions include modern Windows Server releases (2025, 2022 series) and Windows 10 for compatible workloads. (learn.microsoft.com)
• Linux distributions listed in the preview include Ubuntu (20.04, 24.04), AlmaLinux, CentOS, RHEL 9.0, Debian 11/12 — however, Linux guests must have Hyper‑V integration drivers available/installed before migration to ensure a clean first boot. (learn.microsoft.com)
• Multi‑disk VMs and those with multiple vNICs are supported, but post‑migration network validation and driver checks are essential.

Linux guests are the common source of post‑migration issues in real‑world tests because of driver mismatches or missing hypervisor integration services; administrators should treat Linux migrations as requiring particular attention in validation stages.

---

Strengths: why administrators should care​

• First‑party, integrated tool — having conversion inside WAC reduces third‑party dependencies and centralizes the migration workflow in a supported Microsoft management plane. This simplifies governance and operational procedures. (learn.microsoft.com)
• Agentless replication — no guest agents to install reduces per‑VM operational overhead and simplifies initial copying. (learn.microsoft.com)
• CBT and two‑phase migration — minimizes downtime for business‑critical VMs by copying most data while the VM remains online. (learn.microsoft.com)
• Low barrier for SMEs — Microsoft positions the extension as requiring minimal infrastructure and quick setup, making it attractive to small and mid‑sized organizations looking for a supported on‑prem alternative to VMware. (techcommunity.microsoft.com)

---

Limitations and critical caveats​

The extension is useful, but several important caveats should temper expectations:

• Preview status — the extension is a public preview; production deployments should be cautious. Preview builds may change behavior, remove features, or introduce bugs. Treat the tool as experimental until GA and validated in your environment. (learn.microsoft.com)
• No snapshots during initial sync — many VMware shops rely on snapshot‑based workflows for backups or short‑term rollback; initial sync will fail if active snapshots exist, requiring policy changes or pre‑migration cleanup. (learn.microsoft.com)
• Disks migrated thin by default — VHDX files are dynamically expanding by default; some teams require fixed VHDX for performance or management reasons, necessitating post‑migration conversion steps. (learn.microsoft.com)
• No automatic uninstallation of VMware Tools in preview — leaving VMware Tools in a Hyper‑V guest can create conflicts; removal must be manual in the current preview. (learn.microsoft.com)
• Resync not supported in preview — some recovery or re‑synchronization workflows are limited; administrators should design manual fallback processes. (learn.microsoft.com)

Finally, marketing claims like “migrations take only a few minutes” are context‑dependent and can be misleading. Large, high‑I/O VMs will not migrate in minutes; expect migration time to scale with used disk capacity, network bandwidth, and IOPS constraints. Flag such optimistic timeframes as best‑case scenarios.

---

Security, compliance, and operational governance​

Migration is a privileged operation that requires careful governance:

• Enforce least‑privilege for accounts used by WAC and the VM Conversion extension; rotate credentials after migration windows.
• Harden and monitor the Windows Admin Center gateway — it orchestrates disk reads and stores migration artifacts; gateway compromise could expose sensitive images or credentials. Maintain SIEM integration and audit trails for compliance.
• Verify data sovereignty and regulatory obligations — while the extension is aimed at on‑premises moves, any hybrid workflows or use of network shares must be validated against data residency and auditing requirements.

These are operational imperatives: migration is not just a technical task, it’s an auditable change to infrastructure that must be lined up with compliance, legal, and procurement teams before execution.

---

Recommended pilot plan and migration runbook​

A disciplined pilot and staged runbook reduce surprises. Use the following plan as a starting template:

• Select 3–5 representative VMs (Windows, Linux, small/medium size, multi‑disk). Document baseline performance and dependencies.
• Deploy Windows Admin Center v2 in a lab gateway and install the VM Conversion extension. Confirm PowerCLI, VDDK 8.0.3, and Visual C++ runtimes are present. (learn.microsoft.com)
• Run the full migration workflow on a non‑production VM, recording time for initial sync, final delta, and total offline window. Validate boot, drivers, network, DNS, and application behavior.
• Practice rollback and data recovery procedures — test restoring from backups and reattaching original vSphere disks if needed.
• Measure resource impact on gateway, network, and destination storage. Scale gateway resources if initial pilot shows CPU/IO bottlenecks.
• Expand pilot to clustered/HA scenarios only after single‑VM conversion is validated. (learn.microsoft.com)

Numbered pre‑migration checklist for each VM:

• Validate there are no snapshots.
• Confirm CBT is enabled on the VM (vSphere settings).
• Ensure adequate temporary storage on target for replica VHDX.
• Preinstall Hyper‑V integration drivers for Linux guests.
• Take a final backup and verify restoration before cutover.
• Notify application owners of expected downtime window and rollback plan.

---

Strategic implications: vendor lock‑in, costs, and options​

The availability of an integrated conversion tool lowers the technical barrier to leaving VMware, but migration decisions are rarely purely technical. Licensing, tooling investments, staff skills, and third‑party integrations often anchor organizations to a platform. Even with a zero‑cost conversion tool, there can be hidden costs: temporary storage, network bandwidth, staff hours, application revalidation, and potential training for Hyper‑V administration.
Microsoft is explicit that the VM Conversion extension also supports hybrid pathways and can be a staged step toward Azure for teams that later choose to adopt cloud services. For shops specifically looking to avoid Broadcom/VMware commercial changes, a supported, first‑party conversion route provides a practical exit option — but one that should be weighed against total cost of ownership and long‑term platform strategy. (techspot.com) (techcommunity.microsoft.com)

---

Practical verdict and next steps for Windows administrators​

The VM Conversion extension is a welcome, pragmatic tool: it brings an agentless, CBT‑backed path for moving VMware workloads into Hyper‑V directly inside Windows Admin Center. For organizations committed to on‑premises operations, regulatory constraints, or seeking a supported exit from VMware, it materially reduces operational friction and consolidates the workflow into Microsoft’s management plane. (learn.microsoft.com)
That said, the extension is a public preview and not a silver bullet. The operational realities — prechecks, driver compatibility, networking, storage capacity, and licensing consequences — remain. Administrators should:

• Validate the tool in a lab and run comprehensive pilot migrations.
• Treat optimistic migration time claims carefully and measure actual throughput for your workload.
• Engage legal/procurement to understand licensing and support transitions beyond pure technical conversion.

---

Final thoughts​

Microsoft’s VM Conversion extension represents the most polished, first‑party approach to vSphere→Hyper‑V migration the company has offered in years. It modernizes a long‑standing pain point, combining agentless discovery, CBT replication, and a batch workflow into the Windows Admin Center experience. For teams that need to keep workloads on‑premises or want a supported alternative to VMware, it is a practical new tool — provided it is deployed with careful testing, realistic expectations, and full operational governance.
The release also underscores a broader market shift: platform vendors are increasingly making migration easier to shape customer choice. Technical capability alone does not resolve contractual relationships or long‑term platform strategy, but it does lower the operational hurdle for organizations that decide the business case for change is compelling. (techspot.com)

---

---

Source: TechSpot Windows Server users have a new tool to convert VMware virtual machines to Hyper-V instances