VIDM to Identity Broker Migration in VCF 9.x The Scripted Path for 5.x Upgraders
The identity layer is the riskiest thing to migrate. VCF 9.x ships a scripted, non-disruptive workflow that decouples the identity transition from the upgrade itself and that decoupling is the design
Every customer upgrading from VCF 5.2.x carries VMware Identity Manager (VIDM) history. And identity is the migration nobody wants to improvise: break the identity layer and nobody logs in to anything not vCenter, not NSX, not the operations tooling you’d use to fix it.
VCF 9.x addresses this with a scripted workflow that migrates users and groups from VIDM to the VCF Identity Broker non-disruptively. The mechanics are simple; the sequencing insight is what belongs in your upgrade runbook.
How the Migration Works
• The upgrade process deploys the Identity Broker as part of VCF Management Services it lands during the platform upgrade regardless of when you migrate identity.
• The migration script runs after the upgrade completes the platform transition and the identity transition are decoupled events.
• Existing users and groups are not impacted accounts migrate without disruption to active sessions or credentials.
• The Identity Broker then integrates with your chosen Identity Provider Azure AD/Entra, Okta, Ping, ADFS, or any OIDC-compliant IdP.
The Sequencing Insight
Because the script runs post-upgrade, the identity transition can be planned as its own change window with its own rollback consideration. Don’t bundle it into the upgrade weekend. Land the platform upgrade, validate the estate, run steady for a defined soak period, then execute the identity migration as a controlled follow-on. If anything misbehaves, you’re debugging one change, not two entangled ones.
This decoupling also creates the natural moment for identity hygiene. Customers with years of VIDM history typically carry group sprawl, orphaned mappings, and role assignments nobody remembers granting. The migration is the opportunity to rationalise group-to-role mappings deliberately rather than lifting-and-shifting VIDM constructs verbatim into the new broker. Budget the workshop; it pays back every quarter at access review time.
Post-Migration Architecture
Once on Identity Broker, the target-state disciplines from the identity field guide apply: three-node broker cluster for production, enterprise PKI for broker certificates, documented group-to-role mapping as an architectural artefact, MFA and conditional access enforced at the IdP, and service accounts on scoped API tokens rather than federated identities. The migration script gets you onto the broker; these disciplines are what make the broker estate operable at Day 365.
The Architect’s Takeaway
The VIDM migration is a solved problem mechanically Broadcom ships the script, and it’s non-disruptive by design. The architect’s value-add is sequencing and hygiene: decouple the identity change from the upgrade window, use the transition to rationalise years of accumulated group debt, and land on the Identity Broker with a mapping document the operations team can actually govern. Treat it that way and the riskiest layer in the upgrade becomes one of the cleanest.
Sources
• Broadcom Strengthen Zero Trust Platform Security and Resilience with VCF 9.1
• Broadcom Modernizing Infrastructure: VMware Cloud Foundation 5.2.x to 9.1 Upgrade Guide
Broadcom Announcing VCF 9.1: Modern Private Cloud Built for Efficiency and Resilience
