VMware to Proxmox: your rollback plan expires on its own

Almost every migration plan we get asked to review has a line that says, more or less: "if it goes wrong, we go back to VMware". And that is where it stops. It does not say what exactly you go back to, or who calls it, or with which data, or —above all— until when going back is still possible. That last part expires quietly on its own while the project moves forward and everyone carries on believing they have a plan B.

This post is not about whether migrating to Proxmox is a good idea —we covered that with the numbers in hand when we described how we migrated over 500 virtual machines. It is about what happens when the migration turns out to be the easy part, and about the other half of the plan: the half you only use on the worst day, that nobody rehearses, and that evaporates without a single alarm going off.

"Rolling back" is not un-migrating

There is an asymmetry the product teaches you without ever spelling it out. Proxmox VE has shipped an import wizard for ESXi and vCenter, built into the web interface, since version 8.2, released on 24 April 2024. It is well built: it attaches to the datastore as if it were just another storage backend and pulls the whole machine across. What does not exist is the button next to it. Proxmox ships no equivalent wizard for pushing a machine back to ESXi: that means qemu-img, a hand-assembled OVF and a long stretch of work. Two years and two branches later, with 9.2 on the table, that button has still not appeared.

Which is why a real rollback —the kind that fits inside a maintenance window— consists of powering the original machine on again, still sitting switched off where it always was, on the same old vSphere. Nothing travels back. It is a simple, good plan. It depends on three things nobody writes down: that the machine still exists, that vSphere is still somewhere you would want to return to, and that the data generated in the meantime has somewhere to go. All three close on their own.

The window closes from three directions

1. The contract

Two situations get mixed up here, and they are not the same. If you still hold a perpetual licence and what has lapsed is support (SnS), Broadcom says it in its own knowledge base article with welcome clarity: "ESXi hosts and vCenter Server will continue to operate normally" and "there is no automated shutdown or disconnection mechanism triggered by the expiration of the support contract". Your plan B survives. What you lose is portal access to download "new patches, security updates, and major/minor version releases", and the ability to add new hosts or perform a major version upgrade.

If you are on a subscription —where most people already are, since perpetual licences stopped being sold— expiry is not a warning, it is an ending. The licensing guides circulating through the channel all converge on the same sentence: there is no grace period at the expiration of the subscription, and renewing late carries a surcharge — ChannelWeb put it at 20% of the first-year cost in 2025, applied back from the lapse date. We should be honest here: we have not found that figure in a public Broadcom document, only in press coverage and reseller material. It is exactly the kind of number you check in your own contract before resting a plan on top of it.

2. The hypervisor you go back to

This is the one that worries us most and shows up least in the plans. A vSphere without active SnS freezes at the last patch you were able to download. In the first month you do not notice. By the third, "we go back to VMware" already means "we go back to a hypervisor that has gone a quarter without security updates, carrying the most critical machines in the building". That is not a contingency plan: it is swapping one risk for another without having decided to. If your plan B has an expiry date, write it down — and if the date has passed, stop calling it a plan B.

3. The data delta

The third closes in hours, not months. While the imported machine is powered off or under test, rollback is free: turn one off, turn the other on, done. The moment the first user saves a file or the first order lands in the database, going back stops being "power up the old one" and becomes "power up the old one and reconcile everything written since". That change of nature happens at a specific instant, and that instant is almost never marked in the plan. It should have a time on it.

What the wizard does not take with it

The official Proxmox wiki is refreshingly blunt about the limits of the import. It is worth reading in full before you plan, because every limit on the way out is a reason to come back:

And above the whole list, the warning the wiki itself sets in bold: "make sure that the VM is only powered on in either Proxmox VE or VMware, but never at the same time in both to avoid disk corruption!". It reads as obvious on a calm Tuesday. It is not obvious at two in the morning, when something has gone wrong, everyone is in a hurry, and the temptation is to boot the VMware one "just for a second, to compare".

The panic rollback is the one that breaks things

A botched rollback does not fail on the disk: it fails on everything around the machine. You power the original on in vSphere while the new one is still up on Proxmox and, for the minutes it takes you to notice, you have two machines with the same name and the same IP, two backup agents reporting to the same backup server, two services authenticating with the same account and —this is the bad one— two processes writing to the same remote database, which lives in neither of them and therefore protects nobody. None of those four things is fixed by shutting one down afterwards.

Which is why step one of any rollback we write is not "boot the VMware one". It is shut the Proxmox one down and confirm it is down. In that order, always, with one person confirming it out loud before anyone touches anything on the other side.

The six lines we do write down

A rollback plan does not need a document. It needs six lines — and if you cannot fill one in, that gap is the finding:

When we would tell you not to migrate yet

We are not Proxmox resellers and we are not VMware resellers, and we sell licences for neither. That lets us say the obvious: there are cases where the right answer is to wait. If your renewal is far off and there is nobody lined up to operate the new hypervisor the morning after the party, migrating only brings the problem forward. If a critical workload is tied to something in vSphere you have never tested outside vSphere, that workload goes last, not first. And if you cannot write down the abort criterion from line 1, you are not ready to migrate: you are ready to run a test, which is a different thing and also fine.

There is a wider reading we already made with data a few weeks ago, when we looked at what has actually happened two years after Broadcom: what is going on is not an exodus, it is a phased reduction of dependency. And a phased migration rests precisely on being able to undo one phase without dragging the rest with it. When your rollback expires, that option is what runs out: from then on there are only waves going forward.

The line we never leave blank

In the plans we write, line 6 is never left blank: by default it carries the date of your next VMware renewal minus thirty days. There is nothing magic about the number —thirty days is roughly what it takes to organise a rollback window with real people and real out-of-hours— but it forces the conversation a month before the decision makes itself. Because that date exists whether you write it or not. If you do not set it, it gets set by a contract lapsing, a datastore running out of space, or someone who needs those hosts back. And on that day nobody tells you that you have just run out of a plan B.

Sources: ESXi/vCenter import wizard and the 8.2 release date (24 Apr 2024) — Proxmox press release; import limitations (vSAN, encrypted disks, vTPM, snapshots, networking, VirtIO on Windows) and the warning about never powering the VM on in both places — official Proxmox VE wiki; perpetual licence behaviour after SnS expiry and the literal quotes — Broadcom article 429208; absence of a subscription grace period and the late-renewal surcharge (channel reporting, not confirmed in a public Broadcom document) — ChannelWeb and reseller licensing guides. Cover image: "One way sign", Karina Carvalho, CC0 1.0, via Wikimedia Commons.