// Technical Guide Updated: 2025

Migration Process:
Step by Step

A complete technical walkthrough for migrating your infrastructure from VMware vSphere / ESXi to Proxmox VE — from environment audit to production go-live. For IT administrators and architects.

<2min
VM downtime (zero for HA)
6
Process stages
97%
VMware license savings
// Table of Contents
  1. Environment Audit & Inventory
  2. Proxmox VE Architecture Design
  3. Cluster Installation & Configuration
  4. VM Conversion: virt-v2v
  5. Live Migration — Near-Zero Downtime
  6. Validation & VMware Decommission
01 Stage one

Environment Audit & Inventory

Every migration starts with a precise inventory. Without a complete picture of your VMware environment, safe migration planning is impossible. At this stage we collect all data necessary for downstream architectural decisions.

vmware-audit.sh
# Export inventory via PowerCLI
$ Connect-VIServer -Server vcenter.company.com
$ Get-VM | Select-Object Name,NumCpu,MemoryGB,@{N='DiskGB';E={($_.HardDisks|Measure -Sum ProvisionedSpaceGB).Sum}} | Export-Csv vm-inventory.csv
 
# Export network configuration
$ Get-VirtualSwitch | Export-Csv vswitches.csv
$ Get-VirtualPortGroup | Export-Csv portgroups.csv
 
# Datastore summary
$ Get-Datastore | Select Name,FreeSpaceGB,CapacityGB
✓ Found 48 VMs · 12.4 TB · 6 datastores · 3 ESXi hosts

What we collect during the audit

💡

Pro tip: Identify VMs with a large number of snapshots or RDM disks — these require special handling during conversion and may extend the migration timeline.

02 Stage two

Proxmox VE Architecture Design

Based on the collected data, we design the target Proxmox environment. The key decisions are: storage model, network configuration, and HA strategy. Good architecture at this stage eliminates 90% of operational issues post-migration.

A

Storage model selection

Three main options: Local-ZFS (simplicity, high I/O performance), ZFS Shared + RoCE (dedicated ZFS server with iSCSI/NFS — recommended), NFS/iSCSI (SAN) (integration with existing infrastructure). We recommend a dedicated ZFS server exporting storage via iSCSI or NFS, with an RDMA over Converged Ethernet (RoCE) network — latencies of 1–5 µs with minimal CPU overhead.

B

Network configuration

Proxmox supports Linux bridges, VLAN-aware bridges, bonding (LACP/active-backup), and SDN. We map VMware vSwitches to their Linux equivalents — port groups with VLAN IDs become bridge ports with vlan_id.

C

HA Cluster with Corosync

Proxmox Cluster Manager (pmxcfs) requires a minimum of 3 nodes for quorum. Proxmox's built-in pve-ha-manager stack (CRM + LRM) on top of Corosync manages automatic VM failover — no Pacemaker or external agents. We configure watchdog, fencing, and restart policies in line with client SLAs.

Storage recommendation: dedicated ZFS server + RoCE v2. 25/100 GbE NICs with RDMA support (e.g. NVIDIA/Mellanox ConnectX-5 or ConnectX-6) — latencies of 1–5 µs with minimal CPU overhead thanks to hardware offload. Full live VM migration without stopping, I/O performance comparable to local NVMe, full HA redundancy.

proxmox-cluster-init.sh
# Create Proxmox cluster (on node 1)
root@pve1# pvecm create CLUSTER-PROD --link0 10.0.10.11
 
# Add remaining nodes
root@pve2# pvecm add 10.0.10.11 --link0 10.0.10.12
root@pve3# pvecm add 10.0.10.11 --link0 10.0.10.13
 
# Verify quorum
root@pve1# pvecm status
Quorum information: Quorate: Yes · Nodes: 3/3
03 Stage three

Cluster Installation & Configuration

Proxmox VE is installed from an ISO image (Debian-based). A typical node installation takes about 15 minutes. After installation we configure storage, networking, and integrate with external systems: LDAP/AD, monitoring, backup.

ComponentVMware (equivalent)Proxmox VEConfiguration time
HypervisorESXiProxmox VE + KVM~15 min/node
Cluster managementvCenterProxmox Web UI / pvecm~30 min
Shared storagevSAN / SANZFS + RoCE / NFS / iSCSI~2–4h (ZFS server)
Virtual networkingvDS / vSSLinux Bridge + VLAN SDN~1h
BackupVeeam / VDPProxmox Backup Server~1h
MonitoringvROpsPrometheus + Grafana~2h
AuthenticationvSphere SSOLDAP / AD integration~30 min
ℹ️

We configure and test the Proxmox environment before beginning VM migration. VMware remains fully operational throughout — that is our safety net.

04 Stage four

VM Conversion: virt-v2v

The primary tool for converting VMware machines to KVM format is virt-v2v — an open-source tool from the libguestfs project. It converts VMDK disks to qcow2/raw format and automatically installs virtio drivers in the guest OS.

virt-v2v conversion
# Conversion via vCenter API (VM powered off)
$ virt-v2v -ic vpx://vcenter.company.com/DC/cluster/esxi01 \
    -it vddk \
    --vddk-libdir /opt/vmware-vix-disklib-distrib \
    -o local -os /var/lib/vz/images/100 \
    "vm-prod-webserver"
 
# Import to Proxmox after conversion
root@pve1# qm importdisk 100 vm-prod-webserver-sda.qcow2 local-zfs
root@pve1# qm set 100 --virtio0 local-zfs:vm-100-disk-0 --boot order=virtio0
 
✓ Conversion complete: 120 GB VMDK → 87 GB qcow2 (sparse)

Supported operating systems

⚠️

Watch out for RDM disks: Raw Device Mappings require a separate approach — we convert them to passthrough disks or replace them with a storage-level solution before migration.

05 Stage five

Live Migration — Near-Zero Downtime

For production systems we use a delta-sync technique: we copy data while the VM is running, then perform a short differential sync. The VM is only shut down for the final delta transfer — typically under 2 minutes. If the application runs on two or more VMs behind a load balancer (HAProxy, F5, etc.), downtime is zero — we migrate one VM at a time while the load balancer continuously routes traffic to the remaining available instances.

1

Initial sync (VM online)

We copy the disk image to Proxmox while the VM is running (VM remains accessible). For a 500 GB disk on a 10GbE link this takes ~7 minutes. The VM operates normally throughout.

2

Delta sync — brief freeze

We stop the VM for the block-level delta transfer (changed blocks only). Under typical production load the delta is 0.5–3% of disk size. For a 500 GB disk — delta ~2 GB — the transfer takes approximately 20–90 seconds.

3

Start on Proxmox + UAT

We start the VM on Proxmox and run automated acceptance tests (ping, port check, application health endpoint). VMware remains shut down but ready for rollback throughout the UAT window.

migration-monitor.sh
# Real-time migration status
$ proxmox-migracje migrate --live \
    --src vcenter.company.com \
    --dst pve1.company.com \
    --vm-name prod-webapp-01 \
    --near-zero-downtime
 
→ Phase 1/3: Initial sync [████████████░░░░░░░░] 62% (310/500 GB)
→ Phase 2/3: Delta sync [████████████████████] 100% (1.8 GB) ✓
→ Phase 3/3: UAT checks [████████████████████] 100% PASS ✓
✓ Migration complete. Downtime: 47 seconds. Rollback window: 24h
06 Stage six

Validation & VMware Decommission

The final stage — but the most important from a safety perspective. We decommission VMware only after confirming the stability of the Proxmox environment. The standard observation period before closing the VMware license is 30–90 days.

🎯

Rollback always possible: Until the ESXi hosts are formally shut down, the VMware environment remains operational. Reverting to VMware in case of a critical issue takes minutes — simply change DNS or switch routing.

Ready to migrate?

We will conduct a free audit of your VMware environment and prepare a detailed migration plan with cost estimates and a timeline.

⚡ Free Environment Analysis → Financial Analysis