VMware to Proxmox Migration: Full Guide 2025-2026

Post-Broadcom context: why migrations are accelerating

Since Broadcom's acquisition of VMware in late 2023, the virtualization market has undergone an unprecedented upheaval. Broadcom's new commercial policies have triggered a wave of migrations toward open-source alternatives, with Proxmox VE leading the way.

Businesses are facing several major changes:

• Price increases of 3x to 10x: VMware license renewals show increases of 200% to 1000% depending on configuration and fleet size
• Forced VCF bundles: Broadcom mandates VMware Cloud Foundation, bundling vSphere, vSAN, NSX and Aria into a single package, even if you only use some of these products
• End of perpetual licenses: forced transition to an annual subscription model, eliminating any capitalization on past investments
• Partner program terminated: small resellers and integrators are cut out, reducing options for customers
• Contractual uncertainty: terms change regularly, making budget planning difficult

For a detailed total cost of ownership analysis and achievable savings, see our TCO VMware vs Proxmox 2026 comparison.

Prerequisites and preparation

Before starting the migration, thorough preparation is essential. Here are the key elements to validate.

Complete VMware inventory

Start by exhaustively documenting your VMware environment. Use RVTools or the vSphere Client to export this information:

# Export inventory via PowerCLI (on a workstation with vSphere PowerCLI)
Connect-VIServer -Server vcenter.example.com
Get-VM | Select Name, PowerState, NumCpu, MemoryGB,
  @{N='UsedSpaceGB';E={[math]::Round($_.UsedSpaceGB,2)}},
  @{N='ProvisionedSpaceGB';E={[math]::Round($_.ProvisionedSpaceGB,2)}},
  Guest, Notes | Export-Csv -Path vm-inventory.csv -NoTypeInformation

# List datastores and their usage
Get-Datastore | Select Name, Type, CapacityGB, FreeSpaceGB |
  Export-Csv -Path datastores.csv -NoTypeInformation

# List networks and port groups
Get-VirtualPortGroup | Select Name, VLanId, VirtualSwitch |
  Export-Csv -Path networks.csv -NoTypeInformation

Proxmox capacity planning

Size your Proxmox cluster based on the collected inventory:

• Storage: plan for 2x the total VM size (space for migration + growth headroom). For Ceph, plan for 3x (replication factor 3)
• RAM: keep the same total allocation + 10-15% headroom for the hypervisor and Ceph (if used)
• CPU: the vCPU:pCPU ratio can remain identical. KVM/QEMU overhead is comparable to ESXi
• Network: minimum 1 Gbps dedicated to migration, ideally 10 Gbps. Plan a migration network separate from the production network

Target Proxmox infrastructure

• Operational Proxmox VE cluster with a minimum of 3 nodes for high availability
• Network access between the VMware and Proxmox environments (direct or site-to-site VPN)
• Storage configured: Local-LVM, Ceph, ZFS or NFS/iSCSI depending on your needs
• Rollback plan documented with a tested fallback procedure
• Proxmox Backup Server (PBS) installed and configured for post-migration backups

To outsource your post-migration PBS backups, discover Proxmox PBS backup with NimbusBackup : off-site replication, encryption and deduplication included.

Proxmox cluster preparation

Configure your Proxmox environment to host the migrated VMs.

Network configuration

Replicate the VMware network topology on Proxmox. Each VMware VLAN corresponds to a Linux bridge or a VLAN on a VLAN-aware bridge:

# /etc/network/interfaces on each Proxmox node

# Main VLAN-aware bridge (replaces the VMware vSwitch)
auto vmbr0
iface vmbr0 inet static
    address 10.0.0.10/24
    gateway 10.0.0.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes

# Dedicated bridge for Ceph storage (10 Gbps network)
auto vmbr1
iface vmbr1 inet static
    address 10.10.0.10/24
    bridge-ports eno2
    bridge-stp off
    bridge-fd 0

# Dedicated bridge for migration (10 Gbps network)
auto vmbr2
iface vmbr2 inet manual
    bridge-ports eno3
    bridge-stp off
    bridge-fd 0

# Example tagged VLAN on vmbr0 (equivalent to VMware port group)
# VMs select the VLAN tag directly in their configuration

Storage configuration

Several options depending on your needs (see the Proxmox Storage documentation):

• • Local-LVM: high-performance local storage, ideal for testing and small deployments
• • Ceph: distributed storage for high availability (replaces vSAN)
• • NFS/iSCSI: to reuse an existing SAN (NetApp, Pure, etc.)
• • ZFS: for deduplication, compression and native snapshots

# Example: create a Ceph pool to host migrated VMs
pveceph pool create vmware-migration --pg_num 128 --size 3
# size 3 = replication across 3 OSDs (equivalent to a vSAN FTT=1 policy)

# Add the pool as Proxmox storage
pvesm add rbd ceph-migration --pool vmware-migration --content images,rootdir

# Check available space
ceph df

The 4 VMware to Proxmox migration methods

Proxmox offers several V2V (Virtual-to-Virtual) migration approaches. The choice depends on your context: number of VMs, downtime tolerance, available bandwidth and team expertise.

Method 1: Proxmox 8.x Import Wizard (recommended)

Since Proxmox VE 8.1, the Import Wizard allows direct import from vCenter or ESXi. This is the simplest and most reliable method for the majority of cases.

Method 2: Manual conversion with qemu-img

For more control, offline VMs, or if the Import Wizard is not compatible (older ESXi versions, VMs with specific disks), use qemu-img.

# === STEP 1: Export from VMware ===

# Option A: Export as OVA from vCenter (web interface)
# VM > Actions > Export OVF Template

# Option B: Export the VMDK directly via SCP from the ESXi host
scp root@esxi:/vmfs/volumes/datastore1/myvm/myvm-flat.vmdk /tmp/

# Option C: Use ovftool (VMware CLI)
ovftool vi://root@esxi/myvm /tmp/myvm.ova

# === STEP 2: Convert the disk ===

# Convert VMDK to qcow2 (recommended: supports snapshots)
qemu-img convert -f vmdk -O qcow2 myvm-flat.vmdk myvm.qcow2

# With compression (reduces transfer time)
qemu-img convert -f vmdk -O qcow2 -c myvm-flat.vmdk myvm.qcow2

# Convert to raw (best I/O performance, no qcow2 snapshots)
qemu-img convert -f vmdk -O raw myvm-flat.vmdk myvm.raw

# For sparse VMDKs (thin provisioning), specify the format
qemu-img convert -f vmdk -O qcow2 -p myvm.vmdk myvm.qcow2
# -p shows progress

# Verify the integrity of the converted file
qemu-img check myvm.qcow2
qemu-img info myvm.qcow2

# === STEP 3: Create the VM on Proxmox ===

# Create an empty VM with the correct config
qm create 100 --name myvm --memory 4096 --cores 4 \
  --net0 virtio,bridge=vmbr0,tag=100 \
  --ostype l26 --bios seabios --scsihw virtio-scsi-single

# Import the converted disk
qm importdisk 100 myvm.qcow2 local-lvm

# Attach the imported disk to the VM
qm set 100 --scsi0 local-lvm:vm-100-disk-0,discard=on,ssd=1

# Set the boot disk
qm set 100 --boot order=scsi0

# For a UEFI VM, add an EFI disk
qm set 100 --bios ovmf --efidisk0 local-lvm:1,efitype=4m,pre-enrolled-keys=1

Method 3: Live V2V migration (Veeam / Zerto)

For critical environments requiring near-zero RPO and minimal downtime, use a continuous replication tool:

• • Veeam Backup & Replication: supports VMware to KVM/Proxmox replication via Instant VM Recovery then export
• • Zerto: continuous replication with RPO of a few seconds, automated failover orchestration
• • Carbonite Migrate: live migration with block-level synchronization, multi-hypervisor support

Method 4: Incremental CBT migration (large VMs)

For large VMs (500 GB to several TB), a full migration can take hours. The CBT (Changed Block Tracking) method significantly reduces transfer time and downtime:

# Enable CBT on the VMware VM (via PowerCLI)
$vm = Get-VM -Name "big-database-server"
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.changeTrackingEnabled = $true
$vm.ExtensionData.ReconfigVM($spec)

# Create a snapshot to initialize CBT
New-Snapshot -VM $vm -Name "CBT-init" -Description "Enable CBT tracking"

# Use a tool like libguestfs or nbdkit to read the CBT deltas
# and apply them to the target Proxmox disk

# First full copy (in the background)
qemu-img convert -f vmdk -O qcow2 -p \
  "https://esxi/folder/big-db/big-db-flat.vmdk?dcPath=DC&dsName=DS1" \
  /tmp/big-db.qcow2

# Incremental passes use CBT to identify changed blocks
# and copy only the deltas, reducing final downtime to a few minutes

Strategy to minimize disruption

To minimize the impact on your users, follow this approach:

1. Migrate in batches: start with non-critical VMs (dev, test, staging), then secondary services, and finally critical services
2. Parallel migration: run both environments simultaneously during the transition phase
3. Data replication: synchronize data in real time with CBT or a replication tool
4. Progressive testing: validate each batch before moving to the next (checklist below)
5. DNS / Load Balancer: gradually redirect traffic to Proxmox (low DNS TTL)
6. Rollback ready: keep the VMware environment operational for 2 to 4 weeks after the last cutover

Common pitfalls and solutions

Here are the most frequent issues encountered during VMware to Proxmox migrations, and how to resolve them:

Real migration timelines

Here are real migration benchmarks by VM size, measured on our client projects. Times include format conversion (VMDK to qcow2) and network transfer.

Post-migration: validation and optimization

Driver and agent installation

After migration, optimize performance by installing the virtio drivers and QEMU Guest Agent:

# === LINUX ===

# Install the QEMU Guest Agent
apt install qemu-guest-agent    # Debian/Ubuntu
dnf install qemu-guest-agent    # RHEL 9 / Rocky / AlmaLinux
yum install qemu-guest-agent    # RHEL 7-8 / CentOS

# Enable and start the service
systemctl enable --now qemu-guest-agent

# Verify that virtio modules are loaded
lsmod | grep virtio
# Expected: virtio_blk, virtio_net, virtio_scsi, virtio_balloon

# Remove VMware Tools
apt remove --purge open-vm-tools open-vm-tools-desktop  # Debian/Ubuntu
dnf remove open-vm-tools                                 # RHEL/Rocky

# Regenerate initramfs without VMware modules
update-initramfs -u    # Debian/Ubuntu
dracut --force         # RHEL/Rocky

# === WINDOWS ===

# 1. Mount the virtio-win ISO as CD-ROM in Proxmox
#    (Download from https://github.com/virtio-win/virtio-win-pkg-scripts)
# 2. In the Windows VM, install:
#    - virtio-win-drivers (network, storage, ballooning, serial)
#    - virtio-win-guest-tools (QEMU Guest Agent + drivers)
# 3. Uninstall VMware Tools via Programs and Features
# 4. Reboot

Complete validation checklist

Post-migration optimization

Once VMs are migrated and validated, apply these optimizations:

• • Enable memory ballooning: allows Proxmox to reclaim unused RAM (virtio-balloon driver)
• • Enable discard/TRIM: add discard=on on disks to reclaim freed space
• • CPU type host: use --cpu host to expose all CPU instructions to the VM
• • NUMA topology: for VMs with large RAM, enable --numa 1
• • IO thread: enable iothread=1 on virtio-scsi disks for better I/O performance
• • Configure disaster recovery: set up a disaster recovery plan with inter-site replication

To explore our managed Proxmox VPS plans or benefit from post-VMware migration managed services , also see our case study: 100 VMware VMs migration (fr) .

# Recommended optimizations for a migrated VM (example VM 100)
qm set 100 --cpu host                           # Native CPU
qm set 100 --balloon 2048                        # Ballooning (min 2 GB)
qm set 100 --scsi0 local-lvm:vm-100-disk-0,discard=on,iothread=1,ssd=1
qm set 100 --numa 1                             # NUMA (if > 8 GB RAM)
qm set 100 --agent enabled=1,fstrim_clk_freq=1  # Guest Agent + auto TRIM

# Verify the final configuration
qm config 100

Cleanup and VMware decommissioning

After full validation of all migrated VMs (wait 2 to 4 weeks of stable operation), proceed with decommissioning the VMware infrastructure:

1. Verify that no VM is still running on VMware (final inventory)
2. Archive the vCenter configurations (export settings, DRS rules, alarms)
3. Remove remaining migration snapshots on Proxmox
4. Release VMware licenses (cancel Broadcom subscriptions)
5. Reassign or retire the hardware from former ESXi hosts
6. Update infrastructure documentation (network diagrams, CMDB, procedures)

Official documentation

To dive deeper into the concepts covered in this guide, refer to the official documentation:

Frequently asked questions about VMware to Proxmox migration