Most infrastructure teams treat hypervisor modernization as an IT project. It's not. It's a security event.
The economics are clear—VMware licensing changes, the maturity of platforms like Nutanix AHV and Microsoft Hyper-V, and a growing range of alternative modern virtualization platforms are pushing organizations to rethink their virtualization strategy. But the window between "We've decided to modernize" and "Our environment is fully transitioned" can stretch across months, sometimes years.
During that entire period, your data protection strategy is under pressure it wasn't designed to handle.
Here's why that matters: 83% of all encrypted data in ransomware attacks lives inside virtualized architectures. Attackers target hypervisor environments that are in transition, when teams are focused on cutovers and not checking that every migrated VM still has a current, validated backup.
Unfortunately, most backup tools were built for a single-hypervisor world. When you introduce a second or third platform, coverage gaps open up—different APIs, different snapshot mechanisms, different data paths. You don't find out about those gaps when everything is working. You find out during an incident.
On-Demand Session:
Hypervisor Freedom: Unified Protection for Modern Infrastructure
Five Hypervisor Modernization Rules
None of this has to come as a surprise mid-incident. The enterprises that get through hypervisor modernization without opening a data protection blind spot follow the same five rules, regardless of which platform they're moving to. These aren't nice-to-haves for teams with time to spare—they're the minimum bar for staying protected while your environment is in motion.
1. Policy consistency can't be a manual process: Every time a VM moves to a new hypervisor, someone has to make sure it's still protected. In most environments, that's a manual step—one that is often overlooked. Your data protection platform should automatically discover new VMs and apply protection policies without requiring anyone to intervene. Consistent SLA enforcement should be available from a single control plane, across platforms, whether VMware, Nutanix, Hyper-V, Proxmox, Azure Local or others.
2. Immutability alone won't save you: Today, almost every backup vendor claims immutability. But read-only storage only stops one type of attack. Modern ransomware operators don't try to overwrite your backups, they compromise admin credentials and delete repositories, shorten retention windows, or disable protection entirely before deploying encryption. The answer isn't better immutability. It's layered security controls that don't let a single compromised credential unravel everything.
3. Your backups may already be compromised: Ransomware operators typically spend weeks inside an environment before triggering encryption. That's long enough for malware to appear across multiple backup snapshots. If your recovery process only restores the most recent backup, you may be restoring the threat alongside your data. Detection has to happen inside your backup platform—scanning for indicators of compromise before you restore, not after.
4. An untested recovery plan is not a recovery plan: Most organizations have a disaster recovery runbook. Far fewer ever actually run it. Hypervisor modernization makes this worse because a recovery plan built for one platform may not translate to another, whether you're moving to OLVM, Openstack, or any other environment. The only way to know your plan works is to test it, repeatedly, in an isolated environment that doesn't put production at risk. Compliance reports from those tests matter too, for your own confidence and for your board.
5. You need more than one way to recover: A mass-encryption event affecting hundreds of VMs requires a completely different response than a single compromised workload. Legacy tools typically offer one recovery path, a full restore that takes hours per VM. But a mature platform gives you options: spinning up a VM in minutes from backup storage, recovering files without touching the full VM, or orchestrating mass recovery across your environment in a single workflow.
Following these rules does not require advanced capabilities. Indeed, they're the baseline for any organization running virtual infrastructure in today's threat environment. The problem is that most backup platforms were architected before these requirements existed and haven't caught up.
This is the first in a series where we'll go deeper on each of these areas—how they work in practice, what to look for in a platform, and the questions worth asking your vendor.
If you want the full picture in one place, we've put together a practical guide covering all five rules in depth, including specific capabilities to evaluate and the vendor questions that matter most.
SAFE HARBOR
Any unreleased services or features referenced in this document are not currently available and may not be made generally available on time or at all, as may be determined in our sole discretion. Any such referenced services or features do not represent promises to deliver, commitments, or obligations of Rubrik, Inc. and may not be incorporated into any contract. Customers should make their purchase decisions based upon services and features that are currently generally available.