Zerto vs. Veeam CDP in the VCF 9 Era: Multi-Tenant DRaaS Is the Real Migration

I keep seeing the same question boiled down to a compatibility checkbox: does the replication product support VCF 9?

At the platform layer, both vendors can point to support. Zerto 10.9 has a documented VAIO deployment path for VCF 9.0, and its current interoperability matrix lists ESXi 9.1. Veeam Backup & Replication 13 supports vSphere 9.1 and lists VCF as supported individual VMware software components.[1][2][8]

For a service provider, that still leaves the bigger question unanswered: whether an existing multi-tenant DRaaS service can move from vSphere 8 and VMware Cloud Director into VCF 9.1 without changing the control plane, tenant boundaries, network model, recovery workflows, or the way customers connect.

That's the part I care about. Change the tenancy layer and the DR architecture changes with it.

I went back through the current Zerto, Broadcom, and Veeam docs with that question in mind. I don't see a clean vendor win. Zerto still has real strengths in continuous protection and recovery orchestration, while its legacy provider model is the part under pressure.

Veeam can move the DRaaS resource boundary into Cloud Connect instead of VCD. Universal CDP moves source-side capture into the guest. Useful differences, yes. Neither one excuses the provider from redesigning and validating the service.

The VCF 9 migration changes the tenancy layer

Documented Broadcom was explicit about VCF 9.0: VMware Cloud Director was not supported, and there was no official VCD to VCF Automation migration path at that time.[4]

VCF 9.1 is a different case. Broadcom introduced a Migration Service intended to transfer VCD workloads and configurations into VCF 9.1, along with provider-oriented improvements around tenancy and self-service.[5] That finally gives providers an official migration direction out of VCD. It does not promise that every service construct carries over one for one.

It still isn't an in-place continuation of VCD. Broadcom documents migration topology limitations. One current example is a VCF Automation 9.1 migration failure when Provider VDCs on the same NSX-T Manager are backed by multiple vCenter Servers.[6] Broadcom also documents an HCX path where HCX registers directly with the underlying vCenter 8 source, bypasses VCD, and moves VMs into a VCF Automation Namespace.[7]

For a provider, this changes the project completely. VCD isn't just a portal. It may be where customer identity, resource boundaries, storage policies, networks, catalogs, APIs, and operational tooling all meet. If that is your environment, a live VCD and Zerto estate is a service-platform migration with customer waves and DR revalidation. Calling it a hypervisor upgrade understates the work.

Zerto: VCF 9 support is real. Provider continuity is the open problem.

Documented HPE Zerto's dedicated 10.9 VCF deployment guide is for VCF 9.0 and says that VCF 9.0 is supported only with the VAIO variant. The older Zerto zDriver is not supported in VCF-managed environments.[1]

Separately, Zerto's interoperability matrix, updated in August 2026, lists ESXi 9.1 under Zerto 10.9.[2]

Architecture inference I would not turn the 9.0 deployment guide into blanket proof for every VCF 9.1 provider topology. The exact Zerto, vCenter, ESXi, and VCF combination still needs to be validated before production.

Documented The interoperability material also sets an important boundary for this VCF path. The VAIO topology referenced by the current guidance is constrained to VMware-to-VMware replication.[2] I am not extending that statement to every Zerto 10.9 capability outside the VCF and VAIO topology.

The replication engine isn't my concern here. Carrying VCD, ZORG, and ZCC forward just because ESXi 9 is on the matrix would be.

Provider evidence 11:11 Systems put a very concrete example around this in July 2026. Its published DRaaS guidance says Zerto with VAIO is not usable in the 11:11 multi-tenant DRaaS service today because VMware Cloud Director and replication through Zerto Cloud Connector are unsupported in that service model.[3] That is one provider's implementation guidance, not proof that every Zerto topology fails. I still take it seriously because VCD and ZCC are exactly the pieces an existing provider may be depending on for tenancy and transport.

Architecture conclusion Public evidence does not establish feature-equivalent continuity for the VCD, ZORG, and ZCC operating model. I would not assume Org VDCs, Provider VDC mappings, tenant networks, ZORG boundaries, ZCC paths, self-service, billing integrations, or runbooks survive the move unchanged.

Field experience From the DR side, I still like Zerto's VPG and journal model. Grouping an application and its recovery behavior around a VPG makes more sense to me than pretending every VM is an island. That strength is real. It just does not answer the provider control-plane question, and good recovery mechanics do not make an unvalidated topology safe to sell as supported.

Veeam's provider answer is Cloud Connect, not just CDP

Documented Veeam Backup & Replication 13.1.1.18 supports vSphere and ESXi 9.x up to 9.1. Veeam also lists VMware Cloud Foundation, with the qualification that VCF is supported as its individual VMware software components.[8]

The CDP requirements are more specific. vCenter Server is required, standalone ESXi is not supported, source and target hosts use the Veeam I/O filter, and Veeam documents a maximum of 500 protected disks per ESXi host for CDP.[8]

The data path is tightly coupled to VMware. The coordinator asks vCenter to create the replica and applies the Veeam CDP storage policy. Source I/O filters intercept writes, CDP proxies move them, and a target-side I/O filter writes them to replica disks and transaction logs.[10] VCF 9 support does not make that I/O-filter lifecycle disappear.

The provider model sits above that data path.

Cloud Connect Replication gives the provider two relevant ways to expose a CDP target. It can allocate VMware vSphere resources through a hardware plan, or expose VMware Cloud Director Organization VDC resources as the cloud host.[14] A hardware plan is provider compute, storage, and network capacity allocated for tenant replicas; the tenant sees that allocation as a cloud host.[15]

The third case is where I would slow down. Veeam documents VCF component support and Cloud Connect tenancy. I did not find current Veeam 13 documentation saying a Cloud Connect tenant is a native VCF Automation tenant or that a hardware plan is backed by a VCF Automation Organization, Namespace, or VPC.

Architecture inference A provider can reasonably evaluate VCF 9.1 as the supported vSphere infrastructure while Cloud Connect remains the DRaaS tenant and service plane. That gets VCD out of the Veeam tenancy dependency. It does not create documented native VCF Automation multi-tenancy. Before production, I would test tenant onboarding, networking, failover, failback, and provider operations in a lab and get the intended topology confirmed by Veeam.

Veeam also has a VCD-specific CDP path. Don't mix the models.

Veeam Backup & Replication also has a separate CDP for VMware Cloud Director workflow in the main product.[19] Cloud Connect can use VCD Org VDCs as CDP targets too. Its Cloud Connect documentation, however, says VMware Cloud Director is not supported as a source for replication to a VCD target.[18]

So I wouldn't lump every Veeam and VCD feature into one bucket. There is a VCD-aware CDP feature, a VCD-backed Cloud Connect target, and a standalone hardware-plan target. They do not have the same exposure when VCD leaves the architecture.

Universal CDP moves the source dependency into the guest

Universal CDP deserves a closer look because the name is easy to overread.

Documented Universal CDP can continuously protect supported virtual, physical, or cloud workloads and replicate them to a VMware vSphere host or cluster.[11] On the source, the Veeam CDP Agent Service and CDP Volume Filter Driver run inside the protected workload. Intercepted I/O goes to source CDP proxies, while the vSphere target still uses a VMware I/O filter for replica disks and transaction logs.[12]

That changes where the dependency lives. The source no longer has to be a VMware VM captured through a source ESXi I/O filter. It can be a supported workload on another virtualization platform, a physical server, or a cloud workload. The target is still VMware vSphere.

The trade shows up in operations. Universal CDP requires the in-guest service and filter driver, installed through protection groups with administrative credentials. Windows workloads require a reboot before Universal CDP works; Linux workloads do not.[13] Veeam also requires direct connectivity between source workloads and the backup server and documents workload limitations including 4Kn disks, CSV, Windows Storage Spaces, and powered-off workloads.[20]

Whether that trade is good depends on the service. Guest drivers, reboots, credentials, and direct source reachability may be acceptable. In some provider models they absolutely won't be. Universal CDP moves part of the complexity into each protected workload; it does not remove it.

Side-by-side architecture comparison

I kept documented behavior separate from architecture conclusions in the table. "Not documented" does not mean "unsupported." Where the vendor material did not establish a VCF Automation integration, I left the gap visible instead of filling it in myself.

Networking is where the cleaner Veeam story gets less clean

Cloud Connect can own the DRaaS tenancy layer without VCD. Good. The provider network still has to be built and operated.

Documented With a hardware-plan design, Veeam allocates tenant networks from provider VLAN ranges and deploys network extension appliances for built-in cloud networking and failover. A tenant using both full and partial failover needs a provider-side appliance plus tenant-side appliances, with a separate tenant-side appliance for each production IP network.[16] The provider-side appliance separates provider and tenant traffic with VLANs and individual VPN tunnels.[16]

The firewall model is manageable, but it is real. Current Cloud Connect documentation uses TCP and UDP 6180 as a core tenant-to-cloud-gateway transport. CDP adds provider coordinator and proxy ports, while network extension uses UDP 1195 with additional odd ports for extra tenant IP networks.[17]

At provider scale, that belongs in the architecture drawing and the firewall matrix. It should not show up as a surprise after the service is sold.

A VCD-backed Cloud Connect target changes the mechanics again. Veeam documents Org VDC networks and an NSX Edge gateway for full-site failover. It also notes that provider network extension appliances are not used for internet access after full-site failover in that VCD scenario.[21]

I still would not say Veeam 'solves' multi-tenancy. It gives the provider another place to anchor it. Hardware plans, tenant accounts, VLANs, Cloud Gateways, and network extension appliances replace VCD as the service-provider abstraction. That can fit a VCD exit much better, but the operational burden is still yours.

Recovery workflow: both products are mature, but the control boundaries differ

Veeam CDP and Universal CDP both use short-term and long-term restore points. For vSphere CDP, Veeam documents journal-based short-term restore points for up to 168 hours, with older recovery states represented by scheduled long-term restore points.[9] Universal CDP uses a similar transaction-log and long-term delta chain, but source capture comes from the in-guest filter.[12]

Current Veeam policy documentation sets a 2-second minimum RPO for both CDP types, calls 15 seconds or more the optimal setting, and allows up to a 60-minute configured RPO.[22][23] Short-term points are crash-consistent. Scheduled long-term points can use application-aware processing where supported.

Cloud Connect adds provider-aware recovery behavior. A tenant can build a cloud failover plan, and the plan is stored on the provider backup server so the provider can run it if the tenant's Veeam server disappears with the production site.[24] Veeam documents testing for cloud failover plans containing CDP replicas, planned failover for cloud CDP replicas, full-site and partial-site failover, permanent failover, and failback.[24][25][26]

Universal CDP also has documented failover, failover-plan, permanent-failover, undo, and failback workflows.[29] When it is delivered through a Cloud Connect cloud host, those product features still sit inside the provider's Cloud Connect tenant and network design.

The control boundary matters. Veeam documents failback as tenant-side only for cloud replicas. A provider can run full-site failover, but cannot perform tenant failback from the provider console.[24] Cloud Connect also does not support RBAC that assigns tenants custom roles over provider cloud infrastructure.[27] Its documented subtenant model covers cloud-repository and agent-backup quotas, so I would not present that as granular replication RBAC.[28]

I would not call Veeam's self-service model universally better. Tenants get useful recovery control, but the delegation boundary is real.

Zerto's recovery workflow is not the weak point. Preserving the provider service around it is. Test recovery, live recovery, journal checkpoints, and reverse protection only matter if the replacement VCF 9 topology keeps the tenant boundaries and connectivity those workflows rely on.

Which architecture handles the VCD exit better?

How I would validate a provider target before committing customers

I don't see a tidy winner here. Zerto has a real VCF 9 VAIO path, but an existing VCD and ZCC provider model creates a serious multi-tenancy transition problem. Veeam's strongest architectural advantage is Cloud Connect's ability to hold the DRaaS resource boundary in Veeam through standalone tenant accounts and hardware plans. That can reduce VCD coupling. It still is not documented native VCF Automation tenancy.

Universal CDP changes the source side again by making the protected workload the capture point instead of the source hypervisor. That is useful for mixed-platform providers. The target is still VMware, and the Cloud Connect network and service plane still need real engineering.

My rule for this migration is simple: choose the multi-tenant control plane you actually intend to operate, then make the replication product prove it fits that service. If you start with the hypervisor compatibility checkbox and work outward, this is exactly the kind of DRaaS dependency you miss.

Source Notes

Support matrices move. I checked the product claims in this article against public vendor material available on September 2, 2026.