The Door Was a Download

The VDDK is the library that lets software outside the hypervisor read VMware virtual disks. That’s the whole trick behind agentless backup and agentless migration: a tool on another machine opens the disk and pulls the blocks out. One participant in the Hacker News discussion of the removal, who said elsewhere in the thread that they were running a customer’s VMware to OpenShift Virtualization migration at the time, put its value plainly: “VDDK allows you to connect and read them (in raw format, in fact) at a reasonable speed, and also understands sparseness and change block tracking.” Speed so a large estate finishes, sparseness so you copy the data and not the empty space, changed block tracking so the second pass only moves what moved.

Customers who opened support cases got an answer. Platform9 reproduced it on September 1, 2026, and micronauts published the same wording the following day: “To ensure the highest standard of security, reliability, and product features, the Virtual Disk Development Kit (VDDK) is no longer available for use or download. Broadcom continues to actively maintain a variety of APIs and SDKs to enable authorized technology alliance partners to build backup and recovery software solutions.”

Read that twice, because it says two different things. The first sentence sounds like withdrawal. The second describes a gate with authorized partners on the far side of it. Which one a paying vSphere customer is living under is unsettled in public. micronauts’ advice was to confirm entitlement with Broadcom directly, which is what you tell people when the answer varies by account. ShapeBlue reported the surrounding silence: “I have found no Broadcom statement withdrawing public access to VDDK, restricting it to selected partners, or explaining the reorganisation.” We checked the old developer portal URLs on the day this was published, and they still return 404. That’s the limit of what we can tell you first hand. We haven’t put the question to Broadcom, and we haven’t seen a customer with an active vSphere entitlement say publicly whether the file is still reachable through a support case. If that’s you, ask now rather than during the migration.

What’s settled is that nobody else can fill the hole for you. ShapeBlue again: “The VDDK licence does not permit general redistribution. No Linux distribution ships it, no container image bundles it, and no backup or migration vendor without a signed redistribution agreement can put it in their installer.” Slower routes exist. A drop-in copy someone else is allowed to hand you does not. One caveat on the sourcing: ShapeBlue, Platform9, and micronauts each sell or support alternatives to VMware, so we cite them for documentary facts you can check without trusting the reporter.

The part your contract does not cover

Lock-in usually gets discussed as two things you can read: the data format and the contract terms. This is a third thing, sitting outside both. The tool that performs the extraction is published by the party you’re extracting from, on a page you don’t control, under a licence stopping anyone else from keeping a copy for you. Unless your agreement named that SDK and committed the supplier to keeping it available, nothing you signed promised the page would load. Go and check whether yours did.

Here’s what that looks like from inside a project. A commenter in the same thread described noticing it mid-migration: “I’m in the middle of a massive Azure Local migration and noticed the VDDK was no longer available… Kinda funny because I was just telling a coworker how surprised I was that they offered it. Thankfully I saved off my copy but I have no idea how Microsoft is going to handle this going forward with Azure Migrate.”

That migration kept moving because one person happened to have the file saved. Good outcome, produced by luck, and not repeatable for the next customer.

Be careful how far this generalizes. One vendor, one library, and no measure anywhere in the reporting of how often a supplier withdraws the tooling customers use to leave. Take Broadcom’s stated reasons at face value and the effect on a customer already mid-migration still does not change. There’s a version of this that blames buyers for not spotting the dependency, and we don’t think it holds. The step was visible, but “download the SDK from the vendor whose product you already pay for” reads as ordinary on any inventory. That’s the lesson: writing the dependency down wouldn’t have flagged it. Only trying to use it would.

What to ask for, and what to rehearse

An exit clause gets written once and then filed. It says you may take your data with you. It says nothing about whether the mechanism will still exist on the day you want it, and a clause can’t notice that a page started returning 404.

So name the mechanism in the agreement, not just the right. Name the tooling your export depends on, by product and version, so it’s a defined thing rather than “commercially reasonable assistance.” Ask for notice, with a stated period, before that tooling is deprecated or moved behind a new gate. Ask for the right to retain a working copy through the term and a wind-down window, which is the ask that would have mattered here: the VDDK licence blocks redistribution, and says nothing about you keeping what you already pulled. Where the supplier won’t move on any of it, ask for escrow of the export path and accept that you’re now paying for it.

None of that helps if the tooling is already gone, which is why the second half is a rehearsal rather than an inventory. The inventory is only the setup: the binaries, the SDK versions, the API endpoints, the credentials, and who publishes each one. The rehearsal is running it. You can’t hold a parallel copy of a whole estate, so pick a representative slice, something with the awkward properties (the large volume, the odd storage backend, the workload nobody wants to touch), pull it end to end, and open the result on the destination platform. Judge it there. “The job completed” isn’t the finding. Repeat on a cadence you actually keep, because what you’re testing is the supplier’s tooling, and it changes without telling you. While you still can, do the cheap part too: micronauts told affected customers to preserve existing local copies and confirm entitlement with Broadcom, both ordinary account hygiene right up to the moment the page is gone.

When the efficient path closes, the fallbacks cost you. ShapeBlue notes Apache CloudStack supports an OVF-based route needing no VDDK, slower and heavier on storage. Agent-based migration is the other option, and the practitioner mid-migration above put their own estate’s experience at “an insane amount of privileged accounts and I would say fails for 10%+ of the VM population.” That’s one operator’s account of one environment rather than a measured rate, and it’s still the shape of the bill: speed, storage, and the number of privileged credentials you hand out to make the slow path work.

What carries over to what you are buying now

The obvious next move is to point at AI contracts and say it will happen again. We’re not going to, because the specific failure doesn’t transfer cleanly. What bit VMware customers was a proprietary binary under a no-redistribution licence sitting on the only efficient path out. AI suppliers mostly hand you exports over documented HTTP APIs, where any generic client will do and there is no artifact anyone can take away. For plain records, the transcripts and call logs and tickets, you are in a better position than VMware customers were.

One narrower thing does carry, and it’s our inference rather than anything the VMware case proves. Not every artifact you accumulate has a defined export, and the ones that don’t are the ones you paid most to create. Fine-tuned weights are the sharp case: whether you can ever hold the file you paid to train is a contract term, and if the agreement is silent, silence is the answer. Embeddings are softer and worth being precise about, because they’re a cost rather than a lock: you can usually download the vectors, and they only compare meaningfully against the model version that produced them, so a deprecation leaves you regenerating rather than stranded. Ask what regeneration costs before deciding that’s fine.

So do not ask “can we get our data out,” because every vendor says yes to that. Name each artifact you will accumulate, have them run its export while you watch, and ask what the output is worth once their service stops running.

You don’t need us for the first pass of any of this. If you have a platform team already running restore drills, put the exit rehearsal in the same rotation and read the results yourselves. Where an outside read earns its keep is the meeting where the agreement gets signed and everyone selling you something has a reason to call the export a solved problem. That filtering is part of the work we do.

Broadcom’s customers found out what their exit depended on when a page stopped loading. You can find out on a day you picked.