Migrate VMware to Proxmox: A Technical Guide for Conversion, Cutover, and Continuity

Key Takeaways

• The native ESXi Import Wizard simplified conversion, but choice of method still depends on environment size and downtime tolerance.
• Windows VMs need VirtIO drivers to boot cleanly on Proxmox VE. Backup-based migration handles this automatically.
• The parallel-run window is the risky part. Carry backup coverage across it deliberately, workload by workload.
• DRS, operations monitoring, and DR orchestration have no Proxmox equivalent. Scope the rebuild into your timeline.
• Test a workload on Proxmox VE from its backup before committing to remove most of the cutover risk.

Hypervisor choice is back on the table. New workloads, licensing minimums, budget shifts, and the licensing changes that followed Broadcom’s VMware acquisition all point the same direction: Teams are asking whether their current platform still fits. Proxmox VE has become the leading open-source answer to that question.

A VMware to Proxmox migration is the process of converting virtual machines (VMs) from VMware vSphere or vCenter Server to Proxmox VE. This includes disk conversion, network and storage remapping, and re-establishing backup and disaster recovery (DR) coverage. That last piece is where most migration guides stop short, and it’s where cloud architects and backup admins carry the risk. For example, a rushed cutover may leave a silent gap in a backup job, or a DR runbook that no longer runs.

The platform decision is yours, and you don’t have to make it under pressure. Whatever you choose, your recovery plan should stay consistent instead of resetting every time your infrastructure does, and you should be able to prove the destination works before you commit to it.

Choosing a Migration Method

There’s no single correct way to move a VM from vSphere to Proxmox VE. There are three viable paths, and the right choice comes down to how many VMs you’re moving, how unusual their disk layouts are, and how much downtime the business will tolerate per workload. Map the methods against those constraints first, rather than picking one and forcing every workload through it.

Most real-world migrations mix methods; straightforward VMs move through the wizard in bulk, while awkward layouts get exported and converted with qemu-img convert. If you’re comparing options more broadly, our overview of VM migration and VMware migration tools covers the wider landscape.

Where the paths differ most is what happens to the guest OS on first boot. Both the wizard and manual conversion hand you a VM that needs driver work before it can perform properly. Veeam Data Platform does that work during the restore itself and can assign VLAN tags to the restored VM. Because the migration runs through the same platform that protects the workload afterward, there’s no second tool to stand up and no gap between the move and its protection.

What Doesn’t Carry Over Automatically

Some things have no Proxmox equivalent waiting for them. Knowing which ones those are before you build the project plan is what keeps a migration from stalling halfway through. Three gaps matter most:

• Automatic VM placement. Proxmox VE supports live migration between cluster nodes and high availability for automatic restart on node failure, but there’s no built-in DRS equivalent. Rebalancing is manual or scripted.
• Operations monitoring. vSphere-native operations tooling doesn’t extend to Proxmox VE. Most teams stand up Prometheus, Grafana, or a similar stack instead.
• DR orchestration. Failover and replication processes built against VMware-specific orchestration won’t recognize Proxmox VE as a source or a target, so those runbooks get rebuilt rather than repointed.

None of this is a reason not to migrate. These are line items to scope and budget, and they’re the reason a Proxmox migration is usually a multi-week project rather than a weekend. Our guide to Proxmox high availability covers what the platform does natively give you.

Pre-Migration Preparation

Most failed migrations fail before anything gets converted. The prep work below is what separates a migration that runs in waves from one that stalls on its third VM and has to be rolled back.

Inventory and Assessment

Start with getting a complete picture of what you’re moving. A conversion tool can only work with what it’s told about, and details missed at this stage may surface later as broken networking or failed boots. Capture the following for every VM that’s in scope:

• VM name, guest OS, and OS version
• CPU and RAM allocation
• Disk count and size per volume
• Provisioning type (thin or thick) and disk format
• Attached networks, VLAN tags, and MAC addresses for any DHCP reservations

Next, group the inventory by application or service dependency rather than alphabetically or by size. Migrating a database server on Tuesday and the application tier that depends on it the following Monday is how multi-tier applications break mid-migration. Move dependency groups together, and sequence them from lowest risk to highest risk so the process gets validated on workloads that nobody will miss.

Snapshot and VMware Tools Cleanup

Unconsolidated snapshots are the single most common cause of failed imports. Every snapshot needs to be consolidated and deleted in the source environment before you attempt the migration, not deferred until the tool complains. Two more items should be donein the same pass:

• VMware Tools. Remove it from Windows guests while the VM is still running on vSphere. Doing it after the move turns a straightforward uninstall into a more involved cleanup on a platform that no longer recognizes the tooling.
• Virtual TPM. vTPM state can’t currently be migrated to Proxmox VE. If full-disk encryption is tied to a vTPM, get the manual decryption keys in hand before the VM moves. Discovering this after cutover results in an encrypted volume you can’t open.

Windows Guest Preparation and VirtIO Drivers

Windows guests are where migrations most often go sideways on first boot. A Windows VM brought through a native or manual path comes in IDE or SATA mode, and it needs VirtIO drivers installed before you can switch it to VirtIO storage and network devices for full performance. Skip this step and the first boot on Proxmox VE can fail outright on a disk controller Windows doesn’t recognize.

The automated path. Veeam Data Platform injects the drivers during restore when a VM comes from another supported platform into Proxmox VE. It also sets the SCSI controller and NIC to VirtIO and installs the QEMU guest agent, so the VM boots correctly on the first power-on with no pre-staging on the source side.

The manual path. If you’re not migrating from backup, pre-install the VirtIO drivers from the Fedora-distributed driver ISO while the VM is still running on vSphere. Handling it after the move means recovering from a boot failure with a rescue disk or a temporary controller change.

Networking and Storage Mapping

Neither networking nor storage carries over on its own. Both need a decision to be made before the first VM converts, because a VM that lands on Proxmox VE with the wrong bridge or an unplanned storage backend has to be reworked rather than adjusted.

Network mapping. vSphere Standard and Distributed Switches, along with their port groups, all map to Proxmox Linux bridges, including vmbr0, vmbr1, and so on. VLAN tags are the part that trips people up. They need to be validated and replicated exactly and not assumed to travel with the VM. Confirm the tag on the Proxmox side against the source port group before the workload goes live, because a VM on the right bridge with the wrong tag looks healthy but can’t reach anything.

Storage mapping. VMFS, NFS, and VMware vSAN datastores each need an equivalent Proxmox storage backend chosen up front, whether that’s a ZFS pool, a Ceph cluster, LVM, or shared directory storage. This decision drives performance, snapshot behavior, and how much rework you’re signing up for, so make it deliberately rather than accepting whatever the import defaults to.

One hard limitation to plan around is VMs with disks backed by VMware vSAN, which can’t be imported directly through the native import mechanism. Those workloads need an alternate export path, so be sure to identify them during inventory rather than discovering them when the wizard refuses the job.

Using Instant Recovery to De-Risk the Migration Itself

Most migration planning asks the wrong question at the wrong time. Planning is often focused on the destination, asking if Proxmox VE is the right platform, will workloads perform, and  what breaks? These are things that should be answered before you commit, not after.

Instant VM Recovery powers a workload directly from its backup, in minutes, without waiting for a full restore to complete. Point that at your new platform and the migration stops being a leap. You spin the workload up on Proxmox VE from a backup you already have, confirm it behaves the way you expect, and only then plan the real cutover. In Veeam Data Platform, this extends to running Proxmox VE VMs from backups taken on other supported platforms and then migrating them to production storage, available under experimental support in the current release.

That changes the decision, not just the execution. You’re de-risking the move itself, not only the destination. This way, by the time you commit, you already know it works. This shows up three ways in practice:

• Choosing a destination. Spin the same workload up on each candidate and compare real behavior, not spec sheets.
• Accelerating a data center exit or hardware refresh. The project stops waiting on a slow, high-risk cutover.
• Reducing risk on any migration. You find out what breaks while the original is still running.

In every one of these cases it comes back to the same mechanism: Critical VMs powered on directly from backup within minutes, so the business keeps running while the migration happens around it.

Protecting Backup and DR Continuity During Migration

Here’s what migration guides tend to leave out. For a stretch of time, every workload you’re moving exists on vSphere and Proxmox VE at once, or briefly on neither. That stretch is a period of degraded recovery posture, and it doesn’t manage itself.

A failure here is quiet. A VM cuts over to Proxmox VE, the old backup job keeps pointing at a source that no longer holds the live workload, and the job may even keep reporting success. Nobody finds out until someone needs a restore and then it’s discovered that the most recent usable copy predates the migration. Backup coverage needs to be deliberately carried across that boundary, workload by workload, rather than reconnected once the project is done.

Three things need attention while the parallel run is open:

• Job configuration. Every migrated workload needs its backup job updated or recreated against the new platform, and the first run on the new side needs to be confirmed rather than assumed.
• Recovery Point Objectives and Recovery Time Objectives (RPOs and RTOs). Re-validate both against what backup and restores actually do on Proxmox VE. Carrying forward numbers documented for your vSphere process gives you a commitment you haven’t tested.
• DR runbooks. Any failover or replication process built against VMware-specific orchestration needs rebuilding against Proxmox-compatible protection. This is rebuild work, not reconfiguration, and it’s the item that’s most often discovered late.

Set explicit exit criteria before anything on the vSphere side gets decommissioned and make them evidence-based rather than simply a calendar date. A completed backup job on the new platform, plus a validated test restore, is a real exit criteria. “The VM boots and runs” is not. Write those two conditions into the migration plan for every workload, and the parallel-run window will close when the evidence says so, not when the schedule does.

The reason this matters is because the vSphere environment is your rollback. Decommission it before the new platform’s protection is tested and proven, and you’ve removed your own safety net at exactly the moment you’re most likely to need it.

Post-Migration Validation

A workload that boots isn’t necessarily a workload that’s migrated. Run these four checks per workload rather than per wave, because the failures they catch are specific to individual VMs:

• Drivers and performance. Confirm the guest is running on VirtIO storage and network devices, not still in IDE or SATA mode. A VM left on the fallback controller works but quietly underperforms.
• Network connectivity per VLAN. Test reachability on each attached network, not just the primary one. Secondary and management interfaces are the ones that get missed.
• Storage read and write performance. Benchmark against the new backend and compare to the old datastore. A ZFS pool and a VMFS datastore behave differently under the same load.
• Backup coverage. Confirm the new backup job has run and a test restore has completed successfully.

Get your replacement monitoring stack running and validated before you perform a full cutover as well, rather than after vSphere is already gone. Migrating into a platform you can’t observe means the first sign of a capacity problem is a user complaint.

Keeping Data Resilient After the Migration

The migration has an end date, but the requirements do not. Your platform changed, but your threat model didn’t. So, the protection posture you had on vSphere needs rebuilding as steady state on Proxmox VE, not to be treated as the last task on the project plan. Four things belong in that steady state:

• Backup jobs mapped to the new infrastructure, with retention and scheduling reviewed rather than just copied across.
• Immutable backup copies, so a compromised environment can’t take your recovery points with it.
• An off-site or cloud copy that follows the 3-2-1-1-0 Rule.
• Periodic restore testing, not the single validation you ran at cutover.

It’s worth being realistic about the shape most environments end up in: Very few teams actually move everything. A workload landing on Proxmox VE means you’re now running a mixed estate, with vSphere, Proxmox VE, cloud, and physical all in scope at once. Protection that spans those platforms keeps you on one operational model instead of two.

Once backup is settled, the next step is replication. Veeam Data Platform adds native VM replication jobs for Proxmox VE, including host-to-host and cross-datacenter. Confirm what’s supported for your specific setup, cluster vs. standalone, shared vs. non-shared storage, before you design around it.

Is Proxmox the Right Fit for Your Environment?

Not every environment should make this move, and the honest answer depends on what you’re running today rather than on the platform’s merits in isolation. These three profiles cover most cases:

Proxmox VE tends to fit well in small to mid-size environments, generally under about 100 VMs, without heavy existing investment in VMware-specific DR orchestration. The rebuild work stays manageable, the cost savings are real, and the feature gaps are ones a smaller team can absorb.

Budget a longer project if you have formal service level agreements (SLAs), regulated compliance requirements, or DR runbooks built on orchestration. This is a multi-quarter effort, not a weekend cutover. The conversion isn’t the long part; reaching DR and monitoring parity is.

If you’re moving to Proxmox VE, our hypervisor migration guide for VMware to Proxmox VE walks through restoring VMware backups directly onto the new platform with conversion handled during the restore. For what protection looks like once you’re there, see Veeam Backup for Proxmox VE.

FAQs