Your VMware Exit Plan Assumed a Tool You Didn't Control

A VMware exit plan usually treats the migration tooling as a given — something you download, install, and use, not something you have to keep asking permission for. In late August, the public self-service path to the Virtual Disk Development Kit (VDDK) stopped working. No deprecation notice. No public transition announcement. A download path that migration documentation had relied on returned an error instead.

Microsoft, Red Hat, Nutanix, and Platform9 have all since surfaced the same underlying problem in their own documentation, support channels, or customer discussions: the public VDDK distribution path is no longer reliably available. The library itself has not simply ceased to exist. What changed is who can obtain it, through which channel, and under what relationship with Broadcom. That is a different problem than the one most exit plans were built to survive.

What People Thought Happened vs. What Actually Happened

The headlines settled fast on a simple read: Broadcom killed VDDK. That's not quite what the evidence supports.

What people thought happened: Broadcom removed the Virtual Disk Development Kit. The tool is gone. Migration and backup vendors that depend on it are stuck rebuilding their integration path from nothing.

What actually happened: Broadcom did not simply delete VDDK from existence. It removed the public self-service distribution path that migration tools had been instructed to use. Red Hat now says the previous public VDDK downloads are no longer active and that Red Hat cannot host or redistribute the proprietary library, directing customers to Broadcom Support instead. Nutanix users are reporting that access to specific VDDK versions now depends on the VMware entitlement attached to the Broadcom account, while Platform9 says Broadcom told affected customers that VDDK is no longer generally available for download or use and remains available to authorized technology alliance partners.

That leaves an important distinction: the dependency did not disappear. The customer's ability to obtain the dependency changed. For a migration project, those are not equivalent conditions — and that's a different problem than the one most virtualization architecture teams built their exit plans to survive.

AWS's current Application Migration Service documentation now tells customers to obtain the VDDK tarball through their Broadcom account — another indication that the distribution dependency has moved upstream into the Broadcom access relationship, not disappeared outright.

The Real Mechanism: What Your VMware Exit Plan Didn't Account For

Here's the sentence that matters more than anything else in this piece: an exit strategy built on a vendor-controlled dependency is not independent. It is conditionally permitted.

The VMware exit plan built over the last two years has usually focused on licensing math, workload compatibility, and destination platform selection — Nutanix, Proxmox, native cloud, whatever the target happens to be. All of that planning assumes the tooling required to execute the move — migration utilities, backup and replication libraries, assessment scanners — will remain obtainable and usable for the duration of the project.

VDDK exposed the gap. The dependency was already known. Migration teams weren't surprised to discover their tools used VDDK. What changed was the control boundary around obtaining it. A dependency can be fully documented and still remain outside your control. That's the failure mode this incident exposes.

Because VDDK is proprietary and subject to redistribution restrictions, software vendors have historically had to account for that dependency either through authorized distribution arrangements or by requiring customers to obtain the library separately. That second path — self-serve, developer-account-only — is what just closed. The immediate exposure falls on organizations whose migration workflow depended on the public self-service path rather than on a separately controlled distribution relationship.

This isn't the first time a VMware-adjacent control surface has turned out to sit with the vendor rather than the customer. Azure VMware Solution customers already operate below a layer they don't control — Microsoft manages the hardware, the embedded licensing, and the upgrade cadence beneath the guest layer they actually run. VDDK's access change just extends the same lesson to organizations that thought they'd fully exited: a VMware exit that depends on third-party tooling was never as self-contained as the migration checklist implied, because the checklist measured the destination platform's readiness, not the vendor's continued willingness to let the current one go. Broadcom's own litigation over migration timelines has already shown that exit timing itself can become a point of vendor leverage, separate from pricing or licensing terms — this incident extends the same category of risk into the tooling layer.

Independent isn't the same as unsupervised.

What You Control, What Broadcom Controls