When Legacy Multi-Tenancy Meets VCF Automation: Why Cloud Accounts Fail After Migration
Introduction
Organizations migrating from legacy VMware Aria Automation multi-tenancy into VCF Automation 9 are discovering that migration is not always a lift-and-shift exercise. One of the more disruptive issues surfaces when administrators attempt to add a cloud account and receive the error:
“The specified vCenter or NSX Manager is already associated with an existing region and cannot be reused.”
This issue, documented in Broadcom KB 408990, is often misunderstood as a simple cloud account registration problem. In reality, it exposes a deeper architectural shift between legacy Aria Automation multi-tenancy and VCF Automation’s organization model. (https://knowledge.broadcom.com/external/article/408990/unable-to-add-a-cloud-account-on-vcf-aut.html)
For organizations migrating environments that relied heavily on shared infrastructure, provider-style tenancy, Virtual Private Zones (VPZs), or overlapping tenant resource consumption, this can become a major roadblock.
The Root Cause: It’s Not Just a Cloud Account Error
In legacy Aria Automation, multi-tenancy often allowed patterns such as:
- Multiple tenants consuming shared vCenter infrastructure
- Shared NSX Managers across tenants
- Provider-managed resource allocation using quotas
- Virtual Private Zones and provider image management
- Shared infrastructure models supported through Aria Suite Lifecycle Manager
Many customers built mature service provider-style architectures around these capabilities.
However, VCF Automation 9 changes those assumptions.
New VCF Automation Rules
According to Broadcom’s documented behavior:
Supported:
- Multiple All Apps Organizations can share the same vCenter and NSX Manager using region quotas.
Not Supported:
- An All Apps Organization and a VM Apps Organization cannot share the same vCenter or NSX Manager.
- Two VM Apps Organizations cannot share the same vCenter or NSX Manager.
That means infrastructure reuse models that worked in Aria Automation may now directly conflict with VCF Automation’s design. (https://knowledge.broadcom.com/external/article/408990/unable-to-add-a-cloud-account-on-vcf-aut.html)
Why This Hits Migrated Multi-Tenant Environments Hard
Legacy Design Assumptions Persist After Migration
During migration, many organizations assume:
- Existing vCenter-to-tenant mappings will remain valid
- Shared regions can be reused across new organizations
- Tenant separation models map cleanly into VCF Automation organizations
Often, they do not.
When an existing vCenter endpoint is already associated with an All Apps Organization, VCF Automation blocks attaching it to a VM Apps Organization.
The system is behaving as designed.
The migration exposed an architectural incompatibility.
The Bigger Problem: Multi-Tenancy Deprecation Impacts
This issue rarely appears alone.
Broadcom’s upgrade prechecks explicitly warn that several shared infrastructure multi-tenancy capabilities from Aria Automation may not carry forward into VCF Automation 9. (https://knowledge.broadcom.com/external/article/389563/essential-prechecks-for-a-successful-vcf.html)
This can impact:
1. Virtual Private Zones (VPZ)
Provider isolation models may not translate cleanly.
2. Shared Infrastructure Tenancy
Shared vCenter or NSX designs may require redesign.
3. Cloud Account Reuse
Cloud accounts tied to legacy assumptions can trigger registration conflicts.
4. Tenant Lifecycle Challenges
Some legacy tenant constructs are difficult—or impossible—to remove cleanly.
Broadcom also notes:
- Multi-tenant tenants in Aria Automation cannot simply be deleted once associated. (https://knowledge.broadcom.com/external/article/389054/unable-to-delete-a-aria-automation-tenan.html)
- Shared Orchestrator models can create additional tenant boundary complications. (https://knowledge.broadcom.com/external/article/384372/multitenant-aria-automation-systems-whic.html)
Common Migration Scenario That Breaks
Before Migration (Aria Automation)
Tenant A:
- Uses vCenter-01
- Uses NSX-01
Tenant B:
- Uses same vCenter-01
- Uses same NSX-01
This works under shared multi-tenancy.
After Migration (VCF Automation)
Organization A (All Apps)
- Attached to vCenter-01
Organization B (VM Apps)
- Attempts to use vCenter-01
Result:
Cloud account creation fails.
Error:
Endpoint already associated with existing region.
Exactly as documented in KB 408990. (https://knowledge.broadcom.com/external/article/408990/unable-to-add-a-cloud-account-on-vcf-aut.html)
Why This Is More Than a Technical Error
This creates operational challenges:
Resource Model Redesign
Teams may need:
- Dedicated vCenter instances per organization
- Dedicated NSX Managers per organization
- New region boundaries
- Reworked quota models
Potential Service Disruption
If discovered late:
- Migration timelines slip
- Cloud onboarding stalls
- Tenant cutovers fail
- Consumers lose provisioning access
Governance Changes
Provider-style multi-tenancy often needs redesign into:
- Organizational isolation
- Infrastructure segmentation
- New operational ownership boundaries
How to Fix It
Immediate Workarounds
Option 1: Use a Different vCenter or NSX Endpoint
Broadcom’s primary recommendation:
Use a vCenter endpoint not already associated with another conflicting organization. (https://knowledge.broadcom.com/external/article/408990/unable-to-add-a-cloud-account-on-vcf-aut.html)
Option 2: Remove the Existing Organization
If the original organization is obsolete:
- Decommission it
- Remove its region association
- Re-register the cloud account
This requires planning and impact analysis.
Option 3: Redesign the Migration Architecture
Often the correct answer.
Treat migration as:
- Architecture modernization
- Not a platform upgrade
Rebuild:
- Organization design
- Cloud account mappings
- Region strategy
- Tenant separation model
Best Practices Before Migrating from Legacy Multi-Tenancy
1. Inventory Existing Shared Dependencies
Document:
- Shared vCenters
- Shared NSX Managers
- Shared regions
- Tenant-to-resource mappings
2. Review VCF Automation Upgrade Prechecks
Do not skip Broadcom’s prechecks. They explicitly call out multi-tenancy risks. (https://knowledge.broadcom.com/external/article/389563/essential-prechecks-for-a-successful-vcf.html)
3. Validate Cloud Account Ownership Before Migration
Determine:
- Which organization owns each endpoint
- Which endpoints cannot be shared under the new model
4. Test Organization Models First
Build a pilot:
- All Apps only
- VM Apps only
- Mixed organization scenarios
Test endpoint registration before production migration.
5. Assume Some Legacy Designs Must Be Rebuilt
This is often the hardest lesson.
Migration may require redesign.
Not every Aria Automation multi-tenant pattern survives in VCF Automation.
Key Takeaway
The cloud account error in KB 408990 is not simply a registration bug.
It is often a symptom of:
- Legacy multi-tenancy assumptions
- Shared infrastructure conflicts
- Organizational model changes in VCF Automation
- Architectural incompatibilities exposed during migration
And for many enterprises, the real work is not fixing the cloud account.
It is rethinking the tenancy model.
Final Thoughts
If you are migrating from older Aria Automation environments that relied on:
- Provider multi-tenancy
- Shared cloud accounts
- Virtual Private Zones
- Shared infrastructure across tenants
Do not treat VCF Automation migration as a technical upgrade alone.
Treat it as an architecture transformation project.
Otherwise, this cloud account error may be the first of several surprises.
I have created this feature request to get the possibility back for having multiple VM Apps orgs access to the same vCenter/NSX. https://vcf.ideas.aha.io/ideas/VCF-I-3889
References
Broadcom KB 389054 – Unable to delete an Aria Automation tenant in a multi-tenancy environment. (https://knowledge.broadcom.com/external/article/389054/unable-to-delete-a-aria-automation-tenan.html)
Broadcom KB 408990 – Unable to add a cloud account on VCF Automation for VM Apps org. (https://knowledge.broadcom.com/external/article/408990/unable-to-add-a-cloud-account-on-vcf-aut.html)
Broadcom KB 389563 – Essential Prechecks for a Successful VCF Automation Upgrade. (https://knowledge.broadcom.com/external/article/389563/essential-prechecks-for-a-successful-vcf.html)