A VDDK-Independent Stack for Migrating VMware Workloads

If you run VMware, the last two years have probably felt less like a technology roadmap and more like a series of things happening to you. Licensing moved to subscription. SKUs consolidated. Core minimums changed, then changed back. And in late August 2026, without any announcement, every public download page for the Virtual Disk Development Kit started returning a 404.

We've spent this year helping teams work through exactly this, and the reaction we hear most often is some version of: we didn't know we depended on that.

Here's our bottom line: the VDDK change is not an emergency for your backups, but it is a warning about your exit. The most durable answer is to protect workloads from inside the guest operating system, which removes the dependency on VDDK, on vCenter backup APIs, and on any single hypervisor's virtual-disk format, and leaves you with backups that still work after the VMware chapter closes.

We'll cover this in four parts:

1. What actually changed, and who it actually affects, because the headlines and the reality diverge.
2. Where purpose-built migration tools fit, the virt-v2v and Proxmox-importer question, answered honestly.
3. Four guest-level approaches, with a capability matrix and the real trade-offs of each.
4. The non-negotiables, the four practices that determine whether any of this works.

Part 1: What actually changed, and who it actually affects

Two things are true at once here, and most of the commentary picks one and runs with it.

Your backups are almost certainly fine. VDDK is the client-side library used to consume the vSphere APIs for Data Protection (VADP). The major backup vendors, including Veeam, Commvault, Veritas, and Rubrik, are Broadcom Technology Alliance Partners with redistribution agreements, and they bundle VDDK inside their own installers. Veeam ships it under C:\Program Files (x86)\Veeam\Backup Transport\. Commvault's Virtual Server Agent auto-selects a bundled VDDK version to match your vSphere release. Almost no end customer was ever downloading VDDK directly for backup purposes. If your nightly jobs ran last night, they will run tonight.

Your exit is the thing that got harder. VMware's first public comment came on 10 September 2026, in a statement to The Register, and it was unusually direct:

"Access to the VDDK is still available through select TAP for its licensed use case, which has always been backup and recovery."

The company further stated that VDDK "is not a customer entitlement" and "was never included with a Broadcom software purchase," and that migration to other virtualization platforms is not a licensed use of the library.

That last clause is the whole story. It is worth understanding the asymmetry precisely, because it is easy to conflate the two acronyms:

• VADP, the server-side API framework, is a customer entitlement. Broadcom's own KB 311197 confirms the Data Protection APIs "are included with all licensed vSphere editions."
• VDDK, the client-side SDK you need in order to use those APIs, is not, and never was.

You own the lock. You do not own the key. And the key is now issued only to partners, for a purpose that explicitly excludes leaving.

Worth noting what this is not. It is not a login gate, since a paying customer with active support and a valid Broadcom portal login still cannot obtain VDDK. It is not a removal of a free tier. And it is not accompanied by any deprecation notice, transition plan, or replacement. The pages are simply gone. This fits a documented pattern of progressively gating technical artifacts behind active entitlement or partnership status, and it is reasonable to plan on the assumption that the pattern continues.

One more piece of context before we go further, because we think the honest version serves you better than the dramatic one: leaving is not inevitable, and most organizations aren't. In 451 Alliance's 2026 survey, the single largest response on two-to-three-year virtualization strategy was retain current hypervisors, at 33%. Roughly 20% planned to replatform to a different hypervisor and 19% to rehost into public cloud. The typical organization already runs close to three hypervisors. If you're staying, this article is still useful, because everything below improves your recovery posture regardless. But nobody should feel stampeded.

Part 2: Where purpose-built migration tools fit

We want to address this directly, because if we skipped it you'd rightly wonder why.

There is a mature ecosystem of tools built specifically to move VMs off VMware, and several are genuinely excellent:

• Proxmox VE's native ESXi import wizard, built in since Proxmox VE 8 and configured under Datacenter → Storage → Add. Tested against ESXi 6.5 through 8.0.
• virt-v2v, open source, which converts ESXi guests to KVM and injects the drivers the target platform needs, addressing the exact failure mode that makes naive image restores fail to boot.
• Nutanix Move for AHV targets, Red Hat's Migration Toolkit for Virtualization (MTV) for OpenShift Virtualization, and Microsoft's converter tooling for Hyper-V.

If you have a straightforward estate, a known target, and working access to these tools, use them. They are faster than what we describe below, and we recommend them routinely. This is not an argument that they're bad.

It is an argument about what you're standing on. Several of these tools use VDDK for their fast transport path, which is precisely the dependency that just moved outside your control. Some have non-VDDK fallbacks; those fallbacks are generally slower, and their future is now a decision made by someone else. More fundamentally, a conversion tool produces a converted image: an artifact shaped by both the source hypervisor and the target, carrying forward whatever drift, undocumented configuration, and legacy assumptions the original VM accumulated. It solves the migration. It does not improve your recovery posture, and it does not survive the next platform change.

Guest-level backup is slower and less glamorous. What it gives you is an artifact that belongs to you, restores onto hardware you haven't chosen yet, and is still a working backup strategy after the migration is done. For estates where the target platform isn't settled, where the timeline runs past 2027, or where backup modernization was already on the roadmap, we think that trade is worth making. For a clean, fast, well-scoped move to a known target, reach for virt-v2v or the Proxmox importer and don't overthink it.

Our recommendation is not one product. It's a layered approach, chosen by recovery objective rather than by VM count:

• Linux workloads: ReaR for bootable system recovery, paired with Borg or restic for encrypted data backup.
• Windows and mixed estates: UrBackup for guest-level image and file backups.
• Larger environments with central governance needs: Bareos as the backup control plane, with ReaR for Linux recovery.
• Rebuilt or cloud-bound workloads: restic plus infrastructure-as-code and configuration management.

Capability matrix

¹ ReaR's documentation is explicit that it "supports recovering to different hardware, but it cannot always automatically adapt to this new environment. In such cases it requires a manual intervention," typically hand-editing disklayout.conf, resizing partitions, or reconfiguring network interfaces.

² UrBackup image backups on Linux are supported from client 2.5.19 onward but are conditional: ext2/3/4 and XFS only, MBR or GPT primary partitions, and a working snapshot mechanism (dattobd or device-mapper). UEFI Linux systems cannot be fully imaged, because the EFI System Partition is vFat and vFat is unsupported. Note also that UrBackup's server administration manual still states image backups are Windows-only; the features page and client changelog supersede it, but the contradiction is live on their site today.

³ Bareos's File Daemon backs up Windows guests at file level with VSS support. Bareos 25 introduced Barri, a Windows disaster-recovery imager, but its binary packages ship only in the subscription repository, so we've scoped this row to what the community edition delivers. See the Option 3 caveats.

Part 3: Four guest-level approaches

Option 1: ReaR + Borg (or restic) for Linux

Relax-and-Recover, or ReaR, is the strongest open-source foundation for Linux workloads that need a real recovery or migration path. It produces a bootable image that can recreate the system's original storage layout, then initiates a restore from backup. Output formats include ISO, PXE, USB, OBDR, RAWDISK, and RAMDISK. It is GPL-3.0, and its own repository describes it as a "Linux bare metal disaster recovery and system migration solution."

This is our default for Linux application servers, internal services, and workloads headed for KVM, Proxmox, cloud VMs, or bare metal.

One important correction to how this pairing is usually described. ReaR and restic are not integrated. ReaR's own documentation states plainly: "Currently there is no workflow in ReaR that supports restic." There is no BACKUP=RESTIC. The only path is the generic BACKUP=EXTERNAL hook with hand-written restic commands, which ReaR says is "not officially supported by the ReaR maintainers."

Borg, by contrast, is native: BACKUP=BORG, documented as "native support for BorgBackup." So is Bareos (BACKUP=BAREOS) and rsync. There are roughly seventeen documented backends in total, including NetBackup, NetWorker, Data Protector, Bacula, and CommVault.

If you want a supported ReaR backend, use Borg. If you want restic, and there are good reasons to, particularly for Windows and multi-cloud, run it alongside ReaR as an independent tool, and understand you own the integration.

Pros

• Independent of VDDK and VMware's disk APIs.
• Supports recovery onto dissimilar hardware or a different virtualization platform.
• Clean separation between system recovery and encrypted, incremental data backup.

Cons

• Linux only. It is not a Windows migration solution.
• Dissimilar-hardware recovery frequently requires manual intervention; ReaR carries the source system's kernel and driver support forward and will not inject drivers for you.
• Requires disciplined handling of database consistency and application quiescing.
• Recovery is a restore-and-test workflow, not a live migration.
• Borg has no native Windows support, only experimental Cygwin and WSL builds. restic runs natively on Windows; Borg does not.

Tooling notes. restic is BSD-2 licensed, ships as a single static binary, and runs natively on Linux, Windows, macOS, and the BSDs, with Windows VSS support via --use-fs-snapshot. It provides client-side encryption, content-defined deduplication, incremental transfer, and repository verification (restic check --read-data re-reads and validates every pack file). Backends include local, SFTP, REST, S3, MinIO, Wasabi, Alibaba OSS, Swift, Backblaze B2, Azure Blob, Google Cloud Storage, and anything reachable via rclone. Borg offers the same encryption and deduplication guarantees, client-side AES-256 with HMAC-SHA256, on Linux, macOS, and the BSDs.

Sources: ReaR user guide · ReaR backend configuration · ReaR restic scenario · restic · BorgBackup

Option 2: UrBackup for mixed Windows and Linux estates

UrBackup is the most approachable open-source option when the environment contains both Windows and Linux guests. It provides in-guest file backups and system-image backups, plus free bootable restore media, and the Restore Stick 2.6.0 ISO is a direct download with no registration. It is AGPLv3+ and actively maintained; server 2.5.38 shipped on 30 August 2026.

Image data can be stored as VHD, compressed VHD (VHDZ), VHDX or VHDXZ, with VHDX lifting the roughly 2TB VHD size ceiling, or as raw copy-on-write files on btrfs, ZFS, ReFS, and XFS. The VHD and VHDX options are useful when feeding a later disk-conversion or import workflow.

This is a strong fit for smaller estates that need a practical migration safety net without building a dedicated backup engineering practice.

Pros

• Covers both Windows and Linux with one client/server platform.
• File-level and system-image recovery from a single tool.
• Genuinely easier to deploy and operate than a full enterprise backup framework.
• Free, unrestricted bootable restore media.

Cons

• Linux image backup is conditional. ext2/3/4 and XFS only, MBR or GPT primary partitions, and a configured snapshot mechanism. UEFI Linux systems cannot be fully imaged because the vFat ESP is unsupported. If your Linux estate is UEFI, and increasingly it is, plan on ReaR for those guests rather than UrBackup images.
• Windows restores to different virtual hardware require driver and boot testing. Test the restore media against your actual target hardware early; UrBackup's own manual warns about exotic or new hardware, and the restore client needs to reach the server without NAT in between.
• Kernel-level changed block tracking is a paid add-on (€15.50 excl. VAT per client) and is Windows-only. Base incremental images work by hashing changed sectors, which is slower.
• Less flexible than Bareos for complex policy, catalog, and compliance requirements.
• Does not replace application-native backup or replication for databases.

Sources: UrBackup features and limitations · UrBackup downloads · UrBackup commercial add-ons

Option 3: Bareos with ReaR for governed environments

Bareos is the right fit when central scheduling, retention, catalog management, and auditability matter. It is AGPLv3, currently on the Bareos 25 release line, with a PostgreSQL catalog holding file indexes and volume databases. Its Director configuration covers Schedule resources, Pool resources with volume retention, and file, job, and volume retention with pruning.

Its File Daemon is a genuine in-guest agent, installed on each client machine that should be backed up, with a native Windows port that includes VSS support for open files. For Linux, pair Bareos with ReaR, which supports BACKUP=BAREOS natively, for bare-metal-style recovery.

Scope the VDDK claim carefully here. Choosing the in-guest File Daemon path avoids VDDK entirely. But Bareos as a product has not escaped it: the Bareos VMware plugin is VADP-based, explicitly uses VDDK, and additionally requires at least a VMware vSphere Essentials license, so it does not work against unlicensed standalone ESXi. The agent path is VDDK-free. The agentless path is not. Deploy accordingly.

On Windows disaster recovery: Bareos 25 introduced Barri, the Bareos Disaster Recovery Imager, which creates VSS snapshots of a running Windows system and writes a .barri DR file. The source is AGPL and sits in the public GitHub repository. The binary packages, however, ship only from the subscription repository at download.bareos.com, alongside the Proxmox and Hyper-V plugins. The documentation gives plain apt and dnf install instructions without flagging this, which has caught out more than one team. If you are building an open-source-only stack, Bareos gives you excellent Windows file-level backup and Linux full-system recovery. Treat Windows DR imaging as either a commercial line item or a job for UrBackup.

Pros

• Centralized policy, scheduling, reporting, and recovery catalog.
• In-guest agents across Linux and Windows, both in the community edition.
• Combines routine file and application backups with platform-independent recovery media for Linux.

Cons

• More operationally complex than restic or UrBackup.
• Requires thoughtful design for storage, catalog backup, credentials, and restore operations.
• Windows bare-metal DR imaging requires a subscription; the community edition covers Windows at file level.
• The VMware plugin, if you were considering it, reintroduces the VDDK dependency and requires a licensed vSphere.

Sources: What is Bareos · Bareos plugins · Bareos downloads and repositories

Option 4: restic plus infrastructure-as-code for cloud-bound workloads

For workloads moving to public cloud, rebuilding the server is often safer than carrying a legacy VM image through multiple conversions. Use restic to protect application data and configuration, then OpenTofu and Ansible to create the target infrastructure and configure the replacement.

This is not a whole-VM migration approach. It treats the VM as disposable infrastructure.

We should be straight with you that this cuts against the hyperscalers' default advice. AWS's own prescriptive guidance states that "Refactor is not recommended for large migrations because it involves modernizing the application during the migration," and recommends "rehosting, relocating, or replatforming the application and then modernizing the application after the migration is complete." Microsoft positions Rebuild for highly complex applications or where advanced compliance frameworks are required; Google notes that rehost requires the least time and lets teams keep existing skills. The documented mainstream sequence is rehost first, modernize second.

So where does rebuild actually win? In our experience, three conditions:

1. The guest OS is at or past end of life. AWS Application Migration Service publishes hard deprecation dates. Windows Server 2003 support ended 15 February 2026; CentOS 6.x, Oracle Linux 6.x and SLES 11.x end 28 August 2026; CentOS 7 through 7.9 and Amazon Linux 1 end 20 November 2026; Windows Server 2008 and Windows 7 end 30 December 2026. The rehost path for genuinely old guests is closing, not opening.
2. Configuration has drifted beyond documentation. If nobody can say what's on the box, converting it faithfully just preserves the mystery.
3. The conversion chain has more than one hop. Each conversion is a place for boot configuration, drivers, and disk geometry to go wrong, and multi-hop chains are where we see the most restore-day surprises.

Outside those conditions, rehost first. It is the lower-risk path and the industry knows it.

Pros

• The most portable result; no hypervisor-specific artifacts survive.
• Enables clean rebuilds, repeatable environments, and more reliable future recovery.
• Works across Linux, Windows, on-premises storage, and the major clouds.

Cons

• Requires existing or newly created automation and configuration discipline.
• Demands more application knowledge than an image restore.
• Not suitable as the sole first step for a legacy application with no documented rebuild path.
• Cuts against hyperscaler guidance for large migrations, so be prepared to justify it case by case.

Tooling notes. OpenTofu is governed by the Linux Foundation under MPL 2.0, currently on the v1.12.x stable line with 3,900+ providers in its registry. It describes itself as a drop-in Terraform replacement, which holds cleanly for greenfield provisioning; the projects have diverged since the 2023 fork, so treat migration of a large existing Terraform estate as a real project rather than a rename. Ansible remains GPLv3 under Red Hat, with no license rug-pull, and ansible-core 2.21 went GA in May 2026. One caution: ansible-core 2.19 rewrote the templating engine, and playbooks written against older cores can break. If you have an existing playbook library, budget for that migration.

Part 4: The non-negotiables

Whatever toolset you choose, four practices determine whether a guest-agent migration succeeds. In our experience these are where projects actually fail, not in tool selection.

1. Protect databases with native backups or replication. A filesystem backup alone is rarely sufficient for a busy database. This is the single most common cause of a "successful" migration that produces a corrupt application.

2. Record VM configuration separately. IP addresses, DNS, firewall rules, certificates, disk layout, boot mode, and service dependencies. Boot mode especially, because UEFI versus BIOS is the detail that quietly decides whether several of the options above will work at all.

3. Test a complete restore on the destination platform before setting a cutover date. A successful backup job does not prove the workload will boot, attach its network, or serve traffic. Test the restore media against real target hardware too, not just the backup.

4. Plan migration around recovery objectives. Guest-agent approaches restore a point in time. They are not continuous, zero-downtime replication, and presenting them to stakeholders as though they are will cost you credibility on cutover weekend.

Bottom line

The VDDK change didn't break your backups, because the vendors who needed that library already have it. What it did was make your exit conditional on somebody else's partner program, and VMware has now said in public that leaving isn't a licensed use of the tool. Both things are worth knowing, and only one of them is urgent.

Guest-level protection answers both. For most Linux workloads, ReaR plus Borg is our default, with restic alongside it rather than inside it. For mixed Windows and Linux estates, UrBackup is the easiest starting point, with the UEFI caveat firmly in mind. For larger organizations, Bareos with ReaR provides the most control, with Windows DR imaging scoped honestly. And for workloads genuinely headed to the cloud with an EOL OS or undocumented configuration, restic plus automated rebuilds is the most durable long-term answer.

For the people doing this work, that's the part that matters: none of these approaches require VDDK, none of them require a partner agreement, and none of them stop being useful the day the migration finishes. The engineer who tests a ReaR restore in October still has a working recovery process in March, on whatever platform you land on. That's a better outcome than a converted disk image and a hope.

We've covered what changed and who it affects, where purpose-built migration tooling fits alongside this approach, four guest-level options with their real trade-offs, and the four practices that decide the outcome. If you're scoping a VMware exit, or deciding whether you need one, we're happy to work through the specifics with you.

Claims in this article were verified against vendor documentation as of 11 September 2026. Product versions, licensing terms, and repository availability change; verify against current sources before making procurement decisions.