How to use VMware Converter

— ny_wk

VMware Converter lets you turn a physical server, a running Windows machine, or an existing virtual machine into a VMware vSphere virtual machine without rebuilding it from scratch. This guide walks through a complete VMware Converter conversion end to end — connecting to source and destination ESXi/vCenter hosts, sizing disks, CPU and memory, fixing the dreaded post-conversion mouse failure, and re-applying static networking — plus what to use now that the original Converter Standalone product has reached end of life.

What VMware Converter Does and When to Use It

VMware vCenter Converter Standalone performs two core jobs: physical-to-virtual (P2V) and virtual-to-virtual (V2V) migration. In a P2V conversion it reads the disks of a live or powered-off physical server and writes them into a new VM on an ESXi host or vCenter Server. In a V2V conversion it copies an existing VM — or a template living on a VMware Infrastructure host — into a fresh VM, optionally resizing disks and changing hardware along the way.

This is the classic workflow for retiring aging hardware, cloning a gold template into a new project VM, or moving a workload between datastores and hosts. Because the conversion is block-level, the resulting VM keeps the same operating system, installed applications, and data — you are migrating, not reinstalling.

Important reality check: Broadcom/VMware discontinued vCenter Converter Standalone; the last public release (6.x) is no longer developed and downloads were retired. The procedure below is accurate for that tool and remains useful on legacy estates, but for new work see the modern equivalent section near the end (vSphere clone/template, OVF/OVA export-import, or VMware Migration tooling).

Before You Start: Prerequisites and Pitfall-Proofing

A failed conversion almost always traces back to something skipped in prep. Confirm all of the following before you click Convert.

Network access: The Converter machine must reach the source host, the destination ESXi/vCenter host, and — for hot P2V — the live source OS over the required ports (notably TCP 443 and 902).
Credentials: You need a privileged account on the source (root on ESXi, or a vCenter admin) and on the destination, plus a local administrator on a live Windows source for agent install.
Free space: The destination datastore must hold the converted disks. If you plan to shrink volumes, confirm used space fits the new size.
Quiesce the workload: For a clean copy, pause or stop database/Exchange-type services on a live source, or run the conversion during a maintenance window.
Snapshot/backup: Never convert a production source without a current backup. P2V is read-only on the source, but assume Murphy is watching.

How to Use VMware Converter: Step-by-Step Conversion

The following steps cover a V2V conversion of a template on a VMware Infrastructure (ESXi/vCenter) host into a new VM — the same wizard flow applies, with minor source differences, to a P2V job. Work through the wizard panes in order.

Launch the tool. Start VMware vCenter Converter Standalone on your admin workstation.
Start a new job. Click Convert machine in the top-left of the toolbar to open the conversion wizard.
Define the source. Set Select source type to VMware Infrastructure virtual machine. Enter the server (ESXi host or vCenter) where the template or VM resides, then supply the root (or vCenter admin) credentials and click Next.
Pick the source VM/template. Browse the inventory, select the template (or VM) you want to convert, and click Next.
Define the destination. Set Select destination type to VMware Infrastructure virtual machine, enter the host where the new VM will live, supply its root/admin password, and click Next.
Name and place the VM. Type a clear Virtual machine name, choose the target datastore (and folder/host as prompted), then click Next.
Configure disks. In the options pane select Data to copy. Change Data copy type to Select volumes to copy so you can deselect unneeded partitions and resize each drive. Set thin or thick provisioning here to control datastore consumption.
Set CPU and memory. Select Devices and adjust the memory and vCPU/core count to match what the project actually needs — do not blindly copy the source if it was over-provisioned.
Configure networking. Select Networks, set the number of network adapters, and map each one to the correct port group / VM network on the destination.
Enable VMware Tools. Open Advanced options and tick Install VMware Tools on the imported virtual machine. This is what gives the guest proper drivers, better mouse/keyboard, and time sync. Click Next.
Review and start. Confirm the summary and click Finish to queue the job. Progress appears in the task list.
Wait for completion. A single machine commonly takes roughly 2–3 hours depending on disk size and network speed. When the status reads Completed, the new VM has been created successfully.

Common Pitfalls After a VMware Converter Migration

The conversion finishing is not the finish line. Legacy P2V/V2V jobs — especially older Microsoft virtual machine (MSVM) sources — leave behind a few predictable problems. Here are the two that bite most often and exactly how to fix them.

Pitfall 1: The mouse stops working after conversion

If the converted guest boots but the mouse is dead, a stale mouse-filter driver (msvmmouf) from the old virtual platform is still loaded ahead of the standard Windows mouse class driver. Remove it from the registry:

Open the new VM's console and start the Registry Editor with regedit.
Navigate to the mouse class key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96F-E325-11CE-BFC1-08002BE10318}
Edit the UpperFilters value: delete the msvmmouf entry and keep mouclass. Click OK.
Restart the virtual machine. The mouse should work on the next boot.

Tip: Use the keyboard to drive regedit if the pointer is unusable — Tab, arrow keys, and Enter are enough to reach and edit the value.

Pitfall 2: Networking breaks because the NIC was swapped

After first boot, the guest typically replaces the original physical network adapter with a virtual one (on older guests, a VMware Accelerated AMD PCNet Adapter; modern guests use VMXNET3). Windows treats this as brand-new hardware, so the new NIC comes up on DHCP and any previous static IP configuration is lost.

If the source used a static IP, re-enter the IP address, subnet mask, gateway, and DNS on the new adapter.
Watch for a "hidden" ghost NIC still holding the old IP. Reveal and remove it: open an elevated prompt, run set devmgr_show_nonpresent_devices=1 then devmgmt.msc, enable Show hidden devices, and uninstall the grayed-out old adapter before re-assigning the IP.
Confirm the adapter is mapped to the right port group so it lands on the correct VLAN.

Other gotchas worth checking

Boot/disk controller: A blue screen on first boot (e.g. INACCESSIBLE_BOOT_DEVICE) usually means a SCSI/IDE controller mismatch — switch the controller type on the VM or repair the boot drivers.
VMware Tools: If you forgot to tick the install option, install Tools manually after boot for proper drivers and time sync.
Disk signature/activation: Some Windows builds may prompt for reactivation after the hardware change.

Verification: Confirm the Migration Actually Succeeded

Do not declare victory at Completed. Run this short checklist on the new VM before handing it over.

It boots clean: Power on and reach the login screen with no recurring blue screens.
Input works: Mouse and keyboard respond in the console (the msvmmouf fix applied if needed).
VMware Tools running: The guest shows VMware Tools as installed/current; the host reports a green status.
Networking correct: ipconfig /all shows the intended IP (static re-applied), and the VM can reach the gateway, DNS, and the wider network. Ping a known host and resolve a name.
Services up: Application, database, and scheduled-task services start and clients can connect.
Hardware as designed: vCPU count, RAM, and disk sizes match what you set in the wizard.
Decommission carefully: Keep the source powered off (not deleted) for a few days so you can fall back if something surfaces.

The Modern Equivalent (Converter Standalone Is EOL)

Because vCenter Converter Standalone is discontinued, prefer these supported paths for new conversions:

V2V within vSphere: Use native Clone to Virtual Machine or Clone to Template / Deploy from Template in vCenter — it does everything the V2V flow above did, supported and faster.
Cross-platform moves: Export to OVF/OVA on the source and Deploy OVF Template on the destination to move VMs between standalone hosts or vendors.
P2V today: Use a current third-party imaging/migration tool (for example, disk-imaging and restore-to-VM products, or a backup product's instant-recovery-to-VMware feature). Most modern P2V is really "back up the physical box, restore the image into a VM."
Larger migrations: For fleet moves, evaluate VMware's HCX/migration tooling or your backup vendor's bare-metal-to-VM workflow.

Key Takeaways

VMware Converter migrates physical machines and existing VMs into vSphere VMs (P2V and V2V) without reinstalling the OS or apps.
Work the wizard panes in order — source, destination, name/datastore, Data to copy, Devices, Networks, then Advanced options — and right-size CPU, RAM, and disks during the job.
Always tick Install VMware Tools so the guest gets proper drivers, input, and time sync.
A dead mouse after conversion is fixed by removing msvmmouf from the mouse class key and rebooting; re-enter any static IP because the NIC swap resets networking to DHCP.
Converter Standalone is end of life — use native vSphere clone/template, OVF/OVA, or a modern backup-to-VM tool for new work.

Frequently Asked Questions

How long does a VMware Converter migration take?

Plan for roughly 2–3 hours per machine as a rough average, but the real driver is disk size and network throughput. A small system over a fast LAN can finish in well under an hour, while a multi-terabyte server over a slow link can take much longer.

Is VMware vCenter Converter Standalone still available?

No — it has been discontinued and the public download was retired, so it is no longer maintained or recommended for new conversions. The conversion procedure still works on legacy installs, but for current environments use native vSphere cloning/templates, OVF/OVA export-import, or a supported third-party migration tool.

Why doesn't the mouse work after a VMware conversion?

An old mouse-filter driver, msvmmouf, is left in the mouse class key from the previous virtual platform. Open regedit, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96F-E325-11CE-BFC1-08002BE10318}, remove msvmmouf from UpperFilters (keep mouclass), and reboot.

Why did my server lose its IP address after conversion?

The conversion replaces the physical NIC with a virtual adapter, which Windows sees as new hardware that defaults to DHCP. If the original used a static IP, you must re-enter the IP, mask, gateway, and DNS — and remove the hidden ghost NIC that may still be holding the old address.

For more hands-on system administration and virtualization walkthroughs, subscribe on YouTube @explorenystream.