Cloud Director 10.6.2: Before VCF Automation

VMware Cloud Director 10.6.2 is the release Broadcom calls a migration release. What it contains, the three official steps to VCF Automation 9.1, and what to do now.

If you run Cloud Director and plan to move to VCF Automation 9.1, 10.6.2 is where you start. Here is what it contains, what the migration path looks like, and what Broadcom has not made public.

Why 10.6.2 matters

The Broadcom blog, dated 2 September 2026 and signed by Jaikishan Tayal, calls 10.6.2 "a migration release". The release notes and the KB date it 3 September 2026 (build 25707817). It adds support for VCF 9.1.1, which went GA on 3 September. KB 455238 says that to migrate from Cloud Director to VCF Automation, you upgrade to 10.6.2 first.

You can upgrade from 10.6.0, 10.6.0.1, 10.6.1, 10.6.1.1 and 10.6.1.2.

On end of life, the Broadcom blog says 10.6.2 shares its EOL date with VCF 9.1. No official date is published.

What is in the release

Security. Photon OS 4.0 updates up to PHSA-2026-4.0-1061. A Jetty fix: the API documentation under /docs/vcd/39.1/cloudapi/ was reachable without authentication, and directory listing is now disabled for that path.
Defects. 43 resolved issues. Among them: a cell crash when database connections reached the limit of 500, snapshot size dropping to 0 in chargeback events, the large-VM relocation timeout raised from 5 minutes to 8 hours, and old jobs replaying after a restart (KB 406271).

Check these before you upgrade:

The update fails if the SAN of the PostgreSQL certificate does not contain the database IP address. Appliances with the default self-signed certificates are not affected.
The current VCD Management Packs and Content Packs for Operations are incompatible. The release notes list no workaround.
Linux password reset in guest customization now needs the enable-gosc-set-password setting in VMware Tools.
Updating through the Broadcom repository fails on a libstdc++ package. Use an update package instead.
Moving VCF Operations to 9.1.1 requires a VCF 9 fleet, with a strict 1:1 relationship between VCF Operations and VCF Automation.
Extensions: CSE, DSE and OSE are RPQ only. VCDA and vRealize Orchestrator are supported. vRealize Operations is not.

The three migration steps

Broadcom's blog lists them:

Run the Environment Assessment Tool (EAT). It collects metadata about your deployment and supports VCD 10.4.x to 10.6.x. If your last submission is older than six months, send the results again.
Request the migration documentation. Email vcdeat.pdl@broadcom.com with the subject "Requesting VCD to VCF A Migration Documentation". It is not public.
Connect the VCF Automation Migration Service to Cloud Director and migrate step by step. The VCF 9.1 release notes describe an in-place migration with a Migration Tool.

One official limit: PVDCs on the same NSX-T that are backed by several vCenters are not migrated, and the evaluation returns CANNOT_MIGRATE_PVDCS_ACROSS_MULTIPLE_VCENTERS. KB 451182 lists no workaround.

What Broadcom does not publish

The detailed migration documentation, the exact impact on tenants and the rollback procedure are not public. Anything beyond that would be speculation. Ask for the documentation and read it before you commit to a plan.

Third-party opinions

Two providers have published guides. These are their views, not Broadcom statements.

Consult Circle suggests planning the migration per organization, warns that "minimal downtime is not no downtime", and points to the Mobility Operator in VCF 9.1 for moving running VMs.

Arora Cloud describes two routes, in place or a parallel build migrated in waves, and recommends piloting a low-risk tenant first.

What to do now

Run the EAT and email the results.
Check that your current version has a supported path to 10.6.2.
Check the SAN of your PostgreSQL certificate.
List the Operations packs and extensions you use against the notes above.
Request the migration documentation.