Partners keep sending us VMware renewal quotes with a note attached, and the note is usually some version of "is this real?". We published the maths in our Proxmox vs VMware comparison earlier this year: Broadcom collapsed more than 168 SKUs into two bundles, moved everything to per-core subscription with 72-core minimums, and the renewal examples we documented ran three to five times the old price, with one 8-host environment going from about $12,000 a year to six figures. As of July 2026 we haven't seen Broadcom soften any of it.
A renewal quote that size is also a budget. It won't fund the exit "once and done", nothing in infrastructure works that way, but a capital purchase plus support subscriptions that total a fraction of the Broadcom number is a different financial shape entirely, and it's one you control. This post is about what that project involves, including the parts nobody budgets for at the start.
What Proxmox replaces, and what it doesn't
Proxmox VE is the landing spot in nearly all of these conversations. KVM hypervisor, live migration, high availability and clustering all sit in the base product. The software is free; the enterprise subscription, priced per socket, buys the stable repository and support from the Proxmox team in Vienna, and it costs in the hundreds of dollars per host per year, against a per-core bill measured in tens of thousands. If the platform itself breaks, support comes with the subscription, and our engineers wrap design, sizing and escalation around that. Your team will also need ramp time. The concepts map cleanly from vSphere, but the CLI is different, and a VMware-only team should budget some weeks of getting comfortable before production cutover.
It is not a full VMware Cloud Foundation replacement. There's no NSX equivalent, and nothing that stands in for Aria automation or the Tanzu runtime. What it does replace cleanly is the part most Australian mid-market environments actually use, a hypervisor cluster with HA, live migration and snapshots. Environments that lean on the rest of the VCF stack need a longer evaluation than a blog post, and there's a section on them further down.
The storage decision
vSAN doesn't come with you. Proxmox's built-in answer is Ceph or ZFS, and Ceph is genuinely capable, but it wants three or more well-specced nodes and someone on the team comfortable operating a distributed storage system. Some MSPs run it happily. Others look at a client's 40-VM environment and decide it doesn't need that much ceremony.
The alternative is shared storage the way it worked before HCI: a dual-controller array presenting iSCSI, with Proxmox running multipath and LVM on top. StoneFly is the storage line we reach for here. It's the only storage vendor we carry with a dedicated Proxmox VE appliance in its range. The SAN and unified lines present standard iSCSI and NFS, which Proxmox consumes natively. In a case study StoneFly publishes about its own gear, a nine-node Proxmox cluster runs over multipath iSCSI with LVM, hosting PostgreSQL, MongoDB and Kubernetes workloads.
For sites that want compute and storage in one box, the USS hyperconverged line supports Proxmox VE by name, with dual hardware controllers. The dedicated Proxmox appliance adds StoneFly's air-gapped vault on top. StoneFly has also stood up a VMware-to-Proxmox migration service, and its SCVM storage software ships as a QCOW2 image packaged for Proxmox specifically, with its own deployment guide. A hardware vendor doesn't do all of that for a hypervisor it considers a niche.
Backup is where exits used to fall over
For years the honest objection to leaving VMware was that the backup tooling lived there. That objection has expired. Veeam added Proxmox VE support in version 12.2, back in August 2024, delivered through a dedicated plug-in; Veeam's current support matrix covers Proxmox 8.2 through 9.1. NAKIVO backs up Proxmox natively as well, and we've written about that pairing before.
On the target side, StoneFly's DR365V is the Veeam Ready appliance in our lineup, certified as a Veeam repository with primary and capacity-tier immutability. StoneFly announced Proxmox support for it in mid-2024, and says the full ransomware feature set, the air-gapped vault and volume-deletion protection among it, has been tested and is functional for Proxmox environments. For shops using Proxmox Backup Server, StoneFly's guidance is to run PBS on a separate physical node and put the appliance behind it as the immutable tier.
StoneFly's design argument is worth hearing even if you buy nothing: immutability set as a policy in backup software can be unwound by an attacker with root on the backup server, so they enforce WORM in the storage controller's firmware, where a compromised host can't reach it. Ransomware crews go for backups before anything else these days, and firmware-level WORM is at least aimed at the right problem. That said, it's their claim and their design intent; we haven't seen an independent teardown of it.
What actually breaks in the move
Proxmox's ESXi import is a cold import. Each VM comes across in a maintenance window, powered off, with a conversion step in the middle. There is no vMotion into Proxmox.
Things to plan for that the brochures skip:
- VMware Tools comes out, qemu-guest-agent goes in, per guest.
- Network mappings are rebuilt: vSwitches and port groups become Linux bridges or Open vSwitch configs.
- Some Windows licensing is keyed to the host; check what re-activates and what needs re-keying before the first production wave, not after.
- vCenter goes away, and whatever your monitoring or RMM watched it with needs a new integration.
- Your cyber insurer may treat the hypervisor change as a material disclosure. Tell them before, not after.
The pattern that works is a pilot cluster first, then production in waves, with the old VMware cluster left standing until the final wave has run long enough to trust. That way the rollback plan for any wave is simply "it's still there".
Who should stay on VMware
Several kinds of environment shouldn't make this move, and it's better to know early. Anything built on NSX micro-segmentation, Aria automation or Tanzu has no clean Proxmox equivalent. GPU-heavy VDI estates need a careful capability check before anyone promises parity. Some government and healthcare contracts name the incumbent platform in their compliance schedules, which turns a migration into a paperwork project as much as a technical one. And an organisation deep in a multi-year ELA usually does better running the term down than breaking it. There are also teams that simply don't have the appetite for a platform change this year. Renewing now and planning the exit for the next cycle is a legitimate answer too.
Before you sign the renewal
If you want the alternative priced, send us the renewal quote plus the basics: VM count, total vCPU and RAM, storage in TB, and what currently backs it up. We'll come back with the exit costed end to end: Proxmox subscriptions, StoneFly storage sized to the workload, a backup design with an immutable tier, and the migration waves planned out. Sometimes the numbers say renew, and when they do, that's the advice you'll get. We distribute Proxmox, StoneFly and NAKIVO, our engineers do the sizing in-house, and we support the stack across Australia, New Zealand, Fiji and PNG. Resellers and MSPs quote it through the CRS partner portal, with deal registration on opportunities you bring us.