Worked example: a 30-VM small business moves from VMware ESXi to Proxmox VE
A fictional small business reviews its options after VMware licensing changes and follows our VMware to Proxmox playbook: inventory, network and storage mapping, guest preparation, waves through the ESXi import wizard, then backup and decommission. The business is invented to show how the steps fit together.
Who they are and what they faced
Illustrative example. The organisation is fictional; the steps follow our How to migrate from VMware ESXi to Proxmox VE.
Organisation
A small professional services and distribution business with about 30 virtual machines run by a two-person IT team (fictional)
Moving from → to
Three VMware ESXi 7.0 hosts managed by vCenter, with VMFS datastores on a shared storage array, several VLAN-backed port groups, Windows Server and Linux guests, and some Windows VMs with a vTPM and BitLocker → A three-node Proxmox VE cluster on the current release, with VLAN-aware bridges, local ZFS for most VMs and shared NFS storage for the VMs that need high availability
Constraints
- The VMware support renewal under the new licensing terms is due, and the business decided not to renew
- The database server and file server cannot lose writes, and outages must fall in a maintenance window
- The existing backup product's support for Proxmox VE had to be confirmed before VMware could be switched off
- The same staff run the business's day-to-day IT, so waves have to be small
Assess
The team exported the VM list from the vSphere Client with guest OS, provisioned and used space, host, datastore and network columns, then added firmware (BIOS or EFI), vTPM, encryption, snapshots and disk count for each VM, as the inventory step of the playbook asks. ESXi 7.0 sits inside the range the Proxmox wiki lists as tested for the import wizard.
They found old snapshots on several VMs, one VM with an encryption storage policy, a datastore name with a special character, Windows VMs with a vTPM and BitLocker, and a database server and file server with large disks. They also compared the options in the VMware alternatives guide before settling on Proxmox VE.
Decisions
- Use the Proxmox ESXi import wizard by default The playbook recommends the wizard wherever Proxmox can reach the ESXi hosts over the network, which was true for all three hosts.
- Use a normal import in a maintenance window for the database and file servers The playbook says live import loses new writes if it fails, so it should not be used for databases and file servers.
- Confirm backup support before decommissioning anything The playbook warns to check the backup vendor's Proxmox VE support, or deploy Proxmox Backup Server, before removing VMware copies.
Plan
The business case included a Proxmox VE subscription for the production nodes, as the playbook advises, with the team checking Proxmox's current subscription pricing rather than relying on an old quote, plus training time. The schedule ran a pilot of one low-risk Linux VM and one Windows VM, then waves built around disk count, keeping application tiers together.
The risk register included BitLocker recovery prompts on vTPM VMs, INACCESSIBLE_BOOT_DEVICE when switching Windows to VirtIO SCSI, 503 errors from the ESXi API during imports, and duplicate IP warnings from hidden old adapters.
Decisions
- Plan waves by disk count, not VM count Proxmox advises importing no more than four disks at a time, so the wave plan was built around that limit.
- Test on the no-subscription repository, then move production nodes to enterprise The playbook suggests this order for the subscription.
Design
Every port group was mapped to the vmbr0 bridge with its VLAN tag, with VLAN aware ticked on the bridge and a Linux bond over the two uplinks. The switch ports facing each node were configured as trunks carrying the same VLANs as the ESXi uplinks, and a small test VM on each VLAN tag pinged its gateway.
Each datastore was mapped to a Proxmox storage. VMs that needed HA were placed on shared NFS storage; the rest went to local ZFS. An NFS share both platforms could reach was added as file-based storage with Disk image content, in case any VM needed the OVF route. The Network and DNS worksheet held the saved IP settings and MAC addresses for every VM.
Decisions
- Design shared storage before promising HA The playbook says not to import HA workloads onto local storage and expect failover; HA needs shared storage such as Ceph or NFS, or replicated ZFS.
- Connect the wizard to each ESXi host, not vCenter The playbook advises one ESXi import storage per host with a local admin account, using vCenter only to find or vMotion VMs.
- Keep the old MAC for VMs with DHCP reservations The playbook offers either updating the reservation or setting the old MAC in the wizard's Advanced tab. The team set the old MAC to avoid changing DHCP.
Execute
While each guest still ran on VMware, the team saved ipconfig /all or ip addr output, installed the VirtIO drivers from the virtio-win ISO linked on the Proxmox wiki (using one version across the estate), checked Linux guests had VirtIO drivers in the initramfs, consolidated snapshots, removed the encryption policy, renamed the datastore with the special character and uninstalled VMware Tools or open-vm-tools.
For vTPM VMs they backed up each BitLocker recovery key and suspended protection with manage-bde -protectors -disable C: -RebootCount 0. Each VM was shut down cleanly just before its slot. In the import dialog they chose the target node, storage and bridge, attached the Windows boot disk on SATA, set the VLAN tag and old MAC, and ran imports one after another within the four-disk limit.
Decisions
- Import the Windows boot disk on SATA, then switch to VirtIO SCSI The playbook's method is to boot on SATA first, add a temporary SCSI disk so Windows loads the vioscsi driver, then move the boot disk to VirtIO SCSI single.
- Never start both copies The playbook warns that running a VM on both platforms risks network split-brain and disk corruption, so VMware copies stayed powered off.
Cutover
Each wave's cutover was the first boot on Proxmox VE. The team checked firmware matched the source and added a boot entry and EFI Disk where an EFI VM dropped to the UEFI shell, re-entered IP settings on the new adapter, removed hidden old adapters that caused duplicate IP warnings, switched Windows boot disks to VirtIO SCSI, installed and enabled the QEMU guest agent and checked it with qm agent <vmid> ping, and applied the playbook's best-practice settings.
For vTPM VMs a TPM state disk was added and BitLocker turned back on, with the new recovery key stored in key escrow. Application owners then ran their tests and signed off before the wave was declared complete.
Decisions
- Use a generic x86-64-v model CPU type The cluster nodes were not all the same CPU model, and the playbook says a generic model keeps live migration working in that case.
- Roll back by powering the VMware copy on, not by repairing in place The import wizard copies disks, so the VMware VM stayed intact and powered off. The rollback plan was to shut down the Proxmox VM, reinstall VMware Tools and start the original.
Close
After each wave the team ran a backup job covering the migrated VMs, restored one VM to a test ID and booted it, and turned on HA only for VMs whose disks were on the shared NFS storage, after checking the cluster had quorum. Validation followed the playbook's checks: every VM running with its ID in the wave plan, hardware as planned with no unused disks, guest agent responding, network settings matching, BitLocker protecting, owner tests passed, backups restoring and no completed-wave VM powered on in vSphere.
Once every wave was signed off and backed up on Proxmox VE, the VMware VMs were removed from inventory and deleted from disk, the ESXi import storage entries were removed from Proxmox, and the hosts were scheduled for reuse or disposal through the Decommission checklist.
Decisions
- Delete VMware copies only after backup and test restore on Proxmox The playbook says deleted VMware VMs and reinstalled ESXi hosts cannot be recovered except from backup.
The cutover timeline
- Wave day 17:30Go / no-go: guests prepared, VirtIO drivers installed, snapshots removed, BitLocker keys backed up, IP settings saved, owners available for testing.
- 18:00Suspend BitLocker on vTPM VMs. Shut down the first VM in the wave cleanly in the vSphere Client.
- 18:10Start the import from the ESXi import storage for that host, Windows boot disk on SATA, within the four-disk limit.
- As each import completesShut down the next VM and start its import. Keep VMware copies powered off.
- After each importFirst boot: check firmware, restore IP settings, remove hidden adapters, switch to VirtIO SCSI, enable the guest agent.
- After first bootAdd TPM state disk and re-enable BitLocker where needed. Store the new recovery key.
- Before end of windowApplication owners test and sign off. Run a backup of the wave.
- Next working dayTest restore one VM. Add HA for VMs on shared storage. Update the wave plan with VM IDs and results.
What surprised them and what they did
A Windows VM showed INACCESSIBLE_BOOT_DEVICE after switching to VirtIO SCSIThe team reattached the disk as SATA, added a temporary SCSI disk so the vioscsi driver installed, then switched again, as the playbook's errors table describes.
Imports slowed with 503 errors when two ran at onceThey went back to running imports one after another, which the playbook recommends before touching the ESXi session limit.
A vTPM VM asked for its BitLocker recovery key on first bootThe key had been backed up in preparation, so it was entered, a TPM state disk added and BitLocker re-enabled.
Windows warned about a duplicate IP addressThe old hidden network adapter still held it. Removing it in Device Manager, as the playbook says, fixed it.
One datastore could not be read by the wizardIts name contained a special character. Renaming it in the vSphere Client and adding the ESXi storage again fixed it.
Templates they used
Questions
Is this a real business?
No. The business is fictional. It shows how the steps in our VMware to Proxmox playbook fit together for a small estate.
Why connect to each ESXi host rather than vCenter?
The playbook advises adding one ESXi import storage per host, using a local admin account on that host.
Did vTPM state move with the VMs?
No. Proxmox cannot migrate vTPM state, so BitLocker was suspended before the move and a new TPM state disk was added afterwards.
Why not use live import for everything?
If a live import fails, writes made since it started are lost. The playbook keeps it for VMs where that is acceptable and uses normal imports in a window for databases and file servers.
When was VMware switched off?
Only after every wave was signed off, backed up on Proxmox VE and test-restored.