FluidCloud vHOP Moves VMware VMs to Azure Without VDDK: Full-Export and Firewall Caveats

Nearly everything about vHOP's capabilities comes from FluidCloud. That includes the speed claims and the customer anecdote, and none of it has been independently tested. Treat it as a vendor pitch with a few useful engineering details.

What vHOP is​

vHOP stands for VM Hopping Engine. According to IT Brief Asia, it is available through the FluidCloud platform and supports AWS, Microsoft Azure, Google Cloud, Oracle Cloud Infrastructure and Nutanix. Network World adds that it is also available through AWS Marketplace.

The pitch is that it maps a VMware estate, translates NSX firewall policy and generates Terraform for the target cloud before any workload data moves, and it does this without VDDK.

There are two modes:

• Self-service: returns a migration plan in minutes.
• Engineer-led: takes three days. It does read-only discovery through the vCenter and NSX Manager APIs.

The engineer-led package delivers:

• A review of which existing migration, backup and disaster-recovery tools depend on VDDK.
• A firewall migration plan.
• Terraform modules for the destination cloud.
• A recommended data path for each workload group.

Why VDDK matters​

VDDK is VMware's Virtual Disk Development Kit, a set of libraries for accessing virtual disk files. Many agentless migration tools used it to read VM disks remotely.

Broadcom pulled the public download pages around the end of August 2026. Several outlets give dates in that window, and Heise puts the removal at around August 25, 2026, without warning. Broadcom confirmed the change to TechTarget. Its stated position is that the kit's licensed use is backup and recovery. Broadcom told The Register that access remains available through select Technology Alliance Program partners for that licensed use case.

Some details are easy to overstate:

• VDDK has not been discontinued. Broadcom says it remains available to approved partners for backup and recovery.
• Anyone who already downloaded it can keep using it, according to Fame Systems' report.
• Not everyone accepts Broadcom's framing. TechTarget quotes one analyst who notes that anyone with a free developer account could download it for years.
• The Register argued that removing easy access doesn't change much for those planning a move away from VMware.

So the VDDK change is real, but it is a smaller obstacle than some marketing suggests. It still matters to anyone whose tooling depended on a public download.

The disk-copy engine​

The IT Brief Asia piece frames vHOP as mostly a planning tool. Network World's reporting shows it also moves data. The engine bypasses VDDK and copies disks with FluidCloud's own cloning engine, using Network File Copy exports through standard ESXi APIs and streaming the VMDK to the destination. FluidCloud says it then remediates drivers and converts the image to the target cloud's format.

Network World reports three trade-offs:

• Full exports only. The engine does not do delta sync, so every export is a full export of the VM. That matters for large, busy servers where you would normally do an initial copy and then sync changes before cutover.
• Unverified performance figures. FluidCloud claims a 2x improvement in restore and image creation over VDDK. It also claims about 5x less data transferred, because snapshots cover only the data on a disk and not its provisioned size. No methodology or workload mix was disclosed.
• Scale claim. The CEO says the company can handle more than 1,000 VMs in one batch. This is also unverified.

The firewall problem​

FluidCloud argues the real bottleneck is network policy, not disk copying. According to the company, NSX distributed firewall rules include a default that allows all traffic, while AWS security groups support only allow rules. That means deny rules must be handled elsewhere. It also means traffic that no rule ever governed has to be identified before cutover.

This is FluidCloud's characterization. Actual behavior depends on how a given NSX policy is built.

The practical lesson holds regardless of vendor. Generated rules and Terraform are a starting point. Whether you use vHOP or something else, validate them against real traffic and application dependencies before production cutover. Nothing in the reporting says the translation is automatic, lossless or safe to deploy without review.

Claims to treat with caution​

• The weekend migration. FluidCloud says one customer finished a job scoped at eight weeks over a weekend. It did not name the customer or give project details, so it says nothing about typical timelines.
• The CEO's quote. Sharad Kumar says disk copying was rarely what held these projects up. That is the company's rationale for the product, not independent evidence.
• "Cloud Cloning" and the Large Infrastructure Model. These are FluidCloud's own terms for copying cloud environments and writing them out as Terraform, and for a live map of connections across an environment.

What to do next​

1. Inventory which migration, backup and DR tools in your environment depend on VDDK. This is the one step worth doing even if you never buy vHOP.
2. Check whether your vendors have VDDK access through the partner program.
3. Audit your NSX rules for implicit allow-all behavior before mapping them to any cloud's security model.
4. Compare full-export transfer times against your bandwidth and cutover windows. The lack of delta sync is the main operational question for big or busy VMs.
5. Test any generated Terraform in a non-production landing zone first.

Kumar also told Network World that AWS and Azure see the most adoption among customers leaving VMware. He says critical workloads tend to stay with those two, and that some customers now go straight to native cloud services.