VMware to Proxmox migration: costs, pitfalls and a step-by-step plan

Since Broadcom took over VMware, perpetual licences are gone: only subscriptions, sold in bundles and billed per core. For many organisations the renewal became a lot more expensive. CISPE, the association of European cloud providers, reports increases of 800 to 1,500 percent among its members and filed a complaint with the European Commission in March (cloudmagazin). Proxmox VE is the alternative most administrators look at first. For us it is not a new alternative: we have been running happily on Proxmox since 2016, and the cloud platform we built for PlanetNode runs on it too. The misconception is that a Proxmox migration is cheap because Proxmox is free.

Free software, not a free migration

The mass exodus from VMware has not happened. A survey cited by heise lists complexity and risk, unexpected costs and technical limits as the main obstacles. That matches what you see in practice: replacing the hypervisor is the smallest part of the job. The costs sit in four other places.

• Subscriptions — Proxmox VE runs without a licence, but in production you want the enterprise repository with tested updates. According to Proxmox's price list that costs EUR 120 to EUR 1,100 per occupied CPU socket per year, depending on the support level, and all nodes in a cluster take the same level.
• Backup integration — a lot of backup software talks directly to the VMware APIs. If your product supports Proxmox poorly or not at all, you are changing backup solutions too, with new retention, storage and restore tests. The good news: the open-source community has responded quickly, with adapters and integrations that let well-known backup solutions talk to Proxmox, and Proxmox Backup Server is open source itself. So check first whether a connector for your product already exists.
• Processes and documentation — runbooks, alert rules, scripts against the vSphere API, the way a new VM gets requested: everything that refers to VMware has to be redone.
• Knowledge — clustering, storage and networking work differently. Someone who ran vCenter for ten years needs a new set of reflexes, and a test cluster is the fastest place to build them.

So do not calculate the switch as "licence minus licence". Set the VMware renewal against subscriptions plus the hours for those four items. For most environments the sum still comes out in Proxmox's favour, just not by as much as it first seems.

Pitfalls you can see coming

A few things go wrong in almost every migration unless you plan for them:

• Quorum — a Proxmox cluster only acts when a majority of nodes can see each other. With two nodes you need a third vote, a small external QDevice, or losing one node stops the other as well.
• Shared storage — live migration and HA depend on the storage under the cluster. Choose it before you move the first VM; changing it afterwards is a second migration.
• Different virtual hardware — an imported Linux VM gets a different network card and disk controller. The interface name changes, and a static network configuration that refers to the old name boots the machine without a network. You can prevent that: on Linux VMs, pin the interface name to the MAC address before the migration, for example with a systemd .link file or a udev rule, and carry the MAC address of the old VM over in Proxmox. The interface then keeps exactly the same name after the import.
• Monitoring on the old platform — if your monitoring runs on the VMware cluster, you lose visibility exactly during the migration. Move it first, or outside both.

A step-by-step plan in the right order

The order is the same as for any infrastructure move: network, storage, compute.

1. Take inventory — which VMs, which dependencies, which links to backup and monitoring, and when the VMware licence expires. That date is your deadline.
2. Design network and storage — VLANs, bonding, a cluster network separate from VM traffic, and the storage choice.
3. Build the new cluster next to the old one — as code, so a second node or a reinstall is a repeat rather than manual work.
4. Sort out backups before production lands — and test-restore a VM before you rely on it.
5. Move the low-risk VMs first — a few internal machines, to test the import, the network configuration and your runbooks.
6. Migrate per application — with a maintenance window and a way back while the old platform still stands.
7. Clean up — update documentation, convert scripts, and retire VMware only once the last dependency is gone.

How long that takes differs per environment. Three hosts with a handful of VMs is a different job from several clusters with hundreds of machines and a backup chain that leans on them.

Migrating with help

We know Proxmox from our own work and can help with the design, building it as code, and the migration itself. Afterwards you can run the cluster yourself or leave it to us as managed servers, with root remaining yours. If you want the hardware in a Dutch data centre on our own network, see colocation. If scripts and integrations against the vSphere API need to move too, we handle that through software development. Is your VMware renewal coming up? Get in touch.