VMware to Proxmox: What to Check Before Moving a Production VM
A virtual machine (VM) that boots after a platform move is not necessarily a working business system. Before moving a production VM from VMware ESXi to Proxmox VE, you need answers about its storage, drivers, network, application dependencies, and recovery path before a VMware to Proxmox migration. Otherwise the first thorough test happens during the maintenance window, which is a terrible time to discover where the payroll database lives.
Start with the service, not the VM in a VMware to Proxmox migration
List the VMs you intend to move, but organize the plan around the business services they support. For each one, record its owner, operating system, firmware mode, disks and storage backend, network interfaces, IP settings, external dependencies, and acceptable outage. A single application may depend on a separate database, identity provider, file share, or scheduled integration. Moving one box without the rest of its dependency map can leave an impressively healthy-looking login screen that cannot actually log anyone in.
Agree on a recovery time objective (RTO). This defines how long the service may be unavailable. Agree on a recovery point objective (RPO) as well. This defines how much data the business can afford to lose. Ask the application owner to define an acceptance test. Perhaps this includes signing in and completing a representative transaction. Also confirm a scheduled job and check a downstream system. These are planning decisions, not promises that the migration tool can meet either objective.
Check what the import path can and cannot handle in a VMware to Proxmox migration
Proxmox VE documents an ESXi import workflow in which you add the source as storage, select a VM, and choose the destination disk storage and network bridge. That is a useful path, not a substitute for checking every source VM. The Proxmox migration guide identifies important exceptions: its documented automated import does not handle disks backed by VMware vSAN or encrypted VM disks, and existing snapshots can slow an import. If your inventory finds one of these conditions, investigate a supported alternative and test it before committing to a cutover.
Match the guest’s boot method. A VM using legacy BIOS should be configured with SeaBIOS on the destination; a VM using Unified Extensible Firmware Interface (UEFI) should use OVMF. Prepare guest drivers, particularly for Windows and VirtIO virtual disk or network devices. Proxmox also recommends removing old hypervisor-specific guest tools before migration because removal afterward can be more difficult. These are checks for the particular guest, not a blanket instruction to uninstall everything and hope for the best. Record the original settings and the intended destination configuration before changing either.
Capacity matters during the move as well as afterward. Confirm destination storage space, host resources, and transfer bandwidth. Avoid starting a pile of imports at once. Proxmox warns that concurrent transfers can run into source-session limits and memory pressure. Test with a representative VM rather than making the busiest production system your compatibility experiment.
“Live import” still involves an outage
The name is easy to misread. According to Proxmox’s description of live-import, the source ESXi VM is still switched off; the destination VM can start while the remaining disk data transfers in the background. This may shorten service downtime, but it does not eliminate it. Proxmox warns that if the import fails, data written after that destination start can be lost. The standard import workflow also powers down the source VM before transferring it to obtain a consistent state.
Choose a method based on the workload and a tested recovery path, not the feature name. For a database-backed service, decide when writes will stop, how you will verify the data after cutover, and who can authorize rollback. Once the destination accepts new writes, simply restarting the old source risks losing those new changes. A backup is only useful here if you know what it contains. You must also know where it is, who can restore it, and whether a test restore works within the business’s constraints. Keep the source untouched until you have a deliberate disposition plan.
Make the cutover testable and reversible
Before the maintenance window, run a pilot with a representative nonproduction VM or isolated copy. The point is to exercise firmware, drivers, disk import, networking, and an actual application test without putting the production service at risk. A pilot cannot prove every workload will behave identically; it can reveal assumptions worth fixing while there is still time.
For the real cutover, write down the go/no-go criteria:
- Before shutdown: Confirm a restorable backup, an approved outage window, responsible people, application dependencies, and the last known-good source state.
- At import: Check target disk mapping, boot firmware, guest drivers, network bridge, and any source-storage exception. Follow the current vendor instructions for the actual versions and configuration in use.
- After boot: Verify IP and name resolution, sign-in, application operations, data access, scheduled integrations, monitoring, and a new backup on the destination. A green VM console is not the acceptance test. Plan your VMware to Proxmox migration carefully.
- If it fails: Use a pre-agreed decision point and recovery procedure. Determine where the newest valid data resides before restarting the old VM or restoring a backup. Do not run two writable copies of the same service by accident.
For a hypothetical payroll VM, the owner might test a sign-in and a controlled, nonfinancial workflow, then confirm its database and downstream integrations respond. That example is not a universal test plan. Your application owner should specify what “working” means for your system.
Finally, check that the new VM is on the intended network segment and that firewall and management paths still make sense. Reliant’s secure network design checklist covers the broader questions; a hypervisor move is not an excuse to inherit an undocumented bridge forever.
The decision before the migration
If you cannot identify the data path, you are not ready for a production cutover.
Without a demonstrated restore, you are not ready for a production cutover.
If you cannot name the person who will accept the application, you are not ready for a production cutover. That does not mean you need a six-month project. It means doing the small amount of discovery that keeps a routine migration from becoming an unusually educational weekend.
Reliant System offers virtualization assessment, design, migration, and support for Proxmox VE, VMware, and Hyper-V environments. If you want help scoping the dependencies, talk with us about the specific workload.
If you need help choosing an approach or planning the cutover and rollback, talk with us.
Tell us the outcome you need.