VMware VDDK downloads removed: what it means for your migration
Broadcom has withdrawn the public downloads of the VMware Virtual Disk Development Kit, the library many migration and backup tools use to read VMware disks. You can still leave VMware. What changes is which route you take, and what you have to check before the project depends on it.
You can still migrate away from VMware. The effect of the VDDK change depends on how your tools access the virtual disks, how their dependencies are supplied, and the specific migration you are planning. For an infrastructure team the immediate job is to check the proposed route before it becomes a dependency in the project schedule. A destination can be a good fit while the assumed way of getting there needs changing.
This guide explains what has changed, where Veeam and other tools can help, and how to choose an approach around your workloads, downtime and budget. The Migration Route Finder part way down turns your answers into a shortlist of routes to investigate and the checks that matter for each. It asks for no email address.
What has changed with VMware VDDK?
VDDK is software that other applications use to read and write VMware virtual disks. It sits underneath some backup and migration workflows, and most customers only meet it as a dependency of another product: a migration tool asks for it, or a backup proxy is built with it.
The public download pages stopped resolving in late August 2026, without an announcement. Trade reporting places the first documented failures around 25 August, with vendors and customers reporting errors even when signed in to a Broadcom account. Virtualization Howto, 7 September 2026
In a statement reported on 10 September 2026, VMware said access remains available through selected Technology Alliance Partners for backup and recovery, which it described as the licensed use case. It also said VDDK is covered by its own developer licence and is not an entitlement that comes with a Broadcom software purchase. VMware's statement, reported by The Register
The practical distinction is between a product that supplies its supported dependencies and a workflow that tells you to download VDDK yourself. A missing download interrupts the second kind even when the migration application itself is unchanged. That is why the same event is a non issue for one team and a stalled project for another.
Availability, technical compatibility and permitted use are not the same question. An archived installer answers only the first. Before you rely on one, check the intended use and the supported combination with the relevant vendors. A migration that runs on an unsupported library has no one to call when it fails at two in the morning.
Which migration routes should you investigate?
Several routes can be relevant at once, and a sensible plan for a real estate often uses more than one. The tool below asks a few questions about your destination, storage, outage window and existing tools, then shows the approaches worth investigating, the checks that matter, and where different workloads may need different treatment. Results are a planning shortlist. Exact compatibility and cutover performance need checking against your environment, and no route is certified by a questionnaire.
VMware Migration Route Finder
Answer for the workloads you plan to move together. You can run this again for another group. Nothing you enter leaves your browser unless you choose to send it to us.
Question 1 of 8
Your migration options at a glance
The table is the same set of approaches the route finder works from, so it is here whether or not you run the tool.
| Approach | When it is worth investigating | What needs checking |
|---|---|---|
| Target platform's migration tool | You have selected the destination and want its native conversion workflow | Exact versions, supported guests, storage, dependencies and access to required components |
| Veeam cross platform recovery | You already use Veeam, or need a migration and an ongoing recovery design together | Supported source backup and target, product build, required components, licensing and measured recovery time |
| Direct ESXi import or conversion | The destination or converter supports your VMware source | Disk access method, source restrictions, drivers, networking and cutover behaviour |
| Export and offline disk conversion | Workloads can tolerate a planned outage | Consistent disk extraction, staging capacity, conversion time and application validation |
| Guest or application level migration | The workload has strict downtime requirements or unusual dependencies | Application support, replication method, final synchronisation and rollback |
| Storage assisted migration | A supported source and target storage arrangement can reduce data movement | Array, protocol, software and orchestration prerequisites. Access to the storage alone is not enough |
These are approaches to evaluate, not interchangeable products. The destination platform and the method used to move workloads onto it are two different decisions, and it pays to keep them apart.
Can Veeam help you migrate away from VMware?
Yes. Veeam has documented cross platform migration uses. Its VMware to Nutanix guidance describes using backups to move workloads between hypervisors, including Instant VM Recovery to shorten the outage. The Veeam Backup and Replication 13 user guide lists backups of VMware vSphere virtual machines as a supported source for restore to Proxmox VE. Veeam's Nutanix migration guidance, Veeam restore to Proxmox VE
If you already run Veeam, investigate that capability before adding another tool. It may let you reuse a familiar recovery process, test the destination, and keep protected copies of everything throughout the move. If you do not run Veeam, it belongs in the comparison rather than at the top of it, and the comparison should weigh the ongoing protection you need as well as the migration.
Plan the migration around the specific recovery feature available for your destination. Full restore, Instant Recovery and replication are different operations. Support for one does not establish support for every other method or platform combination, and none of them is a zero downtime promise until you have timed the switchover yourself.
There is also a distinction between obtaining the source backup and recovering it onto the new platform. A cross platform restore feature does not, by itself, make the VMware backup acquisition independent of VMware interfaces. Veeam documents several VMware transport modes, which decide how the source disks are read, and those should be reviewed against the architecture you actually run. VMware's statement says partners in its Technology Alliance Program keep access for backup and recovery. Whether and how that covers your Veeam build is a question for Veeam, and one worth asking in writing. Veeam VMware transport modes
For a production cutover, establish how the final changes will be captured, when writes to the source stop, how long the restore and validation take, and when users can resume work. A backup from yesterday is useful for a rehearsal. It is not automatically an acceptable production migration point.
Our guide to Veeam for VMware and Broadcom migrations covers the wider relationship between migration and recovery planning.
What should Nutanix Move users check?
Move's ESXi to AHV workflow asks you to supply a VDDK package. In a Nutanix community thread running from late August into September 2026, customers reported the download returning errors even when signed in to Broadcom, and Nutanix staff said they cannot distribute VDDK or unofficial links and directed customers to open a support case. Nutanix Community, VDDK download for Nutanix Move
Which Move releases and migration modes need which VDDK version is currently unconfirmed, so that is the first thing to establish with Nutanix support, against your specific Move release and mode, and it should be settled before the runbook depends on it. A runbook written before August needs rereading.
Then check the complete combination: source vSphere release, storage, guest operating systems, Move release and AHV destination. A tool's name alone does not establish that a migration is ready to run.
If the assumed route has a dependency problem, assess the alternatives against the same workloads and outage requirements rather than reaching for the first thing that installs. Veeam documents a backup based route to AHV, for example, but its operational characteristics need comparing with the proposed Move workflow on your own VMs. The platform decision still deserves its own assessment: see what migrating from VMware to Nutanix involves.
What about Proxmox, OpenShift and OpenStack?
Proxmox VE
Proxmox VE has included an integrated ESXi importer since version 8.2. The vendor material shows no separate VDDK download step, and trade reporting says the importer does not depend on VDDK. That is useful evidence about the workflow rather than a guarantee about every internal dependency or future release. Proxmox ESXi import wizard
The Proxmox wiki also sets limits worth knowing before you plan around the importer: importing a VM with disks backed by vSAN does not work, encrypted disks cannot be imported until the encryption policy is removed, import is significantly slower when the VM has snapshots, and import was tested from ESXi 6.5 up to 8.0. VMs that fall outside those limits need another route, such as recovery from supported Veeam backups or an export and import. Proxmox wiki, Migrate to Proxmox VE
Whichever method you choose, qualify it against your storage and VMware version, and include guest drivers, boot configuration, networks and representative disk sizes in the pilot.
Red Hat OpenShift Virtualization
Red Hat's Migration Toolkit for Virtualization 2.11 documentation strongly recommends creating a VDDK image to accelerate migrations and warns that running without it could mean significantly lower migration speeds. Its troubleshooting documentation goes further for one case: VDDK is mandatory for migrations from vSAN storage, and migrations do not work without it when a VM is backed by vSAN. The documented steps for building the image start from the VMware download page that no longer resolves publicly. MTV 2.11 VMware requirements, MTV 2.11 vSAN troubleshooting
That makes source storage a real decision point. Check the release and migration mode you intend to use rather than assuming every VMware to OpenShift move has the same requirements, and ask Red Hat for the current supported way to provide VDDK to the toolkit. Red Hat also documents storage copy offload for a listed set of arrays, where the array performs the copy. In 2.11 it is generally available for cold migration and a Technology Preview for warm migration, and it needs a compatible array with a working CSI driver. Evaluate its prerequisites and support status separately. MTV 2.11 VMware migration planning
OpenStack and other KVM environments
The open source virt-v2v tooling documents VMware input methods including VDDK, OVA, VMX from local or NFS storage, VMX over SSH and vCenter over HTTPS. The VMX method requires the guest to be shut down before conversion, and the SSH variant does not work if the guest has snapshots. Alternative access paths exist, and each comes with an operational trade off. virt-v2v VMware input documentation
Disk conversion is one part of the work. The target's networking, guest configuration, application support and recovery arrangements still need validating, and they differ between KVM distributions.
Is StarWind V2V Converter affected?
StarWind should not be labelled universally unaffected or unusable on the evidence available.
A StarWind support discussion from September 2025 documents direct ESXi conversion using VixDiskLib, the VDDK library, and discusses VDDK related troubleshooting. Staff also suggest copying a VMDK and converting it locally as an alternative when direct access fails. That shows a distinction between direct host access and local file conversion. It does not establish how Broadcom's 2026 change affects the current release, and we could not re read the thread or the product release notes on our review date because both sat behind an access challenge. StarWind support discussion
Before committing, ask StarWind to confirm the current build's VMware access method, how any required libraries are supplied, and support for the workflow you intend to use. If local conversion is suitable, include the time and space needed to obtain a consistent copy of the disk.
The same discipline applies to any converter: identify the actual data path before calling it a VDDK free alternative.
Will existing VMware backups stop working?
The removal of a public download does not, on its own, show that an installed backup product has stopped working. VMware's statement distinguishes public access from access through selected partners. What matters is your product's supported installation and recovery procedure.
Check whether you could rebuild the backup server or a proxy today with the packages available to you. Then test a restore. An intact backup repository is valuable, but a restore also needs working software, access and infrastructure.
Ask your backup vendor to confirm the supported combination after any planned VMware or backup product upgrade. Neither a successful historical job nor a missing public download is a complete answer about recoverability. Only a tested restore is.
Choose the route around the workload
A useful migration plan starts with a few concrete facts about each group of workloads:
- Outage tolerance. How long can each application be unavailable, including validation and any rollback decision?
- Data volume and change rate. The biggest disk is not always the hardest workload. A rapidly changing database can be harder to synchronise than a large, quiet file server.
- Storage and integration. Record vSAN, external storage, shared disks, encryption and application dependencies. Two of the documented limits in this guide are about vSAN specifically.
- Existing investment. Which licences, tools, hardware and skills can be reused? The backup platform you already own may be a migration route.
- Time remaining. Work backwards from renewal and support deadlines, including a realistic pilot and contingency.
For example, a development server may suit a scheduled offline conversion. A busy database may warrant application level replication. Another group of VMs may fit a supported recovery route using existing backups. That is an illustration of how groups differ, not a claim that those methods fit every workload in those categories.
Compare the complete cost: tooling, engineering, temporary capacity, parallel running, application testing and the destination's ongoing operation. A free converter can be a good choice. It does not make the surrounding project free.
For the broader planning process, read migrating off VMware without breaking production.
Before you commit to a migration date
- Confirm the exact source, target and migration product versions.
- Identify who supplies each dependency, and obtain current vendor guidance where access or support is uncertain.
- Pilot representative workloads, including a large or complex VM.
- Measure transfer, conversion, boot and application validation time.
- Agree the final data capture, cutover and rollback process with application owners.
- Prove backup and recovery on the destination before retiring the source.
A rollback plan must address data written after cutover. Simply powering the old VM back on can leave the business with stale or conflicting data.
If the available window is too short to prove a safe move, consider a phased exit or a commercial bridge alongside a full migration. Often the right answer to a renewal is to stay and renegotiate, and a migration under time pressure is rarely a good one. Our guides to VMware alternatives and staying on VMware cover those wider choices, and the case for engaging early, before the renewal clock removes your leverage, is made in Leverage Requires Runway.
Frequently asked questions
Can we migrate without downloading VDDK ourselves?
Potentially. Some supported products manage their own dependencies, and other approaches use exported disks, guest level replication or different import paths. Confirm both the extraction step and the destination step. Avoiding a separate download is not the same as avoiding VDDK entirely, because a product can still use it internally.
Should we buy Veeam specifically for migration?
Include it in the comparison where a documented recovery route fits your destination, which at the time of writing means Nutanix AHV and Proxmox VE on Veeam's own documentation. Assess the migration requirement and the ongoing protection need together, then compare the full cost with native tools and other methods. Organisations already using Veeam should check their existing capability first.
Does every VM need to move in the same way?
No. Workload groups can have different migration methods, cutover windows and validation plans. Keep the overall programme coordinated around application dependencies so that a system and the things it talks to are not stranded on different platforms for longer than planned.
Does Proxmox need VDDK to import from ESXi?
The built in Proxmox importer shows no separate VDDK step and trade reporting says it does not depend on VDDK. It does have documented limits of its own: it does not work for disks backed by vSAN, it cannot import encrypted disks, and snapshots make it significantly slower. VMs outside those limits need a different route.
Has VDDK been discontinued?
Not on the evidence available. VMware says it continues to supply VDDK to selected partners for backup and recovery under its own developer licence. What has gone is the public download. The practical effect falls on workflows that expected the customer to fetch the kit, which includes some migration tools.
Get an independent view of your migration options
C4C helps organisations assess their options, challenge assumptions and plan the work around their estate. We can help with migration planning, proofs of concept, delivery and the supply of appropriate technology, including Veeam and Nutanix where they fit. The starting point is what you run, what you already own and what the business needs. The answer may be an existing tool, new software, a combination of methods or a phased approach, and sometimes it is to stay and renegotiate.
We spent years on the vendor side, including at VMware and the storage vendors whose arrays these disks sit on, so we know which support statements a vendor will stand behind and which questions to ask before you commit. Tell us your proposed destination, storage, approximate VM count and timescale, and we can discuss the routes worth assessing and the level of help you need.
Prefer email? Reach us directly at hello@c4cgroup.co.uk.