On August 25, a file quietly stopped existing.
If you run VMware, you have probably never heard of the Virtual Disk Development Kit. There is no reason you would have. It is a small library that lets other software read the contents of a virtual machine's disk. It is not a product anybody buys. It is plumbing, and its main job for the last decade has been letting tools copy your virtual machines somewhere else.
Broadcom removed public access to it without an announcement. As of this writing, in early September 2026, the download pages still return errors. There was no deprecation notice, no archive, and no stated way for a customer to obtain it. When people asked, support told them the library is no longer available for use or download, and that access now runs through authorized technology alliance partners. The official reason given was to ensure the highest standard of security, reliability, and product features.
That reason does not explain anything. Taking a library away does not improve the security of the thing that no longer has the library. But the reason is not the interesting part. What broke is the interesting part.
Look at what stopped working
The tools that immediately broke were Microsoft's agentless Azure migration path, Red Hat's Migration Toolkit for Virtualization, Nutanix Move, and the open source conversion utilities that most do-it-yourself migrations rely on.
Every one of those has something in common. They all point away from VMware.
Meanwhile, most backup software kept running. The large backup vendors have formal partner relationships, which means they have someone to call. So the disruption did not land evenly. It landed almost entirely on organizations in the middle of leaving, and it landed hardest on the small end of the market. A large vendor has an account manager. A three person migration shop, or a company converting its own workloads with its own staff, got a support forum thread and a broken link.
There is one more detail that matters. The license on that library never permitted redistribution. So nobody can legally mirror it, package it, or pass it along to fill the gap. A single web address turned out to be a hard requirement for an entire ecosystem of third party software, and the company that controls that address is the one you were trying to leave.
The part that is not about VMware
It would be easy to read this as a VMware story, get annoyed at Broadcom, and move on. That would be a waste of a genuinely useful lesson.
When you selected your current platforms, you almost certainly evaluated two numbers. What does it cost to buy, and what does it cost to run. Those are the numbers on every quote and in every comparison. They are the numbers we all argue about.
Almost nobody evaluates the third number, which is what it costs to leave.
That number is real. You will eventually pay it, because no platform is forever. And it has two properties that make it dangerous. You pay it at the worst possible moment, usually when a renewal price or an acquisition has already forced your hand. And you do not get to know it in advance, because the vendor sets it after you have already committed.
This shape is not unique to virtualization. We see it in cloud storage where getting data out costs more than putting it in. We see it in phone systems where the configuration cannot be exported, and in management platforms with no real way to extract your own ticket history.
We will also be honest that we sometimes recommend platforms with this property, and backup is the clearest example. Most enterprise backup products write to a proprietary format that only their own software can read, which means your historical restores depend on that vendor continuing to exist and you continuing to pay them. We still recommend those products, because what you get in exchange is deduplication, encryption, and recovery speed that open formats do not match, and because losing a restore is a worse outcome than being tied to a vendor.
That is the actual point. The goal is not to avoid every dependency, which is impossible and would leave you running worse systems. The goal is to know which ones you have accepted and why, so that none of them surprise you. A tradeoff you chose deliberately is a business decision. The same tradeoff discovered during a renewal negotiation is an emergency.
Five questions worth asking before you sign
You do not need to become paranoid about vendors. You need to ask a handful of questions while you still have leverage, which is before the purchase rather than after.
How does my data get out of this, specifically? Not whether it can in principle. What is the actual tool or process, by name.
Who controls that tool? If the answer is the vendor you would be leaving, you do not have an exit. You have permission to exit, which can be revoked.
Can anything else read the export? A documented, open format is an asset you keep. A proprietary one is a dependency, which may still be the right call, but you should be making that call on purpose.
What would it cost in hours, not dollars? Migration budgets die on labor, not licensing. Someone has to move every workload and test every application afterward.
When did we last actually test it? An exit path you have never run is a theory. Theories fail at the worst time.
On intent
For the record, I do not think you need to believe Broadcom did this specifically to trap customers. They have been moving downloads behind entitlement portals across their whole catalog, and a lot of that has been handled badly enough to create problems for Broadcom too.
But intent does not change your exposure. The effect is that leaving is now harder, slower, and dependent on the goodwill of the vendor you are leaving. That is true whether it was strategy or sloppiness, and it is the only part that shows up on your side of the ledger.
Where we come in
We cannot tell you which vendor does something like this next. Nobody can.
What we can do is make sure you know your exit cost on the platforms you depend on, before it becomes urgent. When we recommend a system, we will tell you what leaving it looks like, including the cases where the honest answer is that leaving would be painful and we think it is still the right choice.
If you are not sure what it would take to get your data off your current virtualization, backup, or phone platform, that is worth finding out on a calm afternoon rather than during a renewal negotiation. Reach out and we will map it with you.
Want this reviewed against your environment?
We'll walk your stack with you and tell you plainly what we'd change first.