On 25 August 2026, the public download pages for the VMware Virtual Disk Development Kit disappeared. Every URL on developer.broadcom.com that used to serve a VDDK tarball now returns a 404 or a JSON error, tested from multiple regions. There was no deprecation notice, no transition period, no archive and no replacement. Customers who opened support cases have been told, in writing, that the VDDK is no longer available for use or download, and that Broadcom maintains its SDKs for authorised technology alliance partners building backup and recovery software.
If you have never heard of the VDDK, that is normal. It is a C library, not a product. It is also the component that lets software outside the hypervisor open a VMDK and read blocks out of it. Combined with Changed Block Tracking, it is what makes agentless migration and agentless backup possible at all. Take it away and a large part of the tooling that reads VMware disks from the outside stops being installable.
Plenty of platforms are affected. This post is only about one of them: AWS. If you are running vSphere and you have been telling yourself that the migration project can wait another budget cycle, this is the part where the calculation changes.
What actually broke on the AWS side
AWS Transform MGN, still widely known as AWS Application Migration Service, offers two replication methods for VMware sources.
Agentless snapshot-based replication runs through the MGN vCenter Client, a software bundle you install on a dedicated Linux VM inside your vSphere environment. It discovers your VMs through vCenter, then for each replication run it takes a VMware snapshot, uses CBT to work out which blocks changed, and reads those blocks with the VDDK before shipping them to AWS.
The VDDK is not bundled with the client. It cannot be, because the licence forbids redistribution. You supply it yourself. The AWS documentation is explicit about the version:
You must log in to your Broadcomm account and download VDDK 7.0.3.3 to the VM on which the MGN vCenter Client is installed. VDDK 7.0.3.3 must be used, regardless of the vCenter version used.
The installer takes it as a parameter, --vddk-path, pointing at the tarball on local disk.
That is the whole problem in one line. VDDK 7.0.3.3 is a 7.0 line release. The 7.x downloads were already unreliable before August, and now the entire download tree is gone. As of writing, that documentation page is unchanged and still tells you to go and fetch a file that cannot be fetched. AWS has published nothing about the change: no bulletin, no what’s-new post, no documentation update. So a customer starting a greenfield agentless deployment today follows the runbook, hits a dead link at step four, and has no official guidance telling them why.
Agent-based replication installs the AWS Replication Agent inside the guest OS. It reads blocks through its own kernel-level driver, talks directly to a replication server in your staging subnet, and never touches the VDDK, vCenter or VMware snapshots. Nothing about it changed on 25 August.
Two things follow from that, and they matter more than the headlines suggest.
First, the practical damage on AWS is narrower than on platforms whose only migration path was VDDK-based. AWS’s own FAQ has said for years that agent-based replication is the default recommendation for all use cases, with agentless reserved for the exceptions: security policy that forbids installing agents, or an OS the agent does not support. The supported operating system lists for the two methods are in fact identical, so in practice the exception is almost always the policy one. Broadcom removed AWS’s fallback, not its main road.
Second, “narrower” is not “none”. If you are the organisation whose change board does not allow third-party agents in the guest, or you inherited an estate where nobody has working credentials for a few hundred VMs, agentless was the answer and it is now gone for new installs.
One nuance worth stating plainly because we have not seen AWS confirm it: an existing vCenter Client installation already has the VDDK on disk, and the client auto-updates itself independently of the VDDK. Running replications are not expected to break. But rebuild that VM, move to a new AWS account, or add a second vCenter environment, and you are back at the 404. Treat every existing vCenter Client as a single point of failure you can no longer reprovision.
Four routes to AWS that do not need a download from Broadcom
1. Agent-based MGN, deployed at scale with the MGN connector
The reflex objection to agent-based migration is that somebody has to log into every VM. That was true a few years ago. It is not the current state of the tooling, and this is the single most useful thing to know if the VDDK removal is what pushed you into a decision.
The MGN connector is a Linux VM in your source environment, registered to AWS through a Systems Manager hybrid activation, that pushes the replication agent out to your source servers for you. You give it network reachability to the sources and a set of source credentials in AWS Secrets Manager, and it handles prerequisite validation, installation on both Windows and Linux, and post-install verification. Installation of the connector itself takes a couple of minutes and is a one-time task per source environment. AWS Transform will now generate the IAM roles, the hybrid activation code and the ready-to-run install command for you through its console flow, or hand you a CloudFormation template if you would rather own the IAM yourself.
For the servers the connector cannot reach, the manual install is a single command. On Linux:
wget -O ./aws-replication-installer-init \
https://aws-application-migration-service-eu-west-1.s3.eu-west-1.amazonaws.com/latest/linux/aws-replication-installer-init
chmod +x aws-replication-installer-init
sudo ./aws-replication-installer-init \
--region eu-west-1 \
--user-provided-id vm-prod-app-014 \
--no-replication \
--no-prompt
Two flags earn their keep on a large migration. --user-provided-id sets the identifier MGN uses to recognise the server consistently, which is also what AWS Transform keys on when it maps your inventory into wave plans, so set it at install time rather than trying to reconcile later. --no-replication installs without starting the data flow, which lets you pre-stage agents across hundreds of servers and then switch on replication wave by wave instead of saturating your uplink and your MGN quotas on day one.
Validate the installer hash before you push it estate-wide. It is published per region alongside the binary.
What you need in place, and what tends to be the actual project work rather than the agent install:
- Outbound TCP 443 from every source server to the regional MGN endpoint, and TCP 1500 to the replication servers in your staging subnet. PrivateLink over Direct Connect or Site-to-Site VPN if the data must not cross the internet.
- A staging area subnet with routing to S3, since the replication server fetches its own components from there. This is the single most common cause of a replication that installs cleanly and then stalls.
- Root or administrator on each guest. The Linux installer creates an
aws-replicationuser and adds it to sudoers, and fails if it cannot. - Kernel headers on the Linux guests matching the running kernel.
The compensation for the extra guest-level work is real: continuous block-level replication rather than periodic snapshot shipping, which means a cutover window measured in minutes instead of waiting for a final snapshot to complete, and no VMware snapshots sitting on your production datastores slowing disk performance during the whole migration.
2. The cached tarball, with a caveat you should not skip
If someone in your organisation still has VMware-vix-disklib-7.0.3.3-*.tar.gz on a build host, a backup appliance or an old runbook attachment, it will still work. The installer only wants a path. Checksums for the 7.0 and 8.0 lines are recoverable from cached copies of the portal, so verify what you hold rather than trusting the filename.
The caveat: Broadcom’s own wording to customers is that the VDDK is no longer available for use or download. Not just download. We are not lawyers and this is not legal advice, but if your plan depends on a cached copy of a proprietary library whose vendor has just told customers it is not available for use, that is a question for your legal team before it becomes a question for your auditor. Ask it now, not the week before cutover.
3. Offline export through VM Import/Export
This is the path that needs no VDDK and no agent at all. Export the VM from vSphere as an OVA or a stream-optimised VMDK using vCenter’s own export function or OVF Tool, upload it to S3, and import it as an AMI:
aws ec2 import-image \
--disk-containers Format=ova,UserBucket="{S3Bucket=my-import-bucket,S3Key=vms/app014.ova}"
You need an IAM service role named vmimport with a trust policy for vmie.amazonaws.com and permissions on the source bucket and on EC2. Supported input formats are OVA, VMDK, VHD, VHDX and raw.
Be honest with yourself about what this path costs before you make it the plan for more than a handful of servers:
- No CBT, so every attempt is a full copy. A failed import is a full re-copy.
- Staging storage for the exports, on-premises and in S3, sized for your largest VMs.
- Real downtime, because you export a powered-off or quiesced VM and there is no delta sync afterwards.
- Genuine limitations. VMs using Raw Device Mapping are not supported, only VMDK disk images. Encrypted volumes are not supported. Dual-boot configurations are not supported. Neither is the VMware SEsparse delta-file format, nor arm64. Machines that got where they are through a physical-to-virtual conversion are not supported. There is a defined supported-OS matrix and older or unusual guests fall outside it.
VM Import/Export is a good tool for a controlled set of appliances and stragglers. It is not a replacement for a replication-based migration of a few hundred workloads, and anyone who tells you otherwise has not tried it at that scale.
4. Stop moving the VM
The uncomfortable observation in a lot of migration assessments is that a meaningful slice of the estate should not be rehosted at all. A file server becomes Amazon FSx or S3 with DataSync doing the copy. A SQL Server or Oracle instance becomes an RDS instance with AWS DMS handling the load and change data capture. An application server that was built by hand in 2016 gets rebuilt from a pipeline, which is faster than debugging why its agent will not install.
None of those paths care about the VDDK, because none of them read the virtual disk. If your agentless plan just died, this is a good moment to re-run the assessment and ask which VMs you were only lifting because lifting looked cheap.
What to do in the next two weeks
- Inventory what you hold. Search your build hosts, backup appliances and documentation attachments for VDDK tarballs. Checksum them. Treat them as assets with an expiry date, and get the licensing question in front of legal.
- Check whether you actually have an existing vCenter Client. If yes, freeze it. No rebuilds, no account moves, no second environment, until you have a tested alternative.
- Test the agent on your hardest 5 percent. Not your easy Linux fleet. The 2012 R2 box nobody logs into, the appliance with a vendor-locked OS, the VM whose kernel headers are missing. Those are the servers that will decide whether agent-based works for you, and you want to know in September, not in March.
- Exercise the OVA path once, deliberately. Export one real VM, import it, boot it, log in. A fallback you have never run is not a fallback.
- Put the date on the wall. General support for vSphere 8 ends on 11 October 2027, with technical guidance running to 2029. That is your outer bound, and it is closer than it looks once you subtract assessment, network design, wave planning and testing.
The pattern is the point
Broadcom is reportedly bringing back a refreshed vSphere Standard aimed at smaller estates, discussed in interviews at VMware Explore rather than announced from a stage, with details promised in October. Read alongside the VDDK removal, the two moves are hard to reconcile as a coherent retention strategy. One says come back, the smaller edition is being looked after. The other quietly removes a dependency that the entire third-party exit ecosystem was built on, with no notice and no replacement.
Whatever the intent, the operational conclusion is the same. The technical routes off vSphere are being narrowed, not widened, and they are being narrowed without warning. The VDDK went away on a Tuesday. Nothing says the next dependency will give you more notice.
If you are going to leave, the cost of leaving is lowest while you still have working tooling, a supported hypervisor version, and time to test. That window is not open indefinitely.
Where Cloudar fits
We have done this often enough to know which parts of a VMware to AWS migration are the hard parts, and the disk copy is rarely one of them. The hard parts are the dependency mapping nobody documented, the network translation, the wave sequencing, the servers that resist every automated approach, and the operational handover afterwards. We work through those with AWS Transform and MGN where they fit, and around them where they do not.
If the VDDK removal has just invalidated your migration plan, or if it has made you realise you did not have one, our AWS migration practice is the place to start. We are an AWS Premier Partner and Migration Competency partner based in Belgium, and we would rather assess your estate honestly than sell you a lift-and-shift you will regret.
For the strategic side of the same question, why the timing of your VMware exit matters as much as the mechanics, see Leaving VMware is a question of timing.
All AWS documentation references were verified on 8 September 2026. AWS had published no guidance on the VDDK removal at that point, and the MGN vCenter Client requirements page still instructed customers to download VDDK 7.0.3.3 from Broadcom.
