The Tesco vs. Broadcom case has ceased to be just a licensing dispute. It has become a signal for all infrastructure teams still relying on VMware: leaving is possible, but it doesn’t happen overnight. And the more critical the platform, the sooner you should start before the schedule forces you to.
According to documents reviewed by The Register, Tesco has decided to abandon VMware and Broadcom’s mainframe products while maintaining their legal claim in the UK. The case won’t be heard in the High Court until a window opens on 11/01/2027 and closes on 02/25/2028, but the technical work is already underway: the British retailer states they have had to seek alternatives, hire third-party support, and accept operational risks due to the rapid migration.
Computer Weekly adds that Tesco began migration efforts in April 2025, aiming to deploy an alternative to VMware across the organization by the end of 2027. The company claims that the deadline incurs costs, disruptions, and business risks—especially since they also need to replace mainframe software used in critical processes.
The issue is no longer just VMware: it’s dependency
The root of the conflict lies in a 2021 contract in which Tesco purchased perpetual licenses for VMware products, along with subscriptions and support services through 2026, with an extension option. After the Broadcom acquisition of VMware, the business model changed, and Tesco argues they could not access support services under the expected terms. Broadcom denies this interpretation.
Economic tension is evident. Tesco states that Broadcom’s April 2026 offer proposed $23.5 million (about £17.4 million) for one year of VMware Cloud Foundation 9.0 and mainframe support. According to Tesco, this represented an increase of approximately 175% over their understood licensing costs for VMware and 350% for mainframe products.
Beyond the dispute, the clear message to the market is: when a virtualization platform becomes a critical layer for years, leaving it is more than just replacing a hypervisor. You must review backups, networks, automation, monitoring, security, disaster recovery, licensing, appliances, integrations, and support.
Tesco isn’t describing an easy switch. They are saying that exit involves working “at an exceptional pace,” with third-party support, and with an alternative that, according to their documents, doesn’t directly integrate with data protection tools they already used, like Veeam and Zerto.
Low-risk migration begins well before the cutover
The technical takeaway isn’t that any company can just turn off VMware on a Friday and start on another platform Monday. The correct understanding is that exit can be executed with minimal risk if well planned.
David Carrero, co-founder of Stackscale (Aire), a company specializing in private cloud infrastructure and Proxmox, presents it from a practical perspective: migration shouldn’t be seen as just fleeing, but as a continuity project. Inventory, design, pilots, phased migrations, rollback plans, and support must be defined before moving critical workloads.
This approach shifts the conversation. It’s not about choosing Proxmox VE, Hyper-V, OpenShift Virtualization, XCP-ng, Nutanix, or another alternative based solely on licensing costs. It’s about evaluating which workloads can be migrated, what VMware features are actually used, and what dependencies have no direct equivalents.
| Area to Review | Key Question Before Migrating |
|---|---|
| Workloads | Which VMs are critical, legacy, appliances, or candidates for rebuild? |
| Network | Is NSX, microsegmentation, BGP, overlay, DFW, or label-based rules used? |
| Storage | Is vSAN, external SAN, NFS, iSCSI, Ceph, ZFS, or dedicated arrays involved? |
| Backup and DR | Does the current tool support the new platform at the same functional level? |
| Automation | Which scripts, APIs, Terraform, Ansible, or pipelines depend on vCenter? |
| Support | Who handles incidents in production? |
| Operations | Does the team master Linux, KVM, Ceph, networks, and troubleshooting for the new stack? |
The technical discussion around the case reflects these points precisely: NSX and its distributed firewall are difficult to replace one-to-one; Proxmox is attractive for many environments; Hyper-V fits where there’s already a strong Microsoft investment; Nutanix reduces initial friction but maintains vendor dependency; and XCP-ng appears as an option in niche areas. The conversation also raises real questions about SDN, microsegmentation, compatibility with Veeam/Zerto, and exit costs for each platform.
Proxmox is gaining ground, but it doesn’t automatically replace everything
Proxmox VE has become one of the most discussed alternatives because it combines KVM, LXC, software-defined storage, networking, clustering, high availability, and recovery tools within an open platform. Its official documentation presents it as a comprehensive open-source enterprise virtualization solution, with a web management interface and support for virtual machines and containers.
Moreover, Proxmox has improved in the area that customers care most about in VMware: migration. From Proxmox VE 8.2 onwards, there is an integrated importer to move VMs from VMware ESXi via the web interface and API, reducing some manual work that previously required disk conversions and manual configuration rebuilds.
Third-party support is also maturing. Veeam now includes specific documentation for Proxmox VE within Backup & Replication, with its own requirements and compatibility notes. This doesn’t mean all VMware features are replicated at the same level or that every environment can migrate unchanged, but it does eliminate one of the classic objections to Proxmox in organizations dependent on consolidated backup tools.
Caution remains necessary. Proxmox is not “free VMware.” It’s another way to run infrastructure. In VMware, many complexities are bundled inside vCenter, ESXi, vSAN, NSX, and the partner ecosystem. In Proxmox, the admin is more directly involved with Linux, KVM, Ceph, ZFS, bridges, VLANs, firewalls, and storage. This can be a huge advantage for experienced teams but also a risk if underestimated.
The real cost lies in functions taken for granted
One of the key lessons from the Tesco case is that the hypervisor doesn’t operate alone. Many companies rely not only on VMware to run VMs but on their network, ecosystem, APIs, backup tools, DR mechanisms, vendor integrations, and internal procedures.
Therefore, migration must be layered.
| VMware Function | Usual Migration Risk | How to Reduce It |
|---|---|---|
| vCenter | API-dependent automation and processes | Inventory of scripts, jobs, and tools before pilot |
| ESXi | Driver, controller, and boot differences | System or appliance-specific testing |
| vSAN | Storage model change | Proof of concept with real loads and failure testing |
| NSX | Microsegmentation and advanced troubleshooting | Redesign security; direct rule copy isn’t feasible |
| Backup | Functions not equivalent in the new platform | Validate restore processes, not just backups |
| DR | Different RPO/RTO | Documented recovery tests |
| Support | Change of contact point and SLA | Clear contracts with vendor, integrator, or MSP |
The worst mistake is thinking that migrating from VMware is just a disk conversion project. It’s an architectural initiative. Some VMs will be migrated, others rebuilt; appliances may need replacement; services can be moved into containers; and some workloads might temporarily need to stay on VMware until a solid alternative is ready.
Exiting VMware doesn’t mean falling into another trap
The natural reaction to price hikes is to seek the quickest replacement. But rushing out can lead to another lock-in. Migrating from VMware to a closed platform without evaluating future costs, support, roadmaps, compatibility, and portability can solve the 2026 problem but create a new one in 2029.
Thus, many organizations are weighing options such as: Proxmox for private cloud and open virtualization, Hyper-V or Azure Local if there’s already a strong Microsoft foundation, OpenShift Virtualization if Kubernetes is central to their strategy, Nutanix for a highly integrated HCI, or XCP-ng in environments that value an open-stack based on Xen.
There’s no one-size-fits-all answer. But there is a common rule: your choice should be driven by workload requirements, not trends. A retail edge cluster doesn’t have the same needs as a data center with NSX, an isolated public administration environment, a SaaS platform, or a small business with three hosts sharing a storage array.
Opportunity: regain control over your infrastructure
The Tesco case highlights dependency risks but also presents an opportunity. Many organizations have kept VMware for years simply because it worked, not because they reviewed whether it’s still the best fit for each workload. Broadcom’s pressure is forcing them to reassess.
A well-executed migration can cut costs, simplify environments, eliminate technical debt, enhance backups, clean up abandoned VMs, redesign networks, and better segment critical services. It can also open doors to European private cloud, bare-metal solutions, managed Proxmox, hybrid models, and more transparent architectures.
The key is not confusing urgency with improvisation. Tesco is rushing because of contractual and legal deadlines. Other companies still have room. That room should be used to inventory, run pilots, test restores, define support, and migrate in phases.
Exiting VMware is feasible. Doing so with low risk requires accepting a less glamorous reality: migration begins months before the first VM moves.
Frequently Asked Questions
What is Tesco doing with VMware?
Tesco has decided to migrate away from VMware and Broadcom’s mainframe products while maintaining a legal claim over licensing and support issues.
Why does Tesco’s case matter to the market?
Because it shows that even a large company with critical systems can initiate a VMware exit, though the process is costly, complex, and risky under pressure.
Can Proxmox replace VMware?
In many scenarios, especially for private cloud, small and medium businesses, providers, and technically capable environments, yes. But it doesn’t automatically replicate advanced features like NSX or certain DR workflows.
What is the biggest risk during migration?
Typically, it’s dependencies—network, backup, storage, automation, security, appliances, and support—not just the hypervisor itself.
How can migration risk be reduced?
Through inventory, pilots, phased approach, restoration testing, rollback planning, clear support arrangements, and a well-designed target architecture before moving critical workloads.
