The email subject line was blunt: "VMware is dead to us." It came from a CTO at a BPO company in Clark Freeport Zone. His VMware renewal had tripled, and he had just read a blog post about Proxmox — free, open-source, enterprise-ready. He wanted to migrate 200 VMs in 6 weeks.
We told him 6 weeks was aggressive. He said the board had already approved the budget. We started the following Monday.
That was 18 months ago. The migration took 11 weeks, not 6. We hit problems nobody warned us about. But the result was solid: 200 VMs running on Proxmox, zero licensing costs, and an IT team that now prefers it over VMware.
This is the real story of migrating from VMware to Proxmox. No vendor pitch. No ideology. Just what worked, what broke, and what you should know before you start.
What Is Proxmox VE?
Proxmox VE (Virtual Environment) is an open-source server virtualization platform. It combines KVM hypervisor and LXC container management into a single platform. Developed by Proxmox Server Solutions GmbH, based in Vienna, Austria.
The core tech: Proxmox runs on Debian Linux. It uses KVM for full virtualization (running Windows, any Linux distro, or other OS as a VM) and LXC for lightweight containerized workloads. The web management interface is built into the platform — no separate vCenter-like appliance needed.
Proxmox uses a cluster-based architecture. Multiple nodes form a cluster, and VMs can be migrated live between nodes. Storage is pluggable: local disks, ZFS, Ceph, NFS, iSCSI, or ZFS over iSCSI. The default and recommended storage is ZFS on local SSDs.
Licensing model: free and open-source under AGPLv3. There is an optional "Proxmox VE Subscription" (per node, annually) that gives you access to the enterprise repository and email support. The subscription is not required — the software works fully without it. Typical cost: 110-820 EUR per node per year depending on support level.
Why Consider Proxmox Over VMware?
The obvious reason is cost. After Broadcom restructured VMware licensing, many Philippine enterprises found themselves facing 5-10x cost increases. Proxmox eliminates licensing costs entirely. For a 10-node cluster, that is 50K-200K USD per year in VMware licensing you no longer pay.
But cost is not the only reason. Here is what we have seen drive real adoption:
1. Simplicity. Proxmox has one management interface. No vCenter, no NSX, no vRealize. For teams that are tired of managing six different VMware products, Proxmox feels like a breath of fresh air.
2. ZFS integration. Proxmox ships with native ZFS support. For storage-heavy workloads, ZFS provides snapshots, compression, deduplication, and replication without requiring a separate storage array. We have clients running 50TB on ZFS without issues.
3. Built-in backup. Proxmox Backup Server (PBS) is a separate open-source product that integrates natively with Proxmox VE. It provides incremental, deduplicated backups with verification. No Veeam license needed for basic backup scenarios.
4. LXC containers. Proxmox supports LXC containers natively. For Linux workloads, containers are 3-5x more efficient than VMs. We run monitoring agents, DNS servers, and lightweight web services as containers on Proxmox, saving significant RAM and CPU.
5. Community and transparency. With VMware, you get what Broadcom decides to give you. With Proxmox, the source code is public. Bugs get fixed by the community when the vendor is slow. This transparency matters for organizations that need to audit their infrastructure.
How We Migrate: The Step-by-Step Process
Proxmox migration from VMware is not a "lift and shift." The virtual disk formats are different (VMDK vs QCOW2), the networking model is different, and the management paradigm is different. Here is how we handle it.
Step 1: Inventory and Assessment (Week 1)
We export the full VM inventory from vCenter. For each VM, we capture: OS, CPU/RAM/disk, network configuration, installed applications, and any VMware-specific features in use (snapshots, vApps, resource pools, DRS rules).
Key question: which VMs use VMware tools? These need special handling because Proxmox uses QEMU Guest Agent instead. We document every VM that has VMware Tools installed and plan the guest agent migration.
Inventory output: a spreadsheet with every VM, its tier, migration complexity (low/medium/high), and estimated migration time.
Step 2: Proxmox Cluster Deployment (Week 1-2)
We deploy the Proxmox cluster on new hardware. For most Philippine clients, this means:
Hardware: 3-6 nodes (depending on workload), each with dual Intel Xeon, 128-256GB RAM, 2-4TB NVMe for local storage, 10GbE networking.
Cluster setup: install Proxmox VE on each node, create cluster, join nodes, configure ZFS pools (typically RAIDZ1 or RAIDZ2 for balance of performance and redundancy).
Storage: we use local ZFS for primary storage and NFS or Ceph for shared storage (ISO images, templates, backups).
Networking: create VLANs for management, production, and storage traffic. Proxmox uses Linux bridges or Open vSwitch for virtual networking.
One important note: Proxmox clusters need a quorum. For a 3-node cluster, you need at least 2 nodes running for the cluster to function. For even-numbered clusters, add a quorum device (a small VM on a third-party host or a dedicated hardware quorum device).
Step 3: VM Export from VMware (Week 2-3)
This is where things get interesting. VMware VMs use VMDK disk format. Proxmox uses QCOW2. You need to convert the disk images.
Method 1: Export via OVF/OVA. vCenter can export VMs as OVA files. We then extract the OVA (it is a TAR archive) and convert the VMDK to QCOW2 using qemu-img convert. This works well for most VMs.
Method 2: Direct VMDK conversion. If you have access to the ESXi datastore, you can copy the VMDK files directly and convert them on the Proxmox host. Faster, but requires SSH access to ESXi.
Method 3: For VMs with multiple disks, we use a scripted approach: export each VMDK, convert, then assemble the QCOW2 images in Proxmox with the correct disk ordering.
Conversion speed: typically 200-500 GB per hour depending on disk speed. A 1TB VM takes about 2-5 hours to convert.
Critical gotcha: thin-provisioned VMDKs become thick-provisioned QCOW2s unless you specify the -f flag during conversion. This can significantly increase storage usage. Always use: qemu-img convert -f vmdk -O qcow2 -f source.vmdk target.qcow2.
Step 4: Network Configuration (Week 3)
VMware networking (vSwitches, distributed switches, port groups) does not map directly to Proxmox networking (bridges, VLANs). Each VM needs its network configuration updated.
For each VM:
1. Map VMware port group to Proxmox bridge and VLAN tag.
2. Update IP configuration inside the VM (static IPs remain the same; DHCP VMs auto-reconfigure).
3. Update any firewall rules that reference specific network interfaces.
4. If the VM uses VMware-specific NIC drivers (vmxnet3), verify that Proxmox/KVM provides compatible paravirtualized drivers (virtio). Most modern OSes support virtio natively.
Networking lesson learned: we once had a client whose load balancer was configured to recognize VMs by MAC address. When we migrated to Proxmox, the new VMs had different MACs, and the load balancer dropped all traffic. Fix: manually set the MAC address in Proxmox to match the VMware MAC.
Step 5: Migration Execution (Week 4-8)
We migrate in batches: Tier 3 first, then Tier 2, then Tier 1.
For Tier 3 (offline migration):
1. Shut down VMware VM.
2. Convert VMDK to QCOW2 (can be done in advance).
3. Create VM in Proxmox with matching specs (CPU, RAM, disk, network).
4. Import QCOW2 disk.
5. Boot and validate.
For Tier 2 (scheduled downtime migration):
1. Schedule maintenance window (4-hour window).
2. Shut down VMware VM during window.
3. Convert and import (can be pre-staged to reduce window).
4. Configure network and boot.
5. Validate and notify users.
For Tier 1 (live or near-live migration):
This is the hardest part. Proxmox does not have native VMware-to-Proxmox live migration. Our approach:
1. Set up the Proxmox VM in advance with the latest data (rsync or database replication).
2. During maintenance window, stop writes to the VMware VM (for databases: put in read-only mode).
3. Perform final rsync or database log shipping to sync remaining changes.
4. Switch network configuration (DNS, load balancer) to point to Proxmox VM IP.
5. Start Proxmox VM and verify.
For a 500GB SQL Server database, this process takes about 30 minutes of application downtime. For file servers, about 15 minutes.
Step 6: Post-Migration Validation (Week 8-10)
After each batch migration, we run a validation period:
1. Monitor performance metrics (CPU, RAM, disk I/O, network) for 48 hours.
2. Compare against VMware baselines.
3. Test all application functionality.
4. Verify backup schedules are working with Proxmox Backup Server.
5. Check that monitoring tools (Nagios, Zabbix, Prometheus) can see the new VMs.
Common post-migration issues we have seen:
VMware Tools remnants. Some applications check for VMware Tools and behave differently without it. Solution: install QEMU Guest Agent and update any scripts that referenced VMware Tools paths.
Disk performance differences. Proxmox with virtio drivers and raw disk images can be faster than VMware with virtual LSI controllers. But if you use QCOW2 with copy-on-write overhead, disk-heavy workloads may be 5-10% slower. We mitigate this by using raw disk format for database VMs.
Memory overhead. KVM has slightly higher memory overhead per VM than VMware ESXi. For memory-constrained environments, this means you may need to reduce per-VM memory allocations by 5-10%.
Step 7: Decommission VMware (Week 11)
Once all VMs are validated on Proxmox:
1. Shut down VMware hosts.
2. Remove VMware licenses (or let subscriptions expire).
3. Repurpose or sell VMware hardware (many buyers in the secondary market).
4. Update all documentation to reference Proxmox.
5. Train IT team on Proxmox operations.
Best Practices for VMware to Proxmox Migration
1. Test Proxmox with a non-critical workload first. Deploy Proxmox alongside VMware for 2-4 weeks before starting migration. Let the IT team get comfortable with the interface.
2. Use ZFS for primary storage. It is the best-supported and most performant option in Proxmox. Avoid NFS or iSCSI for primary VM storage unless you have specific requirements.
3. Set up Proxmox Backup Server early. Backup is the safety net during migration. If a migration fails, you need a working backup to restore from.
4. Document VMware-specific configurations. Some VMs have VMware-specific settings (CPU reservations, memory shares, affinity rules) that have no direct Proxmox equivalent. Document these and plan alternatives.
5. Plan for the learning curve. Proxmox is simpler than VMware, but it is different. Budget 2-4 weeks for the IT team to become proficient.
6. Consider running mixed environments. Not everything needs to move to Proxmox. Keep VMware for workloads that use VMware-specific features. Run Proxmox for everything else.
7. Join the Proxmox community forums. The community is active and helpful. Many migration edge cases have been discussed and solved on the forums.
Common Mistakes We See
Mistake 1: Migrating without testing backup and restore. We had a client migrate 100 VMs before setting up Proxmox Backup Server. When they needed to restore a VM, they discovered their backup strategy did not work with Proxmox. Set up PBS first.
Mistake 2: Ignoring CPU compatibility. Proxmox/KVM is more sensitive to CPU feature differences than VMware. If your VMware hosts have newer CPUs than your Proxmox hosts, VMs may fail to migrate. Ensure CPU compatibility across the migration path.
Mistake 3: Underestimating the networking complexity. VMware networking is well-documented and mature. Proxmox networking works differently. Do not try to replicate your VMware network topology exactly — simplify where possible.
Mistake 4: Forgetting about Windows activation. Windows VMs activated against VMware hardware may deactivate when moved to Proxmox (different virtual hardware signatures). Plan for reactivation or use KMS/MAK licensing.
Mistake 5: Not budgeting enough time. Every migration we have done has taken 20-40% longer than initially estimated. Plan for the unexpected.
Conclusion: Proxmox Works, But Plan Carefully
Proxmox is a legitimate VMware alternative. It is free, capable, and well-supported by the community. We have successfully migrated over 500 VMs from VMware to Proxmox across Philippine enterprises.
But migration is not free. It costs time, expertise, and some downtime. The licensing savings are real, but do not expect a zero-cost migration.
If you are considering the move, start here:
1. Deploy a Proxmox test cluster (3 nodes, minimum).
2. Migrate 5-10 non-critical VMs. See how it goes.
3. Set up Proxmox Backup Server and test backup/restore.
4. If the pilot succeeds, plan the full migration with proper timelines.
5. Keep VMware running in parallel until you are confident in Proxmox.
The IT team at that BPO company in Clark? They now run 200 VMs on 8 Proxmox nodes. Their annual infrastructure cost dropped from 450K USD to 180K USD. The CTO who sent that email? He got promoted.
Want to go deeper? Explore [VMware alternatives](/en/vmware-alternative), [Run infrastructure services](/en/products/run), or [platform comparison](/en/compare).
FAQ
Q: Can we migrate Windows VMs from VMware to Proxmox?
Yes, but with caveats. Windows VMs need QEMU Guest Agent installed (replaces VMware Tools), and you may need to reactivate Windows due to hardware signature changes. Most modern Windows versions (Server 2016+, Windows 10/11) handle this gracefully.
Q: What about VMware features like vMotion and DRS?
Proxmox has live migration (similar to vMotion) built into the cluster. DRS (automatic load balancing) is not built-in, but Proxmox has HA (high availability) that automatically restarts VMs on other nodes if a node fails. For automatic load balancing, you can use third-party tools or scripting.
Q: Is Proxmox enterprise-ready?
Proxmox is used in production by thousands of organizations worldwide, including banks, hospitals, and government agencies. The optional subscription gives you access to the enterprise repository and professional support. For Philippine enterprises, we recommend the "Pro" subscription (EUR 220/node/year) for production environments.
Q: How does Proxmox backup compare to Veeam?
Proxmox Backup Server is excellent for Proxmox-native backups: incremental, deduplicated, verified, with built-in replication. For cross-platform backup (physical servers, non-Proxmox VMs), Veeam is more versatile. Many of our clients use PBS for Proxmox VMs and keep Veeam for legacy infrastructure.
Q: What if we need to go back to VMware?
You can export Proxmox VMs back to VMDK format using qemu-img convert. The process is reversible. However, going back means re-purchasing VMware licenses, so make sure you have a good reason before reversing the migration.