Moving from VMware to Proxmox: when restoring from Veeam is the better route

When restoring from Veeam is the sensible route

Most VMware exits start with a business trigger such as a renewal, a hardware refresh or a new price list. The sensible aim is to get the VMs somewhere else without a weekend of heroics.

Veeam Backup & Replication can restore VMware vSphere backups straight onto a Proxmox VE host, so the backups you already take can double as the migration source. That suits you under a few conditions.

• You already run Veeam Backup & Replication and have healthy, recent backups of the VMs you want to move.
• You want to rehearse each move from a restore point while the live VMware VM carries on undisturbed.
• You are moving a mixed estate in waves rather than everything in one night.
• You have, or can obtain, Veeam licence capacity for the Proxmox side (covered under cost and licensing below).

What actually goes wrong in a VMware to Proxmox move

A guest operating system installed under VMware expects VMware-shaped hardware: a particular storage controller, a particular network card and a set of VMware guest tools. Proxmox VE runs VMs on KVM and presents different virtual hardware, with VirtIO as the preferred, high-performance choice for disks and network cards. If the guest has no VirtIO drivers, it may not find its own boot disk.

Proxmox's own migration notes are blunt about this. On Windows, only IDE or SATA disks work out of the box, and moving to VirtIO needs extra steps and the VirtIO driver ISO. On Linux, the drivers may need adding to the initramfs, the small boot image the kernel uses to find the root disk. The same notes flag three other things: firmware must match (SeaBIOS for legacy BIOS guests, OVMF for UEFI guests, with an EFI disk), network adapter names usually change so static IP settings need revisiting, and a vTPM state cannot be migrated from VMware. If full-disk encryption depends on a vTPM, that VM needs special handling before you touch it.

Veeam's 13.1 release adds automatic VirtIO driver injection during restore for backups that did not come from Proxmox VE. Its What's New page describes this as enabling recovery of non-Proxmox VE backups to Proxmox VE targets. An early Proxmox forum report says a restored VM came up with VirtIO SCSI, SCSI disks and a VirtIO network card, but that is one user's experience. Treat injection as a feature to prove on your own guests during the pilot, not a promise that every Windows or Linux build will boot first time.

The realistic options side by side

There are four common ways to move a VMware VM to Proxmox. They differ mainly in what they need, how much downtime they cause and how easily you can back out.

• Veeam restore to Proxmox VE: uses your existing backups, leaves the source VM alone and supports rehearsal from a restore point. It needs a working Veeam and Proxmox integration and licence capacity. The restore itself is not a live migration, so each VM has a downtime window at cutover.
• Proxmox import wizard: add your ESXi host as an import source under Datacenter, Storage and import from there. It needs no extra software and Proxmox says it has been tested from ESXi 6.5 to 8.0. Importing through vCenter is possible but Proxmox warns it dramatically reduces performance. vSAN-backed disks and encrypted disks cannot be imported, and snapshots slow the import.
• Proxmox live-import: an option within the wizard that starts the VM on Proxmox while data is still being fetched. The source VM must still be powered off, so some downtime remains, and Proxmox warns that if the import fails, data written since it started is lost. We would reserve it for VMs where you have tested the network path and can tolerate that risk.
• OVF export or manual disk import: export with VMware's ovftool and import with qm importovf, or import the VMDK files with qm disk import. It works anywhere and costs nothing, but every VM is a hands-on job. Reasonable for a handful, tedious for fifty.
• Veeam Instant VM Recovery to Proxmox: Veeam's 13.1 What's New lists it, but under experimental support. We would not build a production migration plan around an experimental feature.

What the Veeam route needs in place

Check these before you schedule anything. Version support moves quickly, so confirm each against the current Veeam requirements page rather than relying on our snapshot.

• Veeam Backup & Replication with the Proxmox VE integration. For automatic VirtIO injection you need 13.1 or later.
• A supported Proxmox VE version, installed from the official Proxmox ISO. Veeam's documentation we retrieved listed Proxmox VE 8.2 to 9.1, although community posts about 13.1 mention 9.2, so check the live page for your build.
• At least one file-level storage configured in Proxmox VE, and sufficient space for the restored disks.
• Backups stored somewhere VM restore is supported. Veeam states that restores cannot come from external repositories, Veeam Cloud Connect repositories or tape.
• If your Veeam account on the Proxmox host is not root, the sudo rules changed in 13.1. Veeam KB4701 has a separate sudoers block per version, so existing Proxmox users should check it before upgrading.
• A restore point you trust, ideally one you have already test-restored on VMware first so you know the backup itself is sound.

A staged rollout using Veeam restore

The pattern below keeps the VMware VM as your rollback until you decide otherwise. Pilot first, then repeat the cutover sequence wave by wave. Each restore uses a real backup, so the timing you see on the pilot is the best guide you will get for planning later windows.

1. List the VMs you intend to move with their guest OS, firmware type (BIOS or UEFI), disk sizes, vCPU count, any vTPM or disk encryption, static IP addresses and the person who can sign off that the application works. Put awkward ones, such as encrypted guests or legacy operating systems, in a late wave. Choose a dull, replaceable VM for the pilot.
2. Check the pilot VM has a recent successful restore point in a repository that supports VM restore. Where the guest allows it, install the QEMU Guest Agent. Veeam's Proxmox integration relies on it for application-aware processing, and Proxmox uses it for tidier shutdowns and reporting.
3. Run the Entire VM Restore wizard in Veeam, choosing Proxmox VE as the target. You pick the restore point, restore mode, target cluster and storage, then name the VM and set its networking. Give the restored VM a new name and either an isolated network or a disconnected network card. If the original and the copy both appear on the production network, you can get duplicate IP addresses and confusing failures. Restores of large disks take time, depending on disk size, repository speed and the link to Proxmox, so note the duration for your planning and leave other work for the wait.
4. On the Proxmox node, open a shell as a user who can run qm and review the restored VM's hardware before first boot. This command only reads configuration. Check that the firmware matches the source, that the disk is attached as expected and which model the network card uses. Then start the VM and watch the console. Windows guests may restart once or twice while drivers settle. If the guest will not boot, switch the disk temporarily to SATA or IDE as Proxmox's guidance describes, load the VirtIO drivers and switch back.
   bashCopy

   qm config YOUR_VMID

5. Test the workload the way its owner would. Sign in, check the services start, confirm DNS and network access, check monitoring and any software licence tied to the MAC address or hardware identity, and remove the VMware guest tools. The Proxmox notes recommend removing VMware-specific tools; do it deliberately on the pilot so you know whether order matters for your guests.
6. For each production VM, agree a downtime window. Shut down the guest on VMware, run a fresh Veeam backup of the powered-off VM so the restore point holds the final data, and restore that point to Proxmox. Connect it to the production network and start it only once you are sure the VMware copy remains powered off. Never power on the same VM in both places on the same network.
7. Keep the VMware VM powered off but intact for an agreed period. If you must roll back, shut down the Proxmox VM and power on the VMware one. Anything written on Proxmox since cutover will not be on the VMware copy, so decide early how long rollback stays realistic for each application.
8. When a VM has been stable, include it in a Proxmox backup job, run the job and perform a test restore. Only then delete the VMware copy and remove its old restore points.

Cost and licensing during the overlap

Veeam licenses protection of Proxmox VE per protected VM. Each protected Proxmox VM consumes one Veeam Universal License instance, and a VM counts as protected if it has a restore point from the past 31 days. By default, Veeam revokes the instance if no new restore point is created in that time. Spare instances on an existing backup server can be used for Proxmox VMs.

We could not find documentation on how instances are counted while a VM has backups on both platforms. Until you have confirmation from Veeam or your reseller, plan as though both copies may count during the overlap. We have not priced any of this and you should use current Veeam pricing for your own estimate.

Choosing between the routes

Our judgement, rather than sourced fact: the Veeam route earns its place when you have the licences and a solid backup estate, because it turns migration into something you can rehearse. It is hard to justify buying Veeam just to move a few VMs.

• Use Veeam restore if you already run it, want rehearsals from restore points and can accept a downtime window per VM.
• Use the Proxmox import wizard if you do not use Veeam, your hosts are standalone ESXi rather than managed through vCenter and you can power VMs off for the transfer.
• Use OVF or disk import for a small number of VMs, or one-off oddities the other routes struggle with.
• Hold back any VM with a vTPM, encrypted disks or a legacy guest OS until the pilots have shown what is needed.
• Ask for help if the estate is large, the applications are business-critical or the cutover must happen inside a tight window. A pilot with an outside engineer reviewing the plan costs less than a failed Friday night.