Executive Summary
Broadcom stopped publishing the VMware Virtual Disk Development Kit in August 2026, and that download was the piece many ESXi migration tools depended on. Nutanix Move read source disks through the VDDK, so its users hit a dead link in the middle of a migration wave. Move 6.3.3, released October 12, removes the dependency with a method called DirectPath that reads the disks directly.
The migration workflow is unchanged. The deployment model is not, and that is the part teams will feel. DirectPath installs as a fresh appliance only, so an in-flight migration finishes on the old appliance and new waves start clean. The read here is simple. Migration friction has moved from a licensing gate to an engineering one, and Nutanix just cleared its side of it.
The tool a lot of teams are using to leave VMware quietly broke this summer. Broadcom pulled the public download its migration path needed, and the link in the setup guide started returning a 404.
For years, every ESXi migration with Nutanix Move started the same way. You downloaded the VMware Virtual Disk Development Kit from the Broadcom developer portal, then uploaded it into the Move appliance. Move used that library to read virtual machine disks out of vSphere. In late August 2026, Broadcom removed the public VDDK downloads. Teams setting up Move hit 404s, and customers who opened support cases were pointed at the Technology Alliance Program, which serves vendors building products.
Broadcom told The Register on September 10 that the VDDK stays available to select partners for its licensed use case, which it describes as backup and recovery. It also said the VDDK is not a customer entitlement. The practical effect is blunt. Migrating to another platform is not a use case Broadcom intends to support, and a customer without a saved copy of the library had no supported way to get one.
Nutanix stopped needing the library instead of asking for it
Move 6.3.3, released on October 12, adds a migration method called DirectPath. Instead of reading disks through the VDDK, DirectPath attaches snapshots of the source disks to the Move appliance and copies the data straight across. There is no library to download and no version to match against the ESXi build.
The catch is where Move runs. DirectPath deploys the Move appliance inside the source VMware environment rather than beside it, because it needs direct access to the datastore holding the source disks. That changes the network requirements. The appliance needs management access to vCenter on port 443, to the ESXi host on 443, to Prism on 9440, and NFS access to every target controller VM on the Nutanix cluster over ports 111 and 2049.
DirectPath moves the appliance, not the workflow
Nutanix kept the migration workflow intact. You still add environments, select virtual machines, map networks, seed data and cut over. What changed is the data path and the deployment. DirectPath stays a data-copy migration, so it does not remove network transfer, and Move 6.3.3 does not support zero-copy migration or in-place cluster conversion.
The harder constraint is versioning. Move 6.3.3 installs as a new appliance only. You cannot upgrade into it from an earlier release, and you cannot upgrade away from it yet. An appliance already partway through migration plans should finish those plans where it sits. New work starts on a fresh deployment, with environments, network mappings and bandwidth policies rebuilt by hand.
What to check before your next migration wave
The compatibility window is wide. DirectPath supports ESXi 6.5 through 8.0 Update 3 and vCenter up to 9.0, which covers most estates still running VMware. Two permissions are required on the source, provisioning access to download virtual machines and cryptographic operations for direct access.
A few known issues are worth reading first. DirectPath can fail when two clusters in the same data center hold datastores with identical names but different contents. CentOS 8.4 and 8.5 virtual machines configured with Secure Boot may fail to boot on AHV after migration. And Move uses the 172.17 and 172.18 address ranges internally, so avoid those ranges if they collide with yours.
Three questions for your own estate. Do you still have a saved copy of the VMware VDDK, and does anything else in your toolchain depend on it? Which of your migration waves are mid-flight, and can they finish before you need a 6.3.3 appliance? And does your Move deployment have NFS reach to every controller VM on the target cluster?
Related reading. Broadcom shipped HyperArmor to buy time on hypervisor patching, and why patching the hypervisor is too slow is the argument in that analysis.
Sources. The VDDK change and Broadcom position were reported by The Register. Release details come from the Nutanix Move 6.3.3 release notes and the DirectPath documentation. Nutanix hosts its product documentation at nutanix.com.
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.