For the best part of two decades, picking a hypervisor was the easy bit. VMware was the default, and every backup and replication vendor built their integration around it first. VADP, journal-based CDP, tag-driven job scoping… The whole ecosystem grew up assuming vSphere underneath.
That assumption is gone. Broadcom’s licensing changes knocked the certainty out of the market, and the result isn’t a tidy migration from one platform to another. It’s fragmentation. Hyper-V, Proxmox, Nutanix AHV, XCP-ng, OpenShift Virtualization, Sangfor aSV estates are splitting across multiple hypervisors, sometimes within the same organisation, sometimes within the same rack. I covered the sharp end of this a few weeks back with the Tesco filing: 40,000 servers moving off VMware, and a backup and replication stack that doesn’t follow them.
the mistake is thinking of this as a one-off decision
Most organisations are treating the hypervisor question as a single migration project with an end date. Pick the target, move the workloads, done. That’s the wrong frame for backup and DR specifically, because of one detail that gets lost in the platform debate: your data protection software has to survive longer than any one piece of compute infrastructure underneath it.
Long-term retention requirements don’t care what hypervisor you were running when the backup was taken. A seven-year retention policy for regulatory or legal reasons will span at least one hypervisor refresh, quite possibly two. Compliance obligations under DORA and NIS2 don’t reset because you swapped from ESXi to Hyper-V. The backup platform is the constant. The compute layer underneath it is the thing that changes.
Put simply: you’ll replace your hypervisor more than once during the life of a single retention policy. Choose backup and DR tooling as if that’s a certainty, not a risk.
what this means in practice
Native, broad hypervisor support beats deep integration with one. A platform that only does VMware brilliantly is a liability the moment your estate stops being VMware-only. This is where it’s worth giving credit where it’s due – Veeam has clearly clocked this shift and has been putting real engineering effort into closing the gap rather than hoping the market stays still. Version 13.1, announced at VeeamON in May, introduced a Universal Hypervisor API and added native support for Red Hat OpenShift Virtualization, Sangfor aSV, Vates XCP-ng, and Citrix XenServer on top of existing VMware and Hyper-V coverage. That takes them to something like 95% of hypervisors in active use, with cross-platform portable recovery built in from the off, meaning a VM protected on one platform can genuinely be restored onto another, not just backed up on both in isolation. That’s the direction every vendor in this space needs to be moving, and it’s a meaningfully different starting position for anyone planning a hypervisor move today versus twelve months ago.
Vendor lock-in at the hypervisor layer becomes lock-in at the backup layer if you’re not careful. This is the expensive lesson Tesco are learning. Choosing a backup platform because it’s the best VMware tool available, without checking what happens if VMware isn’t the answer in three years, is how organisations end up rebuilding their entire data protection stack mid-migration, under time pressure, with leadership only finding out about the gap once it’s already a problem.
the retention timeline is the argument
This is the part that doesn’t get enough airtime in the hypervisor debate. Nobody selects a backup platform with a seven-year retention in mind. But the retention data doesn’t move when the compute does. It has to be restorable regardless of what’s running underneath it by the time someone actually needs it back. Again, this is where Veeam are leading the pack.
If there’s one lesson from watching the VMware exodus play out this year, it’s this: don’t pick backup and DR tooling to match your current hypervisor. Pick it because it’ll still be doing its job long after that hypervisor has been and gone.