When NOT to migrate from VMware to Proxmox

Migrating from VMware to Proxmox is part of what we do. And there are cases where our answer is: not now. Not out of commercial caution — because of how the numbers come out. Here are the five cases, and along the way the two arguments that can no longer be used to argue for staying.

The conversation about whether Proxmox is "ready" is still being had, in most of the meetings we walk into, with a list of shortcomings copied from a three-year-old comparison. Part of that list expired in May this year. Part of it is exactly as valid as it ever was. Telling the two apart is half the decision, and almost nobody does it before sitting down to look at the renewal quote.

It also helps to drop the epic framing. Nearly three years after the acquisition, the actual movement of VMware customers was far smaller than the noise: we went through the figures in the exodus that wasn't. Most companies neither fled nor sat comfortably; they renegotiated and carried on. So this is not about picking a side. It is about whether the numbers work in your specific case.

Two objections that no longer hold

The first: "there is no DRS". It was true. It stopped being true on 21 May 2026, with Proxmox VE 9.2. The official press release puts it like this: "Operating in a new dynamic mode, the cluster resource scheduler (CRS) incorporates real-time node and guest resource utilization into every placement decision." And it adds that "the integrated load balancer can automatically migrate guests managed by the High Availability (HA) stack to reduce the imbalance across the cluster nodes while strictly respecting all user-defined HA rules".

Read that second sentence to the end, because the part that matters sits in the middle: guests managed by the HA stack. The balancer moves what has been registered as a high-availability resource. Machines you simply have running on a node, never declared in HA, stay where they are no matter how lopsided the cluster gets. It is consistent and it is documented; it is just not what people take away from the headline.

The second: "there is no serious third-party backup". Veeam has supported Proxmox VE since 2024, and version 13.1, released on 29 July 2026, adds replication jobs for the platform. Now the honest caveat, straight out of that release's known issues: "A replication job may fail if the source VM has disks whose size is not a multiple of the block size used by the target storage." Translated: it works, and it has edges. You plan for those beforehand; you do not discover them on cut-over weekend.

What actually changes: who makes the decisions for you

The relevant difference between the two platforms is not a feature list. It is that vSphere arrived with a pile of decisions already made — by the vendor, by the integrator, by whoever built it eight years ago — and Proxmox expects you to make them. When nobody makes them, they get made anyway: at the default value. And the defaults are written in the documentation, in plain sight.

The datacenter.cfg manual page defines the crs block. Three things in there are worth reading before you sign anything:

• ha=<basic|static|dynamic>, with "default = basic". And basic is, literally, "only the number of services is used". Out of the box, the scheduler balances by counting machines: the database that eats a whole node and the little licence-server VM count exactly the same.
• ha-auto-rebalance, with "default = 0". The automatic balancing from the headline does not switch itself on. It is a box somebody has to tick, along with its threshold (ha-auto-rebalance-threshold, default 30%) and its hysteresis (ha-auto-rebalance-hold-duration, default 3 rounds).
• ha-rebalance-on-start, with "default = 0". Not even when starting a stopped service does it look for the most suitable node, unless you ask it to.

None of this is a flaw. These are conservative values, and for a freshly built cluster they are the right ones: a balancer that starts moving machines on day one is worse than one that stays put. The problem is not the value, it is the belief. If somebody sold the migration on "it has DRS now" and nobody touched the file, the cluster is balancing by machine count and no one finds out until one node is gasping and the one beside it is half empty.

The objection still standing: the safety net that does not come fitted

There is one vSphere feature almost nobody mentions in the comparisons and that we genuinely miss: admission control. Broadcom's documentation describes the slot policy as a mechanism that works out how many machines fit if N hosts fail and that, when the current failover capacity drops below the configured one, prevents the operation. It does not warn you: it stops you. vSphere refuses to power on the machine that would break your own N-1.

Proxmox VE's high-availability documentation describes no equivalent mechanism. There are node and resource affinity rules, there are priorities, there is fencing with a watchdog. There is nothing that reserves capacity or stops you when you eat into it. In fact the documentation hands the problem straight back to you: explaining what happens when a node fails, it says the manager distributes services to the remaining nodes, that this increases the service count on those nodes, and adds "please design your cluster so that it can handle such worst case scenarios". That is an instruction for you, not a feature of the product. You can fill the cluster to the brim and everything will run beautifully until the day a node drops and you find out that what was on it does not fit on what is left. That day is not an outage: it is a failure turned into a breakdown by a design decision nobody made. The same thing we wrote about in Proxmox HA does not prevent downtime, it shortens it — except that here it does not even shorten it.

It is solvable, of course. A spreadsheet, a quarterly review and a written rule about how much RAM stays free per node. But it moves from being a guardrail in the platform to being a house discipline — and house disciplines get slack in August.

The five cases where we say no

None of the five is a Proxmox problem. One belongs to the calendar, one to your software vendor, and the other three are yours.

1. When the renewal sets the date

The most common case, and the most expensive. The renewal quote lands, the number stings, there are six weeks left and somebody decides to migrate before it expires. Migrating to a date set from outside means giving up the one thing that makes a migration safe: being able to stop it. We work with a prepared rollback and a window in which the source is still powered and bootable, and that window expires on its own, by contract and by data. If the renewal eats your window, the honest advice is to renew for the shortest term they will give you and migrate without a knife at your throat.

2. When the thing that keeps the invoices flowing has a support matrix

The ERP, the sector-specific management system, the lab software, the application that validates invoices. Many of those vendors publish a list of hypervisors they support, and that list is not negotiated on a forum or with a benchmark: you ask in writing, with the contract number in front of you, and you keep the answer. If your critical supplier replies that outside their list they help on a "best effort" basis, that is a risk decision for the board, not for the sysadmins. And it is not fixed by Proxmox performing as well or better, because the problem was never technical.

3. When nobody has done the N-1 arithmetic

The arithmetic is primary-school level and it is still almost never done. For each node, add up the memory actually assigned to the machines it has powered on — today's figure, not the last inventory's — remove your busiest node, and check whether that total fits on the ones left with headroom for the system itself. On vSphere you never had to do it, because admission control did it for you; on Proxmox you do it or nobody does. When it comes out short there are three honest ways forward: buy another node, switch something off, or write in the plan that if that particular node fails there are services that will not start, and name them. All three are legitimate. Pretending the question does not exist is not — and moving an over-provisioned cluster onto a platform that will not stop you is removing the airbag and buying a newer car.

4. When the hypervisor is not the problem

One room. Backups that have never actually been restored. A recovery time objective nobody has ever timed. Changing hypervisor fixes none of that, and it burns the budget and the hours of the person who could be fixing it. If that is where your real exposure lies, the right order is to put numbers on RTO and RPO and run a restore with a stopwatch first, and talk about platforms afterwards. Worse sales advice, better advice.

5. When there is nobody to maintain it at three in the morning

Proxmox VE is Debian underneath, which is an enormous advantage the day you need to read a log and a disadvantage the day nobody knows which one to read. The platform does not forgive a forgotten lifecycle either: the 8 branch reaches end of support at the end of this August and the package manager will not tell you on its own. If there is nobody in the company who is going to read that, and nobody contracted to read it for you, the migration produces a new platform with no owner. That is a worse starting point than an expensive but well-tended vSphere.

So when yes, then

When the three-year sum works with project hours included, not just licence prices. When there is a window in which you can stop without drama. When the critical software is confirmed in writing. When somebody — in-house or outside — owns the platform after the end-of-project photo. And when it is done in layers: a batch of low-criticality machines first, weeks of the two platforms coexisting, and the source kept powered until nobody remembers it is there.

We have worked with both platforms for many years and we sell licences for neither, which is exactly why we can afford to write this. When the answer is "stay where you are", we bill considerably less. We also sleep better.

Sources

The quotes on the CRS dynamic mode and the integrated load balancer come from Proxmox Server Solutions' official press release for Proxmox VE 9.2 (21 May 2026). The crs defaults (ha=basic, ha-auto-rebalance=0, ha-rebalance-on-start=0, threshold 30, hold duration 3) are in the datacenter.cfg(5) manual page of the Proxmox VE documentation. The sentence about designing the cluster for the worst case is from the high-availability chapter of that same documentation. The absence of a capacity-reservation mechanism is our reading of that chapter: it describes affinity rules, priorities and fencing, and describes nothing equivalent to admission control. The description of the slot policy and of it preventing the operation comes from Broadcom's technical documentation for vSphere. The Veeam 13.1 date (29 July 2026) and the replication known issue come from its official release notes; Veeam's support for Proxmox VE dates from 2024, not this year. Proxmox VE 8's end of support appears as "2026-08" in the lifecycle table of the Proxmox VE FAQ. The five cases, the order we put them in and the opinion about the defaults are ours, not the sources'.