A few weeks back, buried in the filings of a £100 million High Court case between Tesco and Broadcom, there was a sentence that deserves more attention than it got.
Tesco confirmed it is migrating roughly 40,000 servers off VMware. And then, almost as an aside to the bigger licensing row, it confirmed this: the virtualisation platform it has chosen as its replacement is not compatible with the Veeam backup and Zerto replication tools it currently uses.
Forty thousand servers. A forced migration timeline. A data protection gap in the middle of it.
This is not a Tesco problem. It is the backup consequence of hypervisor dependency that almost nobody puts in the migration risk register until they are already committed to a target.
the backstory
Tesco bought perpetual VMware licences in 2021 with support through 2026 and an option to extend. After Broadcom’s acquisition, the commercial model changed, standalone support was pulled, and the extension Tesco believed it was entitled to was refused. Tesco knocked back four renewal proposals, including a $23.5 million offer for a single year of VMware Cloud Foundation 9.0. The resulting litigation, filed mid-2025, alleges breach of contract and anti-competitive behaviour.
Migration started in April 2025, targeting completion by end of 2027. The data protection incompatibility is not the headline. It is, however, the part most likely to catch other organisations on the hop.
why backup tools don’t just follow the workloads
Most enterprise backup solutions protect VMware workloads through VMware Storage API, previously known as VADP, the vSphere API for Data Protection. It is efficient, reliable, and VMware-specific. Move to a different hypervisor and that integration does not come with you.
Replication tools like Zerto are even more tightly coupled. Zerto’s journal-based continuous replication intercepts writes at the hypervisor I/O layer. That is what delivers RPOs in seconds. It used to support Hyper-V, and could even replicate from one hypervisor to the other, but HPE made the decision to drop Hyper-V and prioritise their own VME hypervisor in a colossal case of bad timing. Right now it’s effectively VMware & public cloud only as the VME support isn’t complete. Moving platform means replacing Zerto entirely for most people.
During a phased migration, VMs on the old platform have full coverage. VMs on the new one may have partial coverage, agent-only coverage, or a gap while the new integration is being bedded in. That mixed-protection state can persist for months.
For organisations with DORA, NIS2, or cyber insurance obligations, that gap has a compliance angle too. Underwriters who find at claims time that workloads were unprotected during a transition have grounds to dispute. Regulators who find business continuity arrangements lapsed during a migration have grounds to cite a breach.
where Veeam and Zerto actually stand
Tesco’s filing names Veeam specifically. The irony is that v13.1, announced at VeeamON in May 2026, introduced a Universal Hypervisor API and added Red Hat OpenShift Virtualization, Sangfor aSV, Vates XCP-ng, and Citrix XenServer, taking coverage to roughly 95% of hypervisors in active use today. All new platforms support cross-platform portable recovery from the off.
The caveat: backup and replication are not the same thing. Veeam replication coverage is far more limited, and is still hypervisor-homogeneous; VMware to VMware, Hyper-V to Hyper-V, but not across the boundary. If replication is your DR mechanism, moving hypervisor means redesigning that architecture, not just extending it.
Zerto’s position is similar. Today its supported list covers VMware, Azure, and AWS. A migration to anything outside that list means rebuilding protection relationships from scratch on the target side, if an integration exists at all.
before you pick a target
Ask these before the platform decision is made, not after:
Does your backup tool support the target hypervisor natively? If yes for VMware but unconfirmed for the target, that gap needs closing before migration starts.
Does your replication or DR tool support it? If not, the DR architecture is part of the migration scope.
What does coverage look like for workloads mid-move? The runbook needs to account for the mixed-estate period explicitly. Your leadership also needs to acept the risk of incomplete coverage during the process.
Has a cross-platform restore been tested under realistic conditions? Documented and tested are not the same thing.
the lesson
Broadcom’s conduct here has been, to put it charitably, difficult. But the lesson for everyone else is not really about Broadcom. It is about the assumption that a VMware migration means moving workloads from one platform to another and the tooling sorts itself out.
The hypervisor is the integration point for the backup API, the replication engine, the snapshot layer, and every data protection capability built on top of it. Move it without auditing those dependencies and you are not migrating — you are rebuilding. Finding that out mid-project, under time pressure, is exactly where Tesco’s filing places them.
There are cheaper ways to learn this. Ask the backup compatibility question before you pick the platform.