From ESXi to Proxmox VE 9.2: A Low-Downtime VM Migration Guide

Many teams want to migrate VMware ESXi to Proxmox VE 9.2 because it is free, open source, and has a real import tool built into the web interface. This guide shows you how to move Linux and Windows VMs, and a safe rollback plan if something goes wrong.

Licensing cost is not the only reason teams are switching. Proxmox VE 9.2 also brings real upgrades that make it a great choice:

• A Dynamic Load Balancer for HA clusters; Proxmox's version of VMware's DRS.
• Better software-defined networking (SDN), with WireGuard support and BGP/EVPN route filtering.
• Easy, GUI-based control of custom CPU models, useful for clusters with mixed hardware.
• Built on Debian 13.5, with Linux kernel 7.0, QEMU 11.0, and Ceph Tentacle 20.2 as the new defaults.
• No per-core or per-socket license fees. The platform is free and open source. A paid subscription is optional, only for enterprise updates and support.

If your infrastructure runs on rented hardware, moving these workloads onto dedicated servers built for Proxmox VE gives you full control over CPU, storage, and network design without a hypervisor license bill attached.

Before you migrate VMware ESXi to Proxmox VE 9.2, make sure to get these things ready:

• A Proxmox VE node on version 9.2.
• Network access from the Proxmox node to the ESXi host's management IP, with enough bandwidth for a full disk copy.
• An ESXi admin account.
• ESXi 6.5 through 8.0. This is the tested and supported range for the import tool.
• A list of the VMs you plan to move, with their vCPU count, RAM, disk size, and NIC settings.
• A full backup of every source VM.

The first step is to clean up work inside vSphere Client or the ESXi host client before you make any changes in Proxmox VE:

1. Delete or consolidate every snapshot. Leftover snapshots are the most common cause of a failed or extremely slow import.
2. Write down the network settings. Static IPs, DNS servers, and adapter names. Interface names always change after the move.
3. Uninstall VMware Tools inside the guest before you shut it down, if you can. It is easier to remove it now than to find and delete leftover VMware drivers later.
4. Check the datastore name. If it has special characters like +, rename it first; some imports break on datastore names with punctuation.
5. Shut the VM down cleanly, unless you plan to use Live-Import (explained in Step 4).

Proxmox VE 9.2 has a built-in ESXi import wizard. It connects straight to the ESXi host's own API and lists every VM on it. So you don't need to export OVF files or convert disks manually. 

From the web GUI, you must go to Datacenter > Storage > Add > ESXi, and fill in:

• ID: Any name you will recognize, for example esxi-host01.
• Server: The IP address or hostname of the ESXi host. Connect directly to the host, not through vCenter.
• Username / Password: Your ESXi admin login.
• Skip Certificate Verification: Check this box if the host uses a self-signed certificate, which is the default on every standalone ESXi install.

If you prefer the command line, you can run this on the Proxmox node:

This creates an entry like the one below in /etc/pve/storage.cfg. You can open this file with nano /etc/pve/storage.cfg to check it:

Note: This storage type only holds import content. It is read-only and used only to pull in VMs; you cannot use it to store backups or ISO files.

When you migrate VMware ESXi to Proxmox VE 9.2, this step confirms your connection actually works before you copy any real data. 

You can click the new storage entry in the left resource tree. Proxmox VE 9.2 will query the ESXi host and show every VM it finds, such as powered on, off, or suspended. If the list loads correctly, your credentials and network path are working.

Select the VM you want to move and click Import. The import dialog has three tabs:

1. General tab: Set the new VM ID, name, and which Proxmox storage the disks should use.
2. Advanced tab: Per-disk target storage, network bridge, NIC model, and disk controller. Pick VirtIO for the NIC and VirtIO SCSI for the disk controller in most cases; it gives the best performance.
3. Resulting Config tab: A plain preview of the exact VM settings before anything is copied. Always review this tab. It is easier to fix a wrong disk controller here than after the copy finishes.

Also, you must match the firmware type to the source VM. BIOS on ESXi becomes SeaBIOS on Proxmox, and EFI becomes OVMF. If the source used UEFI, you must add an EFI Disk. Proxmox needs this small extra disk to store UEFI settings.

This is the part that decides how much downtime you get when you migrate VMware ESXi to Proxmox VE 9.2. Here is the comparison of offline import and live-import:

Note: Live-Import sounds great, but there is a catch. If the import fails before it finishes, you lose any data written on the Proxmox side after the switch, because the background copy never completed. Test Live-Import on a low-priority VM first. Only use it for critical workloads after you see it work reliably on your network.

To start the copy, you must click through the import dialog. You can track progress under Datacenter > Tasks. A 50 GB VM on flash storage over a gigabit link usually finishes in a few minutes. Multi-terabyte VMs on setting up disks can take hours.

If you are moving several VMs from one ESXi host, do not start them all at once. The ESXi API only allows a limited number of connections at the same time. Proxmox recommends running four or fewer imports at once. If you run more, imports may hang, or you will see 503 errors from the ESXi side.

The import gives you a bootable VM, but not a finished one. This step is often skipped, and skipping it is why some VMs fail to boot right after you migrate VMware ESXi to Proxmox VE 9.2.

For Linux guests, run this before switching the disk controller to VirtIO SCSI:

This makes sure the VirtIO driver is actually built into the boot image, so the guest can still find its root disk after the switch.

For Windows guests: Because Windows does not ship with VirtIO drivers, you need to add them manually:

1. Download the latest stable VirtIO driver ISO from the Fedora-maintained virtio-win project.
2. In the Proxmox VM hardware settings, attach the ISO as a second CD-ROM drive.
3. Keep the disk controller set to SATA for the first boot after import.
4. Boot into Windows, open Device Manager, and install the VirtIO SCSI and network drivers from the attached ISO.
5. Shut the VM down, switch the disk controller to VirtIO SCSI in the VM hardware tab, and boot again.

If you switch straight to VirtIO SCSI and skip this two-step boot, the Windows VM will fail to start after the move from ESXi to Proxmox. This is the most common cause of that problem.

Firmware mismatches are another cause of a VM that imports fine but won't start. When you migrate VMware ESXi to Proxmox VE 9.2, always confirm the boot mode matches:

• If the source VM used legacy BIOS, keep the Proxmox VM set to SeaBIOS.
• If the source VM used UEFI, set the Proxmox VM to OVMF and make sure an EFI Disk is attached; this stores the UEFI variables Proxmox needs.
• For Windows guests with Secure Boot enabled on the source, you may need to re-enroll Microsoft's UEFI 2023 certificates. Proxmox VE 9.2 added a GUI and API option for this under the VM's EFI Disk settings.

If a UEFI guest boots to a black screen or a "no bootable device" message, check the boot order inside the OVMF firmware menu (press Esc during boot) and re-add the boot entry manually if needed.

Network adapter names always change after the move. For example, a Linux guest with the name ens192 under VMware may get a different name on Proxmox's VirtIO NIC. This is why you wrote down the old network settings in Step 1. You will need to set the static IP and DNS again on the new interface name.

For Windows guests, expect a "new network adapter detected" message on first boot. Windows may also reset the network profile from Private back to Public. Check your firewall rules again after this happens.

Also, match each ESXi port group to the correct Proxmox bridge, usually vmbr0 by default. You can do this in the Advanced tab of the import dialog, or later under the VM's Hardware > Network Device settings.

Windows systems with a volume license or KMS activation usually stay activated, because their license checks are more flexible about hardware changes.

Retail or OEM licenses tied to specific hardware may ask for reactivation, because the virtual hardware changes from VMware's chipset to Proxmox's QEMU/KVM one. You must keep your product key ready before the switch, in case you need to enter it again.

A clear switch plan is what actually keeps downtime short, not just the import itself. Follow this order for each VM:

1. Run the import while the source VM is still live on ESXi. Or shut down for an offline import.
2. Boot the new VM on Proxmox in an isolated test network, or with the NIC unplugged, so it does not conflict with the still-running source VM.
3. Validate the guest OS, apps, and services.
4. Once validation passes, shut down the source VM on ESXi and reconnect the new VM's NIC to the production network.
5. Update DNS records, load balancer targets, or any hardcoded IPs that pointed to the old VM if the IP address changed.

Note: If a workload cannot handle any planned outage, Live-Import is your best option. The guest starts on the new host, while the rest of the disk copies in the background.

Go through this list before you send real traffic to the new VM:

• VirtIO drivers installed and confirmed working.
• Boot mode matches the source, and EFI Disk is attached for UEFI guests.
• Static IP, DNS, and gateway settings reapplied to the correct network interface.
• QEMU Guest Agent installed and enabled.
• Application services start correctly and respond on their expected ports.
• Backup job or Proxmox Backup Server target configured for the new VM.

After you send traffic to the new VM, keep both the old and new VM available and check the following:

• Application logs for errors in the first hour of real traffic.
• Time sync: the time can fall out of sync after a hypervisor change.
• Scheduled tasks and cron jobs that may reference the old hostname or MAC address.
• Monitoring and alerting agents reconnecting under the new host identity.
• Performance metrics compared with your pre-migration baseline.

Keep the ESXi source VM powered off, but do not delete it, for at least a few days. Some problems do not show up in the first hour. A missing scheduled task or a monitoring agent tied to the old MAC address may only appear after a few days of real use.

The import tool only copies data one way and does not offer an undo button. If something goes wrong, you can roll back by switching back to the original ESXi VM, not by reversing the import. Here is how to do that safely:

1. Do not delete or reformat the source VM's disks on ESXi until the new VM has proven stable.
2. If problems appear after the switch, power the source VM back on in ESXi and re-point DNS or load balancer targets back to it.
3. Power off the Proxmox VM to avoid IP or MAC address conflicts on the network while the ESXi VM is running.
4. Find the failure using the fixes above, then retry the import once resolved.

This is why you keep the source VM untouched during the whole validation period; it is your way back if something goes wrong.

Even a well-planned move to Proxmox VE 9.2 can run into a few problems. Here are the most common ones and how to fix them:

Import storage shows a 500 error or won't list VMs. This is usually a login or certificate problem. You must check the ESXi username and password again, and make sure the account is not locked from an earlier failed login. If you did not check "Skip Certificate Verification," add the ESXi host's certificate to the Proxmox trust store.

Import is very slow or times out. First, check for old snapshots and remove them on ESXi, then try again. Also make sure you are connecting straight to the ESXi host, not through vCenter, since vCenter is slower.

VM will not boot after import. This always means a driver is missing. For Linux, boot a rescue ISO to check the disk is fine, then make sure VirtIO modules are in the initramfs. For Windows, switch the controller back to SATA, install VirtIO drivers, then switch back to VirtIO SCSI.

You see repeated 503 errors from the ESXi API. This means you have hit ESXi's limit on connections at once. Wait a few minutes, then retry with two or three imports at a time instead of a full batch.

A vSAN or encrypted-datastore VM will not import. Both are unsupported as an import source right now. For vSAN disks, first run a Storage vMotion to a normal datastore on ESXi, then import from there.

Switching VMware ESXi does not have to mean a long outage or rebuilding every VM. Proxmox VE 9.2's import wizard handles the disk copy for you. You just need to remove the old snapshots, add the VirtIO drivers, match the BIOS or UEFI, and test on one VM first. Follow the checklist in this guide, keep the source VM untouched until the new VM proves stable, and you can complete the move with only a short break in service.

Once your VMs are running well on Proxmox, you can check out our guide on setting up a ZFS mirror on Proxmox VE to add safe, built-in disk redundancy for your VM storage.