How We Migrated 500+ VMs from VMware to Proxmox Without Stopping the Business

One of our clients found their VMware bill jumping from €80,000 to €350,000 per year after the Broadcom acquisition. They had 12 ESXi hosts, over 500 virtual machines, and three sites. They needed a real alternative, without stopping the business. This is what we did.

The context: when VMware is no longer an option

The client is an industrial company with presence at three sites in Catalonia. Their virtualization environment had been running on VMware vSphere with vSAN for seven years: 12 ESXi hosts, over 500 production VMs, VLAN networks segmented by department, and replication between sites. Everything worked. Until the renewal bill arrived.

With Broadcom's licensing model change, the cost went from €80,000 to €350,000 per year — a 337% increase. It was not a mistake: it was the new price. The client called us with one clear question: "Can we leave VMware without stopping the business?"

Phase 1: Full audit (weeks 1-2)

Before touching anything, we needed to know exactly what we had. We performed an exhaustive inventory of the entire VMware environment using RVTools, custom PowerCLI scripts, and manual dependency documentation.

# Inventario automatizado con PowerCLI
Get-VM | Select Name, PowerState, NumCpu, MemoryGB, `
  @{N='DiskGB';E={(Get-HardDisk -VM $_ | Measure -Sum CapacityGB).Sum}}, `
  @{N='VLAN';E={(Get-NetworkAdapter -VM $_ ).NetworkName}}, `
  Guest, VMHost | Export-Csv -Path vm_inventory.csv

# Resultado: 512 VMs, 14.3 TB de disco, 47 VLANs unicas

The audit revealed surprises. We found 47 machines running Windows Server 2012 R2 that nobody remembered existed, some running old file services that still had active users. We also discovered 23 orphaned snapshots consuming 2.1 TB of unnecessary space.

Phase 2: New environment design (weeks 2-3)

We designed a 12-node Proxmox VE cluster (reusing the same hardware) with Ceph as distributed storage. The key was to exactly replicate the existing network topology so applications would not notice any change.

Phase 3: Pilot with 30 VMs (weeks 3-4)

We did not migrate everything at once. We selected 30 non-critical VMs — development environments, test servers, and internal tools — to validate the entire process. The VMDK to QCOW2 conversion was the technical core:

# Conversion VMDK -> QCOW2 con compresion
qemu-img convert -f vmdk -O qcow2 -o preallocation=metadata \
  vm-disk.vmdk vm-disk.qcow2

# Importar a Proxmox (directo a Ceph pool)
qm importdisk 100 vm-disk.qcow2 ceph-ssd --format raw

# Para VMs grandes, conversion directa a raw en Ceph (mas rapido)
qemu-img convert -f vmdk -O raw vm-disk.vmdk rbd:ceph-ssd/vm-100-disk-0

# Verificacion de integridad
qemu-img check vm-disk.qcow2
qemu-img compare vm-disk.vmdk vm-disk.qcow2

The pilot revealed two important issues that we resolved before the mass migration:

Phase 4: Mass migration (weeks 4-8)

With the pilot validated, we entered migration mode. Every Saturday, in 4-hour maintenance windows (06:00 to 10:00), we migrated batches of 50 to 80 VMs. We automated the entire process with bash scripts:

#!/bin/bash
# migrate_batch.sh - Migracion por lotes VMDK -> Proxmox/Ceph
BATCH_FILE="$1"          # CSV: vmname,vmid,pool,node
LOG="/var/log/migration/$(date +%Y%m%d).log"

while IFS=',' read -r vmname vmid pool node; do
    echo "[$(date)] Migrando $vmname -> VMID $vmid en $node" | tee -a "$LOG"

    # 1. Exportar VMDK via SSH desde ESXi
    ssh esxi "vim-cmd vmsvc/power.off \
      \$(vim-cmd vmsvc/getallvms | grep $vmname | awk '{print \$1}')"
    scp esxi:/vmfs/volumes/datastore1/$vmname/$vmname.vmdk /tmp/migration/

    # 2. Convertir e importar directamente al pool Ceph
    qemu-img convert -p -f vmdk -O raw \
      /tmp/migration/$vmname.vmdk rbd:$pool/vm-${vmid}-disk-0

    # 3. Crear config de VM en Proxmox
    qm create $vmid --name "$vmname" --memory 4096 --cores 2 \
      --net0 virtio,bridge=vmbr0 --ostype l26 \
      --scsi0 $pool:vm-${vmid}-disk-0 --scsihw virtio-scsi-single \
      --boot order=scsi0

    # 4. Verificacion
    qm start $vmid
    sleep 30
    qm agent $vmid ping && echo "[OK] $vmname operativa" | tee -a "$LOG"

    # 5. Cleanup
    rm /tmp/migration/$vmname.vmdk
done < "$BATCH_FILE"

For critical VMs — SQL Server, Exchange, and the ERP — we could not afford any maintenance window. We used a hot replication strategy:

Phase 5: Optimization and decommission (weeks 8-10)

With all VMs migrated, we spent two weeks optimizing the Ceph cluster performance and completing the transition:

# Tuning Ceph OSD para NVMe
ceph config set osd.* bluestore_cache_size_hdd 1073741824
ceph config set osd.* bluestore_cache_size_ssd 3221225472
ceph config set osd.* osd_memory_target 4294967296

# Balanceo de PGs
ceph balancer mode upmap
ceph balancer on

# Ajuste de recovery para no impactar produccion
ceph config set osd osd_recovery_max_active 1
ceph config set osd osd_recovery_sleep_hdd 0.1
ceph config set osd osd_max_backfills 1

# Verificacion de salud
ceph health detail
ceph osd pool stats

In parallel, we trained the client's IT team with 3-day hands-on sessions covering VM management, Ceph, backups, HA, and troubleshooting. We delivered complete documentation of the entire environment and a runbook for incidents. Finally, we decommissioned the ESXi hosts: format, license reclamation, and vCenter retirement.

Results: the numbers speak

Lessons learned: 5 tips for your migration

Complete timeline

Your turn

If you are facing a VMware renewal with outrageous prices, or simply want to explore open alternatives with professional support, we can help. We have been deploying and managing Proxmox environments with Ceph in production for companies of all sizes for years. Every project is different, but our accumulated experience allows us to plan migrations with guarantees.