KingWerx Hypervisor Migrator

This guide walks you through a complete migration from connecting to your VMware source to booting the finished VM on Hyper-V and documents the behavior and caveats for every kind of guest the tool handles. Read Pre-flight assessment and the guest-specific notes before your first production move.

OverviewWhat the tool does

The KingWerx Hypervisor Migrator converts running or exported VMware virtual machines into working Hyper-V VMs. For each machine it connects to your vCenter or ESXi host, grades how cleanly the guest will boot on Hyper-V, copies and converts the disks to VHDX, repairs guest bootability (the Windows STOP 0x7B fix and its Linux equivalent), then builds and starts the VM on your Hyper-V host.

It is built for the post-Broadcom "leave VMware" move, and deliberately works where the free tools can't:

Standalone ESXi no vCenter required. Connect straight to a bare ESXi host with root.
Zero extra infrastructure no Windows Admin Center gateway, no VMware VDDK, no PowerCLI, no Install-Module, no internet. Everything it needs is bundled in one self-contained, portable download.
Boot-readiness first it tells you which VMs will boot clean, which it will auto-repair, and which need your attention before you commit to a migration.

SetupBefore you begin

Requirements

Where it runs

On the Hyper-V host itself, signed in as a local Administrator or a domain administrator. The app self-elevates via UAC if you launch it un-elevated.

Host role

The Hyper-V role installed and running, with at least one virtual switch configured.

Source access

Network reachability to your vCenter or ESXi host on port 443, and credentials that can read inventory and export VMs.

Disk space

A local drive with room for the source disk plus the converted VHDX. Point the working folder at a large drive if C: is tight.

.NET

None to install the app targets the .NET Framework that ships in-box on Windows Server 2016/2019/2022/2025.

Before you migrate anything: your backup

This tool builds, starts, and can delete virtual machines on production systems. You are responsible for maintaining a current, tested FULL SYSTEM BACKUP of every machine this software changes — the source hosts, the target hosts, and the virtual machines themselves. A VMDK copy, a VM snapshot, a converted VHDX, or any file this tool writes is not a backup. Validate every migrated VM before you decommission its source.

What's in the box

The download is a portable folder no installer required. It carries everything the migration needs so it runs fully offline:

KwxMigrator.exe the application (code-signed by KW Tech Solutions LLC).
govc\ the VMware vSphere client used to read inventory and copy disks.
qemu\ the disk converter (VMDK VHDX).
LICENSE.txt, README.txt, and third-party license notices.

Install & first run

Copy the folder onto the Hyper-V host, extract it, and run KwxMigrator.exe as Administrator. On first launch you'll be asked to accept the license agreement; the tool won't proceed until you do.

License agreement dialog shown on first run — **First run.** The license agreement is shown once; acceptance is remembered per Windows user.

WorkflowHow a migration works

The app is a wizard. You move left to right along the top stepper, and you can click a completed step to go back to it.

1 Source

Connect to vCenter/ESXi, or point at exported disk files.

2 Assess

Review each VM's boot-readiness grade and pick the ones to migrate.

3 Target

Choose where the VMs land, the virtual switch, and how far the tool goes to make them boot.

4 Placement

Send each VM to a specific cluster node or a specific drive and see the RAM and disk headroom before you commit. Only appears when there is more than one place to land.

5 Migrate

Run the migration, watch the live log, and follow the post-migration checklist.

Four steps or five

The stepper adapts to what it finds. Placement appears only when there is a real choice to make a failover cluster with more than one node, or a standalone host with more than one drive. A single-target job stays a clean four-step wizard and the Target screen's button reads Start Migration instead of Next. That is why some figures in this guide show five steps and others show four.

Step 1Connect to your source

Choose one of two source modes with the toggle at the top of the screen.

Live vCenter / ESXi

Pull a live inventory straight from a vCenter Server or a standalone ESXi host.

vCenter or ESXi host

Hostname or IP of the vCenter Server, or a bare ESXi host.

Port

Defaults to 443.

Username

[email protected] for vCenter, or root for a standalone ESXi host.

Password

The account password. It's held only in memory for the session.

Click Assess Inventory to connect and grade the inventory. The status line shows Not connected until the connection succeeds.

Source screen after a successful connection, showing the discovered VM count — **Source — connected.** On success the status line turns green and reports how many VMs were discovered, and the button becomes **Review Assessment**.

ESXi licensing caveat

A host running a free ESXi license has a read-only management API. The tool can still read inventory and copy disks, but it cannot set the source quarantine afterward it will warn you and ask you to disconnect the old VM by hand. A free license also prevents vCenter from managing the host. If you plan to migrate a batch cleanly, put the host in evaluation mode first.

Offline VMDK / OVA files

Already have exports on disk? Switch to Offline VMDK / OVA files and point the tool at an .ova, .ovf, .vmx, or .vmdk or a folder containing several of them.

Source screen, offline file mode — **Source Offline.** Pick a single export file or a folder of them, then Assess Inventory.

Step 2Pre-flight assessment

Every discovered VM is graded for how cleanly it will boot on Hyper-V, so you know what you're getting into before anything is copied. The list is filtered to powered-on VMs.

Read this first

Read each VM's information panel at the bottom of the screen carefully before proceeding. It lists, one line per issue, exactly what will happen to the machines you've selected and which ones need you to act first.

The four grades

Boots cleanMigrate as-is. No action needed.

Needs prepThe tool auto-fixes bootability (e.g. the Windows 0x7B fix). No action needed.

User actionYou must fix the guest first see the guest notes. Most common on fresh Linux installs.

Manual reviewUnsupported or unusual verify yourself before relying on it.

The inventory grid

Each row is one VM. Tick the checkbox to include it in the migration. The columns:

Column	What it shows
VM name	The source VM's name (kept on the target).
Guest OS	The detected operating system.
Firmware	BIOS or UEFI decides Hyper-V Generation 1 vs 2.
Controller	Source disk controller (PVSCSI, LSI, NVMe, IDE). All are handled.
Disk	Disk topology / size.
Tools	VMware Tools state.
Boot readiness	The colored grade, with the reason on hover.

Assess screen with graded VM inventory — **Assess.** Graded inventory with the selection summary and per-issue information panel below.

When you've selected the VMs you want, click Configure Target. Use Re-assess to re-scan the source if things have changed.

Step 3Target settings

Decide where the VMs land, how their network maps, and how far the tool goes to make guests boot.

Set the working folder every run

The working folder is local scratch for the download and conversion, and it must be a real drive with enough free space the pre-flight hard-blocks on the VM's provisioned size ("drive X has 0.0 GB free"). This field does not persist across a fresh extract, so set it each session; otherwise it defaults to an empty/phantom drive and blocks. Point it at a large local drive.

Target settings screen with the network-mapping grid — **Target.** Host storage and network mapping on the left; working folder, generation, VHDX disk format, and guest-prep options on the right. Shown on a host with several switches, so the per-network mapping grid appears in place of the single-switch dropdown.

VHDX folder

Where the converted disk is stored on the Hyper-V host. Click Load from host to auto-fill it along with the switch list.

Virtual switch

The Hyper-V switch the migrated VM's network adapter connects to loaded live from the host. When the host has more than one switch, this field is replaced by a per-network mapping grid — see Network mapping below.

Working folder

Local scratch for the download + conversion (see the warning above). A live free-space readout appears under it.

VM generation

Auto (recommended): BIOS Gen 1, UEFI Gen 2. Or force Gen 1 / Gen 2.

VHDX disk format

Dynamic (recommended): the disk grows as data is written — space-efficient. Fixed: pre-allocates the full provisioned size up front for steadier guest I/O, but it needs that much free space on the target drive and is slower to create. The Compact dynamic VHDX after conversion option reclaims empty space (dynamic disks only).

CPU / RAM

Inherited from each source VM as-is.

Network mapping

The tool reads each source VM's adapters and the vSphere port group each one sits on. How they land on Hyper-V depends on how many virtual switches the target host has:

One switch on the host — the Target screen shows a single Virtual switch dropdown, and every migrated NIC connects to it.
Several switches on the host — that dropdown is replaced by a Network mapping grid: one row per distinct source port group across the VMs you selected, each with its own target-switch dropdown. The tool auto-matches a source network to a switch of the same name where it can; otherwise it defaults and you set it. Every NIC on a given source network connects to the switch you map it to.

The mapping is keyed by source network, not by VM. When you migrate a batch, whatever you map a port group to applies to every selected VM with a NIC on it — and a VM whose adapters sit on two different source networks has each adapter placed independently, by its own network's mapping. Make your VM selection final before you set the mappings; changing the selection rebuilds the grid with fresh auto-matched defaults.

Guest preparation options

Power on when finished (default on) uncheck to review each VM's settings before first boot.
Overwrite existing VM / disk (default off) off means a name clash on the host stops the migration instead of clobbering it. Turn on only to deliberately replace a previous attempt.
Quarantine source VM after success (default on) after a successful migration, disconnects the source's network adapter and disables its autostart so it can't clash with the new VM (duplicate IP / AD). Fully reversible and noted in the VM's Notes.

Windows guests get the STOP 0x7B boot fix automatically. Firewalls and routers (pfSense, OPNsense, and similar) get MAC-address spoofing enabled automatically; for a router the tool doesn't recognize, enable it by hand on the VM's adapter (Hyper-V Advanced Features). Per-VM notes appear in the activity log.

Clustered Hyper-V targets

If the target host belongs to a Windows failover cluster, the Target screen detects it automatically after Load from host and shows a Make highly available option (on the left, under the host and network settings). Check it and the tool places the VM's disk and config on a Cluster Shared Volume (CSV) — it auto-fills the VHDX folder to a CSV for you — then, after the VM is built, registers it as a highly-available cluster role automatically (no manual step). The mapped virtual switch must exist with the same name on every node or the VM can't fail over. On a standalone (non-clustered) host the option never appears and the migration behaves exactly as normal.

With Make highly available checked and more than one node in the cluster, Next opens Step 4 Placement, where you choose which node each VM lands on and check the RAM each node has left.

Target screen on a cluster node showing the Make highly available option — **Clustered target.** On a cluster node the tool detects the cluster (here `LabHVC`), defaults storage to a CSV, and offers **Make highly available** — checked, the migrated VM is registered as an HA cluster role after build.

When the settings look right, click Next or Start Migration if this job has only one place to land.

Step 4Placement

This step appears when there is more than one place a VM could land. It lets you send each VM somewhere specific instead of accepting the default, and it shows the resources each target has left before you commit so a batch that will not fit is visible here rather than discovered halfway through a migration.

On a failover cluster: place each VM on a node

Every VM is built on the shared storage and then moved to the node you choose a Live migration if it is running, otherwise a Quick one. Because the disk is already on the CSV, that move is an ownership change, not a copy.

Placement screen on a cluster: per-VM node picker with per-node RAM cards — **Placement (cluster).** Each VM gets a target node. The cards below show, per node, how much RAM it reported free and how much this batch assigns to it.

Spread across nodes

Distributes the batch automatically, largest VMs first.

Set all to…

Sends every selected VM to one node.

Let the cluster decide

Leaves a VM with no preferred owner. It is built and started on the node running the tool.

On a standalone host: place each VM on a volume

When the host has more than one fixed drive, each VM's VHDX can go to a specific volume. The cards show free space per drive, and a drive the batch would overfill is flagged in red before you start.

Placement screen on a standalone host: per-VM volume picker with capacity cards — **Placement (standalone).** Per-VM volume selection. Here drive `E:` is flagged the VMs assigned to it need more space than it has free.

Reading the RAM and storage figures

The banner and the cards report what the tool measured when you clicked Load from host, alongside what your current selection would put there:

Per-node RAM

RAM 37 of 39.4 GB free · assigned 20 GB what that node reported free, and the total start-up RAM of the VMs you have sent to it. The bar and the GB RAM left figure show what would remain.

Shared CSV

The cluster banner reports the CSV's free space and roughly what the batch will write to it. Disk is shared across the cluster, so it is reported once for the volume rather than per node.

Host RAM (standalone)

The banner reports the host's free RAM against the total for the selected VMs.

Per-volume space

Each drive card shows free space and what the VMs assigned to it will write.

What happens if it does not fit

RAM: a VM whose start-up memory exceeds what the target has free will still convert and build correctly it simply will not start. It is reported amber as Built (not started); free memory on that host and start it. The tool warns before the run and does not block it, because you may be planning to free memory or start the VMs later.

Storage: if the largest single VM will not fit on the target volume, the migration is stopped before it begins and says so. If the batch as a whole exceeds free space it warns instead, because sizes for dynamic disks are estimates. On a cluster this matters beyond the migration: a CSV that fills pauses every clustered VM on that volume.

These figures are a point-in-time reading, not a reservation. Other workloads can consume memory or disk between the reading and the run.

Step 5Migrate

The tool works through the selected VMs one at a time convert, build the VM, prep the guest with a full activity log and a per-VM summary. After each disk is converted it runs a quick integrity check on the VHDX before building; a disk that fails is stopped there and reported, so a corrupt convert is caught at conversion time rather than as a VM that won't boot.

Migration in progress with activity log — **Migrate.** Live progress per VM, the activity log, and the migration summary.

Start Migration

A fresh run resets the done flags and processes every selected VM from the top.

Retry Migration

Resumes skips VMs that already succeeded and re-runs only the ones that failed.

Cancel Migration

Stops the run; a copy in progress is aborted and its scratch cleaned up.

Export activity log

Saves the full log to a .txt file for your records.

Save report

Writes a self-contained .html migration report — a per-VM source-vs-target summary (specs, disks, network mapping, disk-integrity result, and timing) that doubles as a client hand-off document.

Batches

You can select and migrate many VMs at once. If one fails, fix the cause and use Retry the successful ones won't be touched.

"Built — did not start"

If a VM converts and builds but can't power on — most often because the host is low on free memory — it's flagged amber rather than green. The migration itself succeeded and the VM is ready; it just needs resources to run. Free some RAM on the host and start it (Hyper-V Manager, or Start-VM). Nothing is lost — data and settings are intact.

Rolling back a migration

When a VM finishes, a Roll back button appears on its row (a failed VM shows Clean up instead). Rolling back undoes the migration: it removes the target Hyper-V VM and deletes its virtual disks, then reconnects the source VMware VM's network and restores its original autostart — returning the source to exactly how it was before. It is the way back from a test migration, or one that didn't go as planned.

Roll back button and the confirmation dialog on the Migrate screen — **Roll back.** Every finished VM gets a Roll back action. The confirmation names the VM, counts the disks it will delete, states that the rollback cannot be undone, and reminds you that keeping a current, tested **FULL SYSTEM BACKUP** is your responsibility all before anything is deleted.

Only deletes what it built

Rollback only deletes a VM that this tool built — it refuses to touch a VM of the same name it didn't create. The original VMware VM is never deleted; it is only quarantined during migration, and fully restored on rollback (NIC reconnected, autostart returned to its original state, the migration note cleared).

ReferenceGuest-specific behavior & caveats

Windows

Windows guests get the STOP 0x7B boot fix applied automatically before first boot (arming the Hyper-V storage drivers IDE boot-start on Generation 1, the synthetic storvsc/vmbus stack on Generation 2). Data disks come online automatically after boot.

Old Windows (XP / 2003 / Vista / 7 / 2008 R2)

Most pre-Windows 8 / Server 2012 guests get a legacy network adapter automatically, since they lack the synthetic NIC driver. The exception is 64-bit XP / Server 2003, which get a synthetic adapter instead (explained below). Things to know:

64-bit XP / Server 2003 have no in-box NIC driver of any kind, so the tool attaches a synthetic adapter. It comes up undriven — an Ethernet Controller with no driver — so the migrated VM has no network at all on first boot.
Because there's no network, you cannot RDP into it yet. Get in on the host console (VMConnect). These guests have no Enhanced Session, so the pointer is captured — press Ctrl+Alt+Left to release it.
From the console, mount a Windows Server 2012 R2 vmguest.iso to the VM's DVD drive — this needs no network, which is exactly why it works — and install Integration Services inside the guest. That drives the synthetic adapter, and it networks — no manual adapter swap needed. RDP is available after that.
32-bit XP / 2003 are different: they keep the legacy adapter, whose driver (Intel 21140) is in-box, so they network on first boot and you can RDP in straight away.
Vista / 7 / Server 2008 / 2008 R2 also keep the legacy adapter and network on first boot (the 21140 is in-box on all NT6). Install Integration Services later if you want the faster synthetic NIC.

Prep tip — stage Integration Services before you migrate

For a guest that will need Integration Services (64-bit XP / Server 2003), copy the contents of the Server 2012 R2 vmguest.iso into a folder on the guest's C:\ drive while it's still on VMware — before you migrate. After migration the guest has no network and console-only access, so having the installer already on C:\ means you just run setup.exe from that folder at the console — no fumbling to get the ISO onto the Hyper-V host and mount it to the VM.

Disk controllers & snapshots

Any source controller PVSCSI, LSI-SAS, LSI-Parallel, NVMe, or IDE is fine. The target is always a Hyper-V synthetic controller, and boot-prep arms the right drivers regardless of the source.
Snapshots are handled automatically. The tool migrates the VM's current state (base + deltas merged). The source snapshot is never deleted or altered no action needed.
Multi-disk VMs migrate boot-disk-first; data disks are brought online in the guest.

Linux the one to read

Cloud images boot as-is. But a Linux guest installed from an ISO onto VMware may have a host-only initramfs that lacks the Hyper-V storage drivers (hv_storvsc / hv_vmbus) the Linux analog of the Windows 0x7B problem. On Hyper-V it drops to the dracut/initramfs emergency shell (/dev/disk/by-uuid/ does not exist).

Fix it on the source before migrating regenerate a generic initramfs (it's a superset and still boots on VMware, so it can't strip the source's boot):

dracut (recent Ubuntu, RHEL/Fedora):

sudo dracut --regenerate-all --force --no-hostonly

initramfs-tools (Debian / older Ubuntu): add hv_vmbus hv_storvsc hv_netvsc hv_utils to /etc/initramfs-tools/modules, then:

sudo update-initramfs -u -k all

Then shut the guest down normally and migrate. The tool backs up the original initramfs first (*.kwxbak), touches only the initramfs (not the kernel, GRUB, or fstab), and where VMware Tools and guest credentials are available can run the fix for you; otherwise it detects the condition and prints the exact command to run. Secure Boot is forced off on Generation 2 targets, so a Secure-Boot-on Linux guest is out of scope by design.

BSD, pfSense & firewall/router appliances

These boot as-is and get MAC-address spoofing automatically. During boot-prep you may see a benign line "No Windows installation found Is this a Windows guest disk?" that's the tool correctly skipping the Windows-only step; nothing is wrong.

Wrap-upAfter the migration

Verify before you decommission

The source VM is never deleted only quarantined (adapter disconnected, autostart off, a note added), and that's fully reversible. Before you decommission or delete the original, confirm the migrated guest boots, reaches the network, and shows its data disks.

Boot the new VM and log in.
Confirm networking (for old Windows, install Hyper-V Integration Services first).
Confirm all data disks are present and online.
Only then retire the source.

ReferenceTroubleshooting

Symptom	Cause & fix
"drive X has 0.0 GB free" on Start	The working folder isn't set to a real drive. Set it on the Target screen to a large local drive it resets each run.
Quarantine warning after migrating from ESXi	The host is on a free ESXi license (read-only API). Disconnect the source VM's adapter by hand, or put the host in evaluation mode.
Linux VM drops to an emergency shell	Host-only initramfs. Regenerate a generic initramfs on the source (see Linux notes) and re-migrate.
"No Windows installation found" for a firewall/BSD guest	Benign the Windows-only boot step is correctly skipped. Nothing to do.
Old Windows has no network	Install Hyper-V Integration Services in the guest (Server 2012 R2 `vmguest.iso` for 64-bit XP/2003).
A VM in a batch failed	Fix the cause, then click Retry Migration succeeded VMs are skipped.

LegalLicensing & notices

Your use of the software is governed by the End User License Agreement (LICENSE.txt, shown on first run). The application bundles two third-party, separately-licensed components, each run as a separate process:

govc

VMware vSphere API client (govmomi). Apache License 2.0 see govc\LICENSE.txt.

qemu-img

Disk converter. GNU GPL v2 full library licenses and the source written-offer are in qemu\THIRD-PARTY-NOTICES.txt.

About dialog with version and third-party attributions — **About.** Version, third-party attributions, and trademark notices, reachable from the title bar.

The tool runs a free one-migration trial per host. When the trial is used up, migration is blocked until a license key is entered; a valid key unlocks unlimited migrations on that host.

Trial used dialog prompting for a license key — **Trial used.** After the free migration, the tool asks for a license key — enter one to activate, or buy a license at kingwerx.com.

About dialog after activation, showing unlimited migrations — **Activated.** Once a valid key is entered, the About dialog reports **ACTIVATED — unlimited migrations on this host**.

Your responsibilities, warranty and liability

You review what will be migrated and you approve it. You are responsible for maintaining a current, tested FULL SYSTEM BACKUP of every machine this software changes — the source hosts, the target hosts, and the virtual machines themselves. Nothing this software writes is a backup. Support covers this program only — not VMware, Hyper-V, the guest operating systems, or the outcome of any migration.

The software is provided “AS IS” and “AS AVAILABLE”, without warranty of any kind, express or implied. KW Tech Solutions LLC does not warrant that any migration will succeed or be reversible, or that any virtual machine or data will be preserved, converted, or bootable. In no event is KW Tech Solutions LLC liable for any damages of any kind, including loss or corruption of data or virtual machines, downtime, or lost business. Nothing in this user guide — including any statement, example, or screenshot — creates a warranty or expands the scope of the license agreement; the terms in LICENSE.txt govern.

KingWerx™ is a product brand of KW Tech Solutions LLC. VMware, ESXi, and vSphere are trademarks of Broadcom Inc.; Microsoft, Windows, and Hyper-V are trademarks of Microsoft Corporation. This product is independent and is not affiliated with, authorized, sponsored, or endorsed by Broadcom/VMware or Microsoft.