When one of the world’s largest grocery retailers moves to migrate 40,000 server workloads off its hypervisor stack while suing its software vendor for more than £100 million, enterprise IT takes notice.
According to Tesco’s High Court filing, the retailer purchased perpetual licenses for VMware vSphere Foundation and Cloud Foundation in January 2021, with support intended to run through January 2026 and an option to extend. After Broadcom completed its acquisition of VMware in late 2023, Tesco says it was pushed toward subscription-only bundles priced far above the original agreement – court filings put the increase at more than 170%, with a replacement package priced roughly £15 million above the licenses Tesco says it already owns outright. Broadcom disputes Tesco’s characterization, and the case is still working through the UK High Court.
“Faced with Broadcom’s abusive conduct, and given the criticality of virtualization… Tesco has been forced to incur material costs to procure alternative solutions.” — Tesco High Court filing
Whatever the court decides, the exposure is already real: a corporate acquisition changed the terms of a five-year-old contract, and a retailer with no interest in a hypervisor migration is now running one at “exceptional pace.” The question worth asking before you’re in the same position: how much of your infrastructure would move with you if your hypervisor vendor changed the deal tomorrow?
For many IT teams, the honest answer is “the hardware, and not much else.” The storage underneath stays put – or it should.
Where the Storage Layer Adds Real Exposure
For years, enterprise IT strategy ran on a simple assumption: buy perpetual licenses, lock in predictable support, run the platform until hardware end-of-life. That assumption breaks the moment ownership changes hands, and Tesco isn’t the first company to learn it the hard way – Broadcom’s post-acquisition licensing changes have pushed several large customers toward subscription bundles they didn’t ask for and don’t fully use.
Storage compounds the problem when it’s built on hypervisor-proprietary foundations:
- Proprietary Hyperconverged formats. Hyperconverged storage like VMware vSAN is locked into a vendor-specific disk format that turns a hypervisor exit into stranded hardware – without the hypervisor’s proprietary layer, there’s no way to repurpose the local disks.
- Vendor-specific API dependency. Automations or integrations built against a hypervisor’s proprietary storage APIs have to be rewritten from scratch the moment the platform underneath it changes.
- Unsupported hardware. SAN arrays qualified and purchased for one hypervisor might not carry over cleanly to a platform change forced by a licensing dispute. Even though the hardware itself still works fine, if the protocols used or the software itself isn’t vetted by the storage provider, an expensive support contract might become “best effort” – or nothing at all.
None of that is a storage problem exactly – it’s what happens when the storage layer inherits the hypervisor’s lock-in instead of standing apart from it. An open storage foundation doesn’t remove hypervisor risk. It removes hypervisor dependency from the storage decision: the same NFS export or iSCSI LUN serving a vSphere cluster today can serve Proxmox or KVM tomorrow, without a forklift replatform of the data underneath it.
Not Migrating? That’s Fine Too.
Not everyone reading this is planning an exit, and that’s fine. If VMware is still the right call for your business, or you’re contractually locked in until a renewal window opens, TrueNAS earns its place under vSphere too. VAAI offload moves block zeroing, full-copy cloning, and space reclamation off the ESXi host and onto the array itself, for both iSCSI and Fibre Channel – and the TrueNAS Enterprise vCenter plugin brings datastore and snapshot management into the same console you’re already running, so day-to-day storage work doesn’t mean a second tool and a second login. Migration flexibility and native VMware integration aren’t opposing bets; TrueNAS backs both, depending on what your business needs this year versus the next.
Decoupling Compute from Storage
Migrating tens of thousands of production VMs across hypervisor boundaries — vSphere to Proxmox VE, KVM, Hyper-V, or cloud-native platforms — is a genuinely hard technical problem. The part that makes it survivable is keeping storage protocol support broad enough that the hypervisor underneath can change without a second migration on the storage side.
TrueNAS Enterprise connects to virtually any enterprise hypervisor because it’s built on open, time-tested protocols instead of vendor-gated ones.
Block storage is where protocol choice matters most, since it usually carries the performance-sensitive workloads. iSCSI gives raw LUN access with native OS-level support across ESXi, Proxmox, Hyper-V, KVM, and Xen – no proprietary initiator required. Fibre Channel on TrueNAS Enterprise lets you keep an existing FC fabric investment instead of stranding it during a platform change. NVMe-oF goes further, delivering near-direct-attached NVMe speed over fabric for I/O-intensive workloads that can’t absorb a performance regression mid-migration, with connectivity spanning modern KVM, Linux, and VMware vSphere (support coming in TrueNAS 26) alike.
Shared file storage covers the rest of the datastore traffic. NFS (v3/v4) mounts across ESXi, Proxmox, KVM, and Nutanix AHV without per-host proprietary drivers – useful when two hypervisor pools are running side by side mid-migration. SMB/CIFS fills the same role for Windows-centric stacks, with native Active Directory integration and ACL support for Hyper-V and Windows Server clusters.
Object storage rounds it out as a staging layer rather than a datastore protocol: S3-compatible access gives containerized workloads, backup images, and cloud migrations a landing zone that doesn’t depend on any hypervisor at all.
The practical payoff: a single TrueNAS Enterprise system can present NFS, iSCSI or Fibre Channel datastores to an existing vSphere cluster while simultaneously serving NFS, iSCSI, or NVMe-oF to a new Proxmox or KVM environment, from the same underlying pool. Protocol choice becomes an operational decision you can revisit, not a platform commitment you’re stuck with.
OpenZFS: The Constant Underneath
Underneath every one of those protocols sits the OpenZFS filesystem, which is what actually makes the “storage as the constant” argument hold up rather than just sound good:
- Copy-on-write snapshots. Instantaneous, space-efficient snapshots of entire VM datastores before a workload conversion. If a migration attempt fails, rollback takes seconds, not a restore-from-backup afternoon.
- Block-level replication. Production datastores can replicate to a new hypervisor’s staging storage in the background, without touching live copies.
- Inline compression. Every TrueNAS system includes Inline adaptive compression to reduce the storage footprint of running two virtualization environments side by side – a real cost line item when you’re staging a destination cluster before you can decommission the source.
- Data deduplication. Available on TrueNAS Enterprise systems with a Gold-tier support contract, data deduplication can significantly reduce the storage footprint of virtualization systems that rely heavily on “template” style deployments. Deduplication can be provided on both all-flash and hybrid TrueNAS Enterprise systems, with an optional capacity guarantee available.
If you’re staging a destination environment on lower-cost capacity drives while the active migration runs on flash, that’s the same tiering logic behind why hybrid storage is having a moment again – match the media to the job instead of provisioning everything for peak load on day one.
Practical Migration Patterns with TrueNAS Enterprise
Running a dual-stack transition – legacy hypervisor and destination platform live at the same time – is where most of the migration risk actually lives. Three patterns TrueNAS Enterprise supports directly:
Simultaneous multi-hypervisor datastores. One TrueNAS Enterprise system exports storage across multiple protocols at once, so legacy and destination hypervisors don’t need separate storage pools during the transition. One array, two protocol targets, no extra hardware required.
Staged, incremental data sync. ZFS replication clones and seeds multi-terabyte VM datastores to the destination hardware over the network. Once the initial sync completes, incremental syncs keep the destination current, which is what turns a cutover window from hours into minutes.
DR continuity through the transition. Hypervisor changes usually break hypervisor-native backup chains right when you can least afford a coverage gap. Snapshot-based replication at the storage layer keeps DR SLAs intact independently of whatever backup tooling the old or new hypervisor uses.
Where This Leaves You
The Tesco case is still in litigation, and the final numbers may change. What won’t change is the underlying lesson: a hypervisor contract can be renegotiated out from under you by an acquisition you had no say in. Storage doesn’t have to be renegotiated with it.
Talk to a TrueNAS representative today about a hypervisor-agnostic storage design for your next platform migration – before you’re planning one under a deadline you didn’t choose.
FAQ
Do I need to change my storage when I change hypervisors?
No, if the storage layer is already protocol-agnostic. TrueNAS Enterprise serves iSCSI, Fibre Channel, NFS, NVMe-oF, SMB, and S3-compatible access from the same system, so a hypervisor migration doesn’t require a parallel storage migration.
Can TrueNAS serve VMware and Proxmox (or another hypervisor) from the same array during a migration?
Yes. A single TrueNAS Enterprise system can present datastores to a legacy vSphere cluster and a destination Proxmox or KVM cluster simultaneously, which is what makes a staged, incremental cutover possible instead of a hard forklift switch.
What happens if a VM migration attempt fails partway through?
With TrueNAS, you can take a copy-on-write snapshot of the datastore before a workload conversion starts, so a failed migration can be rolled back in seconds instead of triggering a full restore from backup. The rollback isn’t protocol-specific – it works the same whether the datastore is iSCSI, NFS, or any other supported protocol.
Does moving off VMware put disaster recovery at risk during the transition?
Not if DR is handled at the storage layer. Snapshot-based replication in TrueNAS keeps DR SLAs active independently of hypervisor-native backup tools, so a mid-migration outage isn’t also a DR outage.