The VDDK disruption shows why data mobility architecture matters

In recent weeks, Broadcom’s decision to pull public VDDK downloads has reignited the “Exit VMware” discussion, adding uncertainty to migration plans that depend on the library.

Choosing an architecture is one of the most important parts of building a technology product, and these decisions are often tricky. You want to use what already works. But you have to ask whether those choices will deliver the experience you want your users to have, including when their needs change in the future. A product has to work well, and, more importantly, it has to work consistently well.

When we built Cirrus Data to address the evolving data mobility needs of enterprises, we wanted a platform that could integrate with products across the industry. But, while we love integrations, one thing we insisted on was that the core technology moving our customers’ data had to be our own. Stitching together a different migration tool for each platform would leave customers dealing with each tool’s limitations. We wanted them to learn one approach and keep using it. Learn once, use forever.

That led us to develop our proprietary patented technology, Transparent Datapath Intercept, or TDI. We started with a physical appliance that intercepted Fibre Channel storage traffic transparently, so customers could migrate data completely live without interruption or disruption. We later brought that approach into OS-level software for virtual machines and cloud environments.

VDDK, VMware’s Virtual Disk Development Kit, provides the core library that lets software programmatically access individual data blocks in a VM’s virtual disks, including reading disk data through a snapshot. That block-level access is fundamental to copying a workload’s data to another platform. Many migration products depend on it to read the data they need to move.

At the end of August 2026, as many enterprises were already working through VMware exits prompted by higher costs and licensing changes following Broadcom’s 2023 acquisition, the VDDK library was removed from Broadcom’s public download page. ShapeBlue reported the disappearance of the public VDDK download pages on 8/25/2026. This immediately added a new obstacle to those migrations.

The affected migration workflows include Red Hat’s Migration Toolkit for Virtualization, Nutanix Move, the OpenStack Migration Tool, and many other open-source and closed-source tools such as virt-v2v and nbdkit. While existing deployments are not affected, customers who need a VDDK download from Broadcom now depend on Broadcom support’s decision to grant access to a core piece of their migration solution. Without a doubt, an enterprise cannot afford that uncertainty when it has committed to a migration schedule.

VDDK is tremendously popular for a reason. VMware snapshots, Changed Block Tracking, or CBT, and VDDK provide very useful building blocks. In fact, early prototypes of Cirrus Data’s VM compute platform mobility solution were also based on CBT tracking at some point. Of course, that dependency was eventually replaced by our TDI-based data tracker and data mover because, while CBT and VDDK would have saved us engineering work, they would also have tied our data movement to the source platform’s capabilities and availability.

Actually, even before this VDDK episode, snapshot scaling limitations were already a major reason for our approach. VMware’s own guidance warns that growing snapshot files can consume storage and affect performance. Consolidation can also affect other VMs sharing the datastore. Across a large migration, that means managing snapshot growth and cleanup alongside production workloads, and that is certainly not ideal for enterprise-scale data migrations. Our early tests had already shown that, in order to scale, it is crucial to avoid that snapshot overhead entirely, removing a constraint on how many workloads a team can move together.

Cirrus Data Cloud migrations are strictly guest-to-guest, directly from the source operating system to the destination operating system, at the block level. TDI tracks block changes live at the source while the workload runs, and we replicate the data between those systems. The data path requires neither VMware snapshots nor VMware CBT nor VDDK.

It makes no difference to Cirrus Data Cloud whether the source is a VMware guest or a physical server. Even a tiny Windows machine tucked away in a closet can use the same approach, provided its operating system is supported and the destination is compatible. This flexibility is also extremely crucial at scale because it can then support practically any kind of block storage, including software-defined storage and directly mapped disks (RDMs, iSCSI-connected disks, etc.).

Building our own intercept technology means we take responsibility for that part of the migration. This VDDK download restriction is a great example that shows why our proprietary core technology is important for providing our users with a consistent user experience. With integrations across 16 compute migration target platforms and over 35 storage products, it is impractical and unscalable to require customers to know which outside dependencies can interrupt their plans.

Broadcom’s acquisition made VMware exits a pressing use case for many people. VDDK access has now put the underlying architecture under closer scrutiny. Our goal remains “learn once, use forever”: give customers a migration method they can keep using as their infrastructure changes.

People may be leaving VMware today. At the same time, it is important for our users to be aware that they can do exactly the same thing for their next 3 moves in the future.

—

For further reading:

Read more about Virtualization Migration with Cirrus Data.

Read our whitepaper From VMware To Anywhere, which covers the core principles of an ideal VM migration.