Multi-hypervisor is not a phase: it is what you will maintain twice

The survey headline doing the rounds this week says nine out of ten VMware customers are eyeing the exit. In that same survey there is another figure, the one its own sponsor leads with on its blog: 60% are considering a multi-hypervisor strategy. And the barriers most cited for moving are operational complexity (40%), multi-vendor management (38%) and, tied at 37%, securing the increased attack surface and team skills. All four describe the destination, not the road. Running two hypervisors at once installs them in your shop and leaves them there.

Who asked, who they asked, when, and who paid for it

The survey was run by Unisphere Research, commissioned by Rimini Street. It covers 269 executives, managers and professionals at VMware user organisations, and the fieldwork runs from December 2025 to February 2026. The Register published it on 7 October 2026, and the "eyeing the exit" of the headline is theirs rather than the survey's: what was measured is that 90% say rising licensing costs pushed them to look at alternatives. 54% cite the end of perpetual licence support, 73% put savings among their top priorities and 48% have no plans to move any assets to VMware Cloud Foundation.

Commissioning a survey does not mean faking it, but it does mean choosing what gets asked. Rimini Street sells third-party support: its business improves if you stay where you are and stop paying the vendor for maintenance. The same goes for us: we do migrations and managed services, so it suits us if you move. We sell neither VMware licences nor Proxmox subscriptions — we are resellers of neither — but the bias is there and we would rather put it on the table now than on the last page.

Eight months passed between the question and the headline

The answers are eight to ten months old. That matters because in that interval things moved that sat in the cons column when somebody filled in the form. On 2 September, Proxmox Server Solutions announced that its enterprise support goes 24/7 on 19 October — nine days from now — for Proxmox VE, Backup Server and Datacenter Manager: immediately for Premium subscriptions, with an onboarding window for Standard in the last quarter of 2026, and no SLA change for Basic. In the same release it opened a North American subsidiary and stated more than 2.3 million active Proxmox VE servers. We read that release's small print at the time, including the detail that the subsidiary's technical support remains business-hours only: what that 24/7 actually buys you.

Anyone who answered in January that "the vendor does not support us out of hours" was right then and stops being right on the 19th of this month. The pricing is public too, and goes into a spreadsheet without asking anyone for a quote: €370 per socket per year for Basic, €550 for Standard and €1,100 for Premium. And on 8 October the other piece landed: IBM handed 11:11 Systems the contracts of customers on its VMware cloud — the "hundreds" figure came from the buyer, not from IBM, and not every customer is going there — with VCF 9 as the destination. We wrote about it yesterday. The dependency, even when you stay on the same platform, does not stop at the vendor: it also sits with whoever resells it to you, and with whoever they sell your contract to next.

What genuinely does get halved

Let us start with what multi-hypervisor does well, because it is true and because it is the legitimate reason behind that 60%. The subscription bill drops if you genuinely move workloads. Concentration risk on one vendor gets spread. And the renewal negotiates differently when the alternative is already running: saying "we are evaluating options" is not the same as saying "30% of the machines already run elsewhere and the restore procedure has been tested".

Note the verb in that last sentence: run. In production, with users on it and with a backup that actually restores. An alternative platform sitting in a lab negotiates nothing, because everybody on the other side of the table can tell the two apart. We wrote it in September and we still think so: piloting an alternative is not migrating, and confusing the two is the most expensive way of not deciding.

The list of what you will have twice

This is the part that rarely makes it into the spreadsheet, because none of it is licensing and none of it arrives as an invoice. We run Proxmox VE with Ceph in production across several datacenters and we come from vSphere going back to old versions, so this list comes from there: it is what has to be done twice when both platforms coexist.

• The tested restore, not the backup. Backing up two platforms is easy; restoring a full machine on each one, timing it and writing down the result is the work. Two chains, two tests, two reports somebody has to read.
• The recovery procedure and its rehearsal. A continuity plan rehearsed on one of the two platforms is half rehearsed, and the missing half is always the one that comes up on the bad day.
• Monitoring templates and thresholds. Cluster counters do not mean the same thing on both. We use Zabbix: the threshold that means "page someone" on one platform is noise on the other, and you cannot trust that alert until you have watched a full load cycle on each platform.
• The patch calendar and the maintenance window. Two vendors with two release cadences, two windows to negotiate with the business and two conversations about why things have to reboot again.
• The inventory. We keep NetBox as our source of truth, and a source of truth with two object models behind it has twice as many places where the paperwork and reality drift apart without anyone noticing.
• Whatever lives inside the guest. Agents, drivers and provisioning templates. A Windows template prepared for one platform does not boot the same way on the other, and that does not get fixed on migration day: it gets fixed beforehand or paid for afterwards.
• Permissions and placement rules. Who can do what, and which machine may start on which node, do not translate between platforms. We went into it last week: in a migration the disks travel and the permissions do not travel. In a dual state that does not happen once: it gets maintained in both places at the same time.
• The contracts. Two support relationships, two renewals on two different dates, two people to escalate to, and a new boundary: the argument about whether the problem belongs to the hypervisor or the array, now in duplicate.
• The exposed management plane. Two administration interfaces to keep out of everyone's reach, two security bulletins to read and two affected-version lists to check against your estate. It is the barrier 37% of respondents filed under "securing the increased attack surface", and the only one on this list you do not notice until something has already happened.

At three in the morning there are not two people

Of the whole list, this is the one most often underestimated. The on-call rota does not double when you double the platform: there is still one person on duty, and now they have to know both. Not half-know: know where to look at cluster state, what that message means, what can be touched without making it worse and what cannot. That knowledge is built through repetitions, and the repetitions get split across two platforms, so you end up at half on each.

It is consistent, incidentally, with what respondents voted: 37% put team skills among the barriers. What does not add up is resolving that barrier by choosing the scenario that makes it permanent. If you are going dual, training and on-call documentation stop being an optional project line and become part of the running cost, every year.

When two hypervisors is the right answer

Two of the three situations below already appeared on the list of when not to migrate from VMware to Proxmox we published in August, and the third is new. We are repeating them because there they were reasons not to move one workload and here they are reasons to sustain two platforms at once, which is neither the same thing nor the same cost. In all three, the dual state is an architecture decision and not the residue of a migration that stalled halfway.

The first: workloads whose vendor support matrix names one platform and only one. An ERP, a clinical system, certified industrial software. Moving that saves you a licence and leaves you without the support that actually matters on the day it will not start. There the dual state gets documented in one line: which workload, which matrix says so, and with what review date.

The second: when the clock rules. If the renewal arrives before the migration does, you split by contract date rather than by technology, and you write down the date on which the dual state ends. It is a legitimate decision and it defends itself in a steering committee, as long as the date exists.

And the third: when the second platform is a second site with its own contract, its own recovery test and its own owner. There the dual state has been chosen, and it is paid for with eyes open.

When it is not

When the dual state exists to postpone the decision. It is recognisable by one specific sign: what got moved is the easy part — the stateless, the things with no support matrix, the stuff nobody claims — and the expensive part stayed where it was. That half saves nothing; it just spreads the work across two places and leaves untouched the very bill you wanted to reduce.

Nor is it when there is no exit date written down anywhere, when training for both on-call rotas is not budgeted, or when each platform does not have an owner with a name. The usual line: failure is inevitable, an outage is a design decision. A dual state with no date and no owner is a postponement with hardware inside it.

It is also worth remembering that the mass exodus never happened. We looked at it in July with the data available then: two years after Broadcom, what happened was a phased reduction in dependency, not a bloc departure. This survey, eight months later, says the same thing in different words: plenty of people eyeing the door and considerably fewer walking through it. The in-between phase is where almost everybody lives, and that is exactly why it deserves a budget of its own.

Six lines before signing anything

If your organisation is in that 60%, this fits on half a page and changes the conversation with your board more than any price comparison will:

• The date on which the dual state ends, and what happens if that date arrives and it has not.
• Which workloads do not move and why, naming the vendor document that says so.
• Who owns each platform. A name, not a department.
• Where each platform's restore procedure lives and when it was last tested.
• Which contract expires first and how long the migration that would replace it genuinely takes.
• What training is budgeted, for whom, and by what date.

If all six get answered, multi-hypervisor is a decision. If any is left blank — usually the first and the last — what you have is not a strategy: it is a state you ended up in and will be maintaining twice.

What we say when people ask us

We have migrated companies from VMware to Proxmox and we have also recommended staying on VMware when it made sense, and we say the latter just as calmly because we do not make a living from the licence. What we almost never recommend is the open-ended dual state, which happens to be the easiest option to get approved in a steering committee precisely because it forces no decision today. It is the most expensive one and the least visible on the invoice, which is the worst possible combination for an IT budget.

Sources: "Nine in 10 VMware customers eye the exit as licensing bills bite", by Lindsay Clark, published in The Register on 7 October 2026 at 13:24 UTC, which is the source of the survey authorship (Unisphere Research commissioned by Rimini Street), the sample of 269 executives and professionals at VMware user organisations, the December 2025 to February 2026 fieldwork and every percentage quoted: 90%, 54%, 73%, 60%, 48% and the four barriers, which the article lists verbatim as operational complexity (40%), multi-vendor management challenges (38%), securing the increased attack surface (37%) and team skills requirements (37%). The 60% multi-hypervisor figure is also led with by Rimini Street on its own blog about the survey. Proxmox Server Solutions GmbH press release "Proxmox expands Enterprise Support to 24/7 and launches Proxmox North America Inc.", dated 2 September 2026, for the 19 October date, the products covered, the split by subscription tier and the figure of more than 2.3 million active Proxmox VE servers. Public Proxmox VE pricing page, checked on 10 October 2026, for the per-socket per-year rates. "IBM offloads 'hundreds' of its cloudy VMware customers", by Simon Sharwood, The Register, 8 October 2026, for the transfer of contracts to 11:11 Systems, the "hundreds" figure attributed to the buyer, and VCF 9 as the destination. Everything we state about our own operation — Proxmox VE with Ceph in production across several datacenters, prior vSphere experience, Zabbix for monitoring, NetBox as inventory, backups with Veeam and Proxmox Backup Server — is ours, and includes no customer data. We have put no savings figures from any specific migration in here because the ones we have belong to customers and are not public.