Something significant is happening across enterprise IT right now — and I do not think it has been fully reckoned with yet. More than 5,000 organizations are actively evaluating or executing a migration away from VMware. The Broadcom acquisition changed the economics of VMware dramatically and abruptly. Licensing costs surged. Bundling decisions eliminated flexibility. Organizations that had built their entire virtualization strategy around VMware — in some cases for twenty years — suddenly found themselves with an urgent mandate to find an alternative.
That is a massive shift. And it is not happening in a vacuum. As these organizations go looking for a new virtualization home, they are landing on platforms like Red Hat OpenShift Virtualization, which is powered by KubeVirt. And that transition is exposing a problem that nobody adequately planned for: the disaster recovery tooling they relied on in the VMware world does not exist in the open infrastructure world. Not yet. Not in the form they need.
That gap is the reason we built Trilio Site Recovery. And in this post, I want to explain the full picture — the VMware migration wave, the DR void it created, why incumbent storage vendors cannot fill that void, and why the answer has to be a native, storage-agnostic solution built on open standards.
The VMware Exodus Is Real — and It Is Accelerating
Let me put some context around what 5,000+ organizations migrating away from VMware actually means in practice. These are not small businesses experimenting with new technology. Many are large enterprises with thousands of virtual machines, complex networking dependencies, decades of accumulated workloads, and operational processes deeply integrated with VMware’s tooling ecosystem. VMware vSphere, vSAN, NSX, and Site Recovery Manager were not just products to these organizations — they were the fabric of their infrastructure.
When Broadcom completed its acquisition of VMware and restructured the licensing model, the reaction from the customer base was swift and, in many cases, severe. Organizations that had budgeted for a known VMware cost suddenly faced dramatically higher renewal quotes, often with the flexibility of à la carte licensing replaced by mandatory bundles. For many, the total cost of staying on VMware became untenable.
The migration conversations I am having today are unlike any I have seen in my career. These are not organizations exploring an option — they are organizations executing a plan. They have made the decision. The question is no longer whether to leave VMware. The question is how to land safely on the other side.
“The question is no longer whether to leave VMware. It is how to land safely on the other side — with your workloads protected and your operations intact.”
Why OpenShift Virtualization Is Becoming the Landing Zone of Choice
Of all the destinations organizations are considering for their VM workloads, Red Hat OpenShift Virtualization has emerged as the most compelling for enterprises that want more than a like-for-like VMware replacement. And the reason is important: OpenShift Virtualization, built on KubeVirt, does not just give you a place to run your VMs. It gives you a modern infrastructure platform that fundamentally changes what is possible over time.
Here is what that means in practice. When you move your VM workloads onto OpenShift Virtualization, you are placing them on the same Kubernetes-based platform that runs your containerized applications. That unified platform is the foundation for everything you want to do next — reducing infrastructure cost through consolidation, automating operations through Kubernetes-native tooling, and beginning the journey to containerize applications and build scalable microservices. You are not just escaping VMware’s cost burden. You are positioning your organization for the next decade of infrastructure evolution.
The KubeVirt ecosystem that underpins OpenShift Virtualization is built on open standards, open source, and a community of vendors who understand the KVM and Linux-native world deeply. Red Hat has invested enormously in making OpenShift Virtualization enterprise-ready. The ecosystem around it — storage, networking, security, observability — is maturing rapidly. For organizations making this transition, the key is to choose vendors and tools that genuinely understand this ecosystem, not legacy vendors trying to extend their VMware integrations to a platform they were not designed for.
The DR Gap That Is Stalling Migrations
Here is where I want to be direct about a problem I encounter in almost every enterprise migration conversation. Organizations moving from VMware to OpenShift Virtualization are doing their due diligence. They are evaluating compute, networking, storage, security, and observability. They are building migration plans. And then someone asks: “What is our disaster recovery story on OpenShift Virtualization?”
In the VMware world, the answer to that question was VMware Site Recovery Manager. SRM was deeply integrated, widely understood, and broadly trusted. It was not perfect, but it was a known quantity. Enterprise DR teams built their runbooks, their RTO and RPO commitments, and their compliance postures around it. For many organizations, SRM was table stakes — a requirement, not a choice.
When those organizations look for the equivalent in the open infrastructure world, they find a gap. There is no native Site Recovery Manager equivalent for OpenShift Virtualization. There is no broadly adopted, enterprise-ready DR orchestration tool that does for KubeVirt what SRM did for vSphere. The DR tooling that exists in the open infrastructure ecosystem is either immature, storage-specific, or requires significant custom scripting to approach production-readiness.
That gap is not an inconvenience. It is a blocker. I have watched organizations delay their VMware migration timelines — sometimes by quarters — because they cannot get a satisfactory answer to the disaster recovery question. They are willing to accept the cost and complexity of the migration. They are not willing to accept the risk of running mission-critical workloads on a platform with no tested DR strategy. And they should not have to.
“The absence of a true DR solution for open infrastructure is not just a gap — it is actively stalling migrations that organizations need to complete.”
Why Storage Vendors Cannot Fill This Gap
The natural response from the market — and from storage vendors in particular — has been to offer DR as a feature of their storage platform. If you are running our storage, you can use our replication and failover capabilities. On the surface, this sounds reasonable. In practice, it replicates the exact problem organizations are trying to escape when they leave VMware.
Storage vendor DR solutions are by definition homogeneous. They require the same storage platform at your primary and recovery sites. They are scripted rather than orchestrated — meaning your platform team is responsible for encoding recovery logic that should be automated. They store your backup data in proprietary formats that are inaccessible without an active license and incompatible with tooling outside that vendor’s ecosystem. And when your infrastructure changes — as it inevitably will — your DR strategy changes with it, often requiring significant re-architecture.
For organizations that just spent eighteen months and significant capital escaping VMware lock-in, trading that dependency for a storage vendor’s proprietary DR ecosystem is not a solution. It is a lateral move. The underlying problem — a DR strategy that constrains your infrastructure freedom rather than protecting it — remains exactly the same.
Working effectively in the OpenShift Virtualization and KubeVirt ecosystem also requires deep familiarity with KVM, Linux-native virtualization, open source tooling, and the Red Hat partner ecosystem. Legacy vendors retrofitting their VMware DR integrations to OpenShift are operating outside their native domain. The seams show. The edge cases compound. The enterprise DR reliability that organizations need does not emerge from bolted-on integrations.
Trilio Site Recovery: Native, Storage-Agnostic, and Built for This Moment
Trilio Site Recovery is the answer to the question that is stalling VMware migrations. It is a native disaster recovery solution for Kubernetes and OpenShift Virtualization environments — purpose-built for the open infrastructure world, not adapted from the VMware world. And it is differentiated from storage vendor alternatives in ways that matter fundamentally for organizations making this transition.
Storage agnosticism is the foundation. Trilio Site Recovery operates at the Kubernetes and application layer, not the storage layer. It does not care whether you are running Ceph, NetApp, Pure Storage, Portworx, or a public cloud block storage service. It works across all of them, at your primary site, at your recovery site, and across any combination. That means your DR strategy does not constrain your storage decisions — now or in the future. You can migrate storage platforms, adopt new cloud services, expand to new regions, and your recovery plans remain intact.
The recovery orchestration is native and intelligent. Trilio Site Recovery understands Kubernetes and OpenShift Virtualization constructs natively — namespaces, PersistentVolumes, Helm releases, KubeVirt VMs, ConfigMaps, network policies. It knows the dependency relationships between components of a complex application and orchestrates recovery in the correct order automatically. There are no scripts to maintain, no runbooks to execute manually, no tribal knowledge required. This is the SRM-equivalent experience that the open infrastructure world has been missing.
Policy-driven recovery plans let you define per-application RTO and RPO objectives. Automated failover can be triggered by health thresholds or with a single operator action. And non-disruptive DR testing — one of the most important capabilities we offer — lets you validate your full recovery plan in an isolated environment without touching production. You can run DR tests monthly, after every significant infrastructure change, or ahead of compliance audits, with confidence that what you are testing reflects your actual recovery capability.
“Trilio Site Recovery gives organizations the SRM-equivalent DR experience they are accustomed to — native to the open infrastructure world they are moving into.”
Open Formats, No Vendor Lock-In, and the Right to Own Your Data
There is one more dimension of Trilio’s approach that I want to highlight, because it speaks directly to the concerns of organizations that just lived through the consequences of vendor lock-in. Trilio stores backup data in open, non-proprietary formats. For OpenShift Virtualization VM workloads, that means QCOW2 — the Linux-native, open-standard disk image format that is universally supported across virtualization platforms, cloud providers, and tooling ecosystems.
QCOW2 is not a Trilio format. It is an open industry standard, native to the Linux and KVM world that OpenShift Virtualization is built on. Your backup files are accessible, readable, and restorable using any compatible tooling — with or without a Trilio license, now and indefinitely. You will never find yourself in a position where accessing your own backup data requires a vendor relationship you no longer have, or a license you no longer want to pay for.
This matters because the industry is not just moving toward open source — it is moving toward open standards that guarantee interoperability across the entire infrastructure ecosystem. Open formats like QCOW2 work seamlessly with public cloud import and export workflows, with the growing ecosystem of KVM-native tooling, and with the infrastructure services that will emerge over the next decade. When your backup data is stored in an open standard, you are not just protected against your current vendor’s decisions. You are positioned to take advantage of whatever the infrastructure landscape becomes.
Organizations that choose Trilio are genuinely future-proofing their DR strategy. They are free to make infrastructure changes as their needs evolve — different storage platforms, different cloud providers, different Kubernetes distributions — without their DR architecture becoming a constraint. That freedom is the difference between a DR solution and a DR dependency.
The Moment Is Now
The VMware migration wave is not slowing down. The organizations executing these migrations are sophisticated, they are moving quickly, and they are not willing to accept a DR gap as a permanent condition. They left VMware partly to escape lock-in and cost burden. They are not going to accept a new form of lock-in from a storage vendor’s proprietary DR solution.
What they need — what the open infrastructure ecosystem has needed — is a native, storage-agnostic, enterprise-ready disaster recovery solution that matches the SRM experience they are leaving behind, built on the open standards and open source foundations that define the world they are moving into. Trilio Site Recovery is that solution.
It is available today.. If your organization is navigating a VMware migration and the DR question is still open, I want to have that conversation. Reach out at trilio.io or connect with me directly on LinkedIn.
The gap is real. The demand is there. And now, so is the solution.
