The renewal quote arrives, somebody reads it twice, and then we get the call. That has been the shape of almost every VMware to Proxmox migration conversation in Kenya since Broadcom moved the whole portfolio to subscription, and the question is always the same two things: what does it cost, and how long are we down.
CloudSpinx plans and runs Proxmox migrations for businesses across Kenya and East Africa, on the same hardware wherever we can. Neither answer is a single number, but both are more predictable than most people expect, and the parts that go wrong are rarely the parts people worry about beforehand.
What actually changes on your invoice
Proxmox publishes its prices, which by itself makes the comparison easier than it used to be.
There is no licence fee to run it. The subscriptions buy you the enterprise package repository and support, and they run from EUR 120 per CPU socket per year at the Community tier to EUR 1,100 at Premium, billed annually per socket. A two-socket host on Standard is EUR 1,100 a year for that host. You can also run it with no subscription at all on the no-subscription repository, which we do not recommend for production but which is genuinely available and costs nothing.
The VMware side is harder to state honestly, because Broadcom ended perpetual licences and the associated support renewals and no longer publishes a public price list. Anyone quoting you a firm per-core VMware list price is quoting a third-party estimate. What you can compare is your own renewal quote against a published Proxmox number, which is the comparison that matters anyway.
The thing to hold onto: the licence is not where migration money goes. Migration cost is engineering time, and it scales with how unusual your environment is rather than with how many VMs you have.
How the VMs actually move
Proxmox VE has an integrated import path for ESXi. You add the ESXi host as a storage target, it enumerates the VMs, and you import them without needing an intermediate export to OVA sitting on a staging disk. This matters more than it sounds, because the older route needed as much free space as your entire estate and a lot of waiting.
Per guest the work is mechanical. Note the network and disk layout, uninstall VMware Tools, import, attach the disks on the right bus, install the QEMU guest agent, boot, check. Linux guests generally come across without complaint. Windows guests need the VirtIO drivers present before you switch the disk controller, and skipping that step gives you a machine that will not boot, which is the single most common self-inflicted wound in this whole process.
The current release is Proxmox VE 9.2, on Debian 13.5 with QEMU 11 and ZFS 2.4, and the import tooling in this line is materially better than what people remember from a few years ago.
What breaks, and what does not
Storage is usually fine. If you have a SAN presenting LUNs over iSCSI or Fibre Channel, Proxmox will consume it, and reusing the array you already own is the cheapest good decision available.
Networking is where the surprises live. Distributed switches do not translate, so port groups become Linux bridges and VLAN tags, and anything clever built on NSX has no equivalent and needs redesigning rather than porting. Budget real thought for this rather than assuming it maps across.
The other thing that does not map is the surrounding ecosystem. Backup products, monitoring agents and orchestration tooling that integrate with vCenter mostly do not integrate with Proxmox. Every one of those needs a plan before you start, and finding out mid-cutover that your backup product cannot see the new cluster is a bad afternoon.
Applications themselves almost never care. Domain controllers, SQL Server, ERP systems and line-of-business applications run on KVM without noticing, because they are seeing standard virtual hardware either way.
How long it actually takes
Per VM, the downtime is small. A guest of ordinary size is offline for the length of the disk copy plus a boot, and the copy is bounded by your storage and network rather than by anything Proxmox does. Live imports narrow that further.
The project timeline is a different question, and it is dominated by three things that have nothing to do with copying disks: how many maintenance windows your business will give you, whether you have spare hardware to build the target cluster on, and how much of the surrounding tooling needs replacing.
With spare hardware to build a target cluster first, a mid-size estate is a handful of scheduled windows, moving in waves, with the old environment still running until each wave is verified. Without spare hardware you are evacuating hosts to free them, rebuilding them into the new cluster and moving on, which works but serialises everything and takes noticeably longer. The estates that take longest are never the biggest ones. They are the ones with undocumented network dependencies.
When we tell people to renew VMware instead
We do say this, and it costs us the engagement.
If you are deep into NSX or vSAN, the migration is not a hypervisor swap, it is a redesign of your networking and storage layers, and the payback period stretches accordingly. If your operations team is genuinely built around vCenter and nobody there runs Linux comfortably, you are trading a licence cost for an operational risk, and that trade is not automatically good. And if your renewal came back roughly flat, the honest answer is that migration effort buys you very little this cycle.
There is also a third path people forget. If what you actually want is self-service tenancy rather than a cheaper hypervisor, Proxmox is the wrong target and OpenStack may be the right one. We wrote separately about what a private cloud actually costs once the licence line disappears, because the money moves rather than vanishing.
The order we do it in
Build the target cluster first, on hardware that is not currently running production, even if that means borrowing a couple of nodes or bringing in additional servers for the duration. Migrating into a cluster that does not exist yet is how people end up with no rollback.
Then move something that does not matter. A test VM, an internal tool, something with a forgiving audience. That first pass finds the driver problem, the VLAN that was tagged somewhere unexpected and the backup agent that does not install, and it finds them on a Tuesday rather than during a change window.
Then move in waves grouped by application rather than by size, so a whole system lands together and can be tested as a unit. Keep the source VMs powered off but intact until the wave has run a full business cycle, including a month-end if that is meaningful to you. Only then reclaim the hosts.
Do the backup last, and do it properly. Point Proxmox Backup Server at the new cluster, run a real restore of a real VM onto different hardware, and open the application. A migration is not finished when the VMs boot, it is finished when you have proven you can get them back.
Send us your host count, socket count and roughly what the renewal came in at, and we will come back with a scoped migration plan and one figure. It is free, it commits you to nothing, and if the answer is that you should renew this cycle we will say so: use the scoping form or WhatsApp +254 713 403 044.