When Broadcom bought VMware, Tesco moved 40,000 workloads

Tesco is moving 40,000 server workloads off VMware. The decision follows Broadcom’s acquisition of the platform and the licensing conduct that arrived with it. Frame this correctly before drawing any conclusion from it: the workloads did not stop running, and VMware did not break. The ESXi hypervisor still schedules the same virtual machines against the same physical cores it did before the platform changed ownership. Nothing in the technical layer failed. What moved was not the software. What moved was the ground the software was standing on.

Consider what the platform actually was inside an estate that size. Tesco’s virtualization layer was a single delegated dependency. vSphere managed the fleet, ESXi ran the guests, and 40,000 workloads resolved their existence through one control plane. That number is not a measure of scale for its own sake. It is a measure of concentration. When an organization consolidates 40,000 workloads onto one virtualization platform, it is not buying 40,000 independent capabilities. It is making one trust decision and replicating the consequence of that decision 40,000 times.

The system did exactly what it was built to do. Consolidation onto a trusted hypervisor is efficient, and the efficiency is real: fewer hosts, higher utilization, one operational model, one skill set, one support relationship. The concentration was never an accident or an oversight. It was the design. VMware became the substrate because a substrate is what the workload count required, and a substrate, by definition, is the thing you build on without re-deciding whether to build on it each day. The migration now underway is the system re-deciding something it was engineered never to have to re-decide.

The assumption underneath that engineering was simple and rarely stated. A dependency, once selected, remains what it was at the moment of selection. VMware under its prior ownership was a stable reference point, and the perpetual license encoded that stability as a structural fact rather than a hope. Pay once, run indefinitely. The commercial model itself asserted that trust in the platform was persistent and transferable forward through time. The system did not merely trust the technology. It trusted that the intent behind the technology would persist regardless of who came to hold it.

What virtualization consolidated, then, was not only compute. It was trust. Placing 40,000 workloads on vSphere means binding 40,000 workloads to one set of terms, one roadmap, one licensing posture, and one owner’s incentives. The system optimized for consolidation efficiency and accepted, silently, that the license entitlement was a proxy for something it could not directly hold: a durable relationship with a dependency whose character would not change. The artifact was the entitlement. The reality it stood in for was permanence. Those two things were treated as identical, because for a long time they behaved as if they were.

There was no mechanism in that trust model to detect the dependency changing character. Nothing in a perpetual license, nothing in a platform standardization decision, continuously re-validates whether the delegate still deserves the delegation. Systems built on delegated trust resolve that trust once, at the point of selection, and then inherit it forward across every subsequent state. That inheritance is the entire reason a platform decision is worth making. It is also precisely where the exposure lives. The trust was granted to VMware. It was never re-examined against what VMware would later become.

Broadcom completed its acquisition of VMware in 2023. What followed was not a change in the code path. It was a change in the terms. Perpetual licenses were withdrawn in favor of subscription bundles, standalone products were folded into packages such as VMware Cloud Foundation, and the commercial reference that Tesco’s consolidation had been built against ceased to describe reality. The same ESXi ran the same guests. The document that governed the right to run them was replaced. What changed was not attacker capability and not any operational fault in the estate. What changed was the validity of the assumption that the dependency remained as it was when it was chosen.

This is the asymmetry the migration exposes. The system depended on VMware as intended, and it had no way to notice that the intent had been eroded from underneath the platform while the platform itself stayed functionally identical. The hypervisor kept its promises. The ownership that stood behind those promises did not renew them on the terms the system had encoded. A dependency can remain technically unchanged in every observable way and still become something entirely different in the only dimension that mattered to the estate that trusted it: the terms on which its trust could be relied upon.

The system never re-evaluated. It could not, because it was never built to. It had inherited trust from a past state of VMware and carried that trust forward into a present where Broadcom set the terms, and the two states were treated as continuous because the technical layer between them was continuous. The assumption that trust in a platform is transferable across a change in who owns that platform is the assumption that no longer holds. It did not hold for Tesco, and the structure of the assumption did not fail quietly. It failed at the scale of 40,000 workloads, all at once, because that is the scale at which it had been trusted.

The estate keeps running because the reference still resolves. Inside Tesco’s virtualization layer the dependency was never held as a live, continuously checked fact. It was held as a reference: an entitlement record that named VMware, a platform standard that named vSphere, a control plane that pointed 40,000 guests at ESXi. Each of those is a pointer, and each resolves to its source by identity, not by inspection of what the source currently is. The system executed correctly the entire time. It followed the reference, found VMware where the reference said VMware would be, and ran the workloads. Nothing in that behaviour was anomalous. Resolving a reference and acting on what it returns is the behaviour the platform was built to exhibit.

What that observable behaviour never included was a step between resolving the reference and acting on it. At no observable point does the estate re-derive, from the terms themselves, whether the entitlement it holds still describes the conditions under which it may run. The reference to VMware resolved to VMware before the acquisition and resolved to VMware after it. The name did not change. ESXi did not change. The externally visible behaviour of the hypervisor scheduling guests against cores did not change. What changed sat behind the reference, in the terms attached to the source, and the terms are precisely the thing the reference does not carry. A pointer carries identity. It does not carry integrity. The estate could observe that the source was still named VMware. It had no observable means of registering that the meaning of that name had been replaced.

This is why the migration is not a response to a bypass. Nothing was circumvented, and no control was defeated. The system did exactly what reference-based execution does: it treated the source as trustworthy because the source was still named the same thing, and it never re-established whether the content behind the name, the license posture, the packaging, the roadmap, the owner’s incentives, still matched the state it had trusted at selection. Broadcom withdrew perpetual licensing and folded standalone products into VMware Cloud Foundation, and the reference kept resolving cleanly through all of it. The entitlement still named a real product. The product still ran. The identity of the source held perfectly while the integrity of what that source meant was replaced beneath it. Reference had become the substitute for validation, and substitution is not a failure. It is the mechanism operating exactly as it was engineered to operate.

The pattern is execution based on reference, not verification. A system resolves a dependency by pointing at a source, trusts the pointer, and acts on whatever the pointer returns without re-establishing that the returned state still matches the state that earned the trust in the first place. A reference is cheap to hold, stable to store, and fast to resolve. Verification is none of those things. So systems at scale hold references and call the holding trust, because performing 40,000 live validations of a dependency is not something an estate is built to do. The reference is not a shortcut around trust. In these architectures the reference is what trust physically consists of.

The same mechanism runs in software dependency resolution, and it runs there in the open. A build system requests a package by name and version, a reference into a public registry such as npm. It does not re-verify that the artifact behind that version is the artifact that existed when the reference was chosen. It fetches whatever the registry now serves at that coordinate and executes it with the trust the reference was granted. When the content behind the reference changes, when an upstream is compromised, a package is republished, ownership of a namespace moves, the build detects no bypass and raises no exception. It resolves the coordinate cleanly and runs the new content under the trust extended to the old. Identity of the source stands in for integrity of the content, and the system executes its expected behaviour against a state it never revalidated.

The surface differs and the structure does not. One reference is a semantic version string pinned in a manifest. The other is a perpetual license entitlement encoded across an estate. The pipeline that pins a version and the retailer that standardized 40,000 workloads on vSphere are running the same architecture of trust: resolve once, inherit forward, act on the name. In both, the thing that changes is never the reference and never the code path the reference drives. What changes is the state behind the reference, in the one dimension the reference was never designed to carry across time. The mechanism does not care whether the source is a registry or an owner. It only resolves the pointer.

A reference resolves once. It does not revalidate, because it was never built to hold the difference between the source it named and the source it received.

The entitlement still exists. The workloads still run. The permanence the entitlement stood for does not.

The control exists. The outcome does not.