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 You Control Broadcom Controls Target platform VDDK distribution Migration schedule Access requirements Project budget Availability of the required library Destination architecture Compatibility path Internal staffing Whether the dependency remains obtainable The last row is the one that changes the calculus. Every other row in the left column assumes the tool required to execute it stays reachable on the terms you planned around. The moment that stops being true, staffing plans, migration schedules, and budget assumptions all inherit a dependency they were never built to account for — and nobody put a line item on the project plan for "confirm the vendor still wants us to leave." For teams building or revisiting a VMware Migration Strategy, this is now a line item for any VMware exit plan: confirm every migration, backup, and replication tool in the plan against its actual distribution mechanism, not just its licensing terms. A tool that's free today can become entitlement-gated tomorrow without a single clause changing. Five rows. One of them just moved columns. The Pattern This Extends Rack2Cloud's Dependency Visibility Boundary framework (#143) names a related but distinct failure: the point where an organization can no longer reconstruct its true dependency surface from documentation alone — where what you depend on has become invisible. VDDK's access change is a different failure mode. Nobody's dependency map was wrong here. Everyone building a VMware exit plan this year already knew they depended on migration tooling built on VDDK. What changed wasn't visibility. It was permission — the terms under which a known, already-mapped dependency stays usable shifted without notice, mid-project. This isn't the first time a VMware exit's declared success has measured the wrong thing. Audit rights have already been shown to survive an exit on their own clock, and a migration dashboard has already been shown to prove less than it claims. Access control is simply the newest instance of the same pattern: the exit isn't finished just because the visible metrics say so. That's a distinct enough mechanism that it doesn't fold cleanly into an existing framework, and one vendor action isn't enough evidence to mint a new one — Rack2Cloud's own bar for that requires recurrence across independent examples, not a single incident. It's a candidate worth watching, not a framework worth naming yet: does the same access-gating pattern show up in cloud egress tooling, SaaS export APIs, identity migration utilities, or AI model portability? If it does, this stops being a VMware story and starts being an infrastructure-wide one. 📥 Download the Architecture Carousel — VMware Exit Plan: The Dependency You Don't Control A concise visual breakdown of how vendor-controlled migration tooling can create a circular dependency inside an otherwise well-defined VMware exit strategy. Download the PDF (7 slides) Architect's Verdict An exit strategy built on a vendor-controlled dependency is not independent. It is conditionally permitted — and conditional permission is not something you can put a firm date on in a project plan. The real problem isn't Broadcom, and it isn't even VDDK specifically. The VMware exit plan still tends to measure readiness by cost model, workload compatibility, and destination platform — and then stop there. It rarely asks who has to keep saying yes to the tooling required to execute the migration itself. That is the missing control boundary. A tool can be documented, tested, budgeted, and working perfectly in the pilot — and still remain outside the organization's control. If access to that tool depends on a vendor relationship that the migration is supposed to eliminate, the exit plan contains a circular dependency. The lesson is straightforward: map not only what your migration depends on, but who controls your ability to obtain and continue using each dependency. That control boundary belongs in the exit plan before the migration begins. Originally published at rack2cloud.com