VCD TO VCFA MIGRATION
What VCF Automation actually is, how the migration path from VMware Cloud Director works, what it does to your tenants, and how to phase a programme that cannot fail quietly.
For most VMware Cloud Service Providers, Cloud Director is not a component of the platform. It is the platform. It is where tenants log in, where organisations and virtual data centres are defined, where the catalogue lives, and in many cases where the metering that produces the invoice originates. Replacing it is not an infrastructure project with a business impact. It is a business project with an infrastructure component.
That replacement is now underway. VMware Cloud Foundation 9 introduced VCF Automation, which supersedes both Aria Automation and VMware Cloud Director. VCF Automation 9.1 added a Migration Tool for moving from Cloud Director in place. And Cloud Director 10.6.2, released in September 2026, is explicitly a migration release: a hardened baseline with security fixes and interoperability validation, whose end of life date is tied to that of VCF 9.1.
VCD to VCFA Migration
Planning a Cloud Director to VCF Automation programme?
Consult Circle runs provider migrations end to end - assessment, construct mapping, platform design, tenant migration and Cloud Director decommissioning.
Explore our VMware Cloud Director servicesIn this article
- Why Cloud Director is being replaced and what that means commercially
- What VCF Automation actually is, architecturally
- What carries over from Cloud Director and what does not
- How tenant constructs map between the two platforms
- The two migration routes, compared
- The migration tooling and the assessment stage
- What your tenants experience, and how to manage it
- Phasing a programme across a live tenant base
- A readiness checklist, common failures and an FAQ
1. Why This Is Happening, and What It Means Commercially
VCF Automation is not a rebranding exercise and it is not the next version of Cloud Director. It is a new cloud management platform built for VCF 9, which absorbed the roles previously filled by two separate products. Cloud Director provided multi-tenancy for service providers. Aria Automation provided self-service automation for enterprises. VCF Automation does both, inside the VCF platform rather than alongside it.
For a provider, the commercial consequences arrive before the technical ones. Cloud Director 10.6.2 shares its end of life with VCF 9.1, which means the platform your tenants log into now has a lifecycle bound to a release you do not control the timing of. Broadcom have not published a standalone end of life date for Cloud Director in the way they did for vSphere 7, and we would encourage you to check the official Product Lifecycle Matrix for the authoritative position rather than working from any blog, including this one. What is unambiguous is the direction: the migration tooling exists, the tenancy investment is landing in VCF Automation, and the Cloud Director codebase is being carried forward inside VCF as Tenant Manager.
Plan against the trajectory rather than against a deadline. A provider with a hundred tenants cannot begin this in the quarter the deadline is announced, because the constraint is not engineering capacity. It is how many tenant conversations you can have, how many contract variations you can process, and how many change windows your customers will grant you.
2. What VCF Automation Actually Is
Two inheritances, one platform
VCF Automation has a provider-facing layer and a tenant-facing layer, and they come from different places. The provider layer, Tenant Manager, is built on the Cloud Director codebase. Its interface and APIs will feel recognisable to anyone who administers Cloud Director today, which considerably reduces the retraining burden on your own operations team.
The tenant layer is different. It inherits heavily from Aria Automation and presents a modernised interface with capabilities that will look genuinely new to a customer whose mental model is the Cloud Director tenant portal. This asymmetry is the defining characteristic of the whole programme. Your engineers will adapt quickly. Your customers will not, because for them the change is total.
How it is deployed
VCF Automation is normally deployed through VCF Operations Fleet Management, the lifecycle component that replaced the embedded Aria Suite Lifecycle. It can also be deployed by the VCF Installer as a day zero action during bring-up, alongside the rest of the platform, at the cost of less flexibility over networking topology. For a provider migrating an existing estate, the Fleet Management route is usually the right one because it lets you place the platform deliberately.
Underneath, VCF Automation consists of one or more VMware Management Services Platform appliances running containerised services in a Kubernetes cluster. This is worth internalising early, because it changes how the platform is sized, patched, monitored and troubleshot compared with the Cloud Director cell model that most providers have operated for a decade.
The resource model
Where Cloud Director gave tenants organisation virtual data centres carved from provider virtual data centres, VCF Automation presents infrastructure to consumers largely through Namespaces, which are Kubernetes namespaces managed by the vSphere Supervisor with assigned compute resources, storage classes and NSX VPCs. Organisations remain. Projects appear. The abstraction has shifted toward the Supervisor and away from the vApp-centric model, and that shift is where most of the mapping friction in a migration comes from.
3. What Carries Over and What Does Not
- Carries over recognisably. Organisations as a tenancy boundary, the provider administration model, role-based access control as a concept, and blocking tasks for inserting external automation into provider workflows. Your operational habits mostly survive.
- Carries over transformed. Networking, storage and compute allocation all exist but through different constructs. Edge Gateways, organisation networks, IP Spaces and storage policies each have a counterpart, and none of them is a like for like rename. This bucket is where the design work lives.
- Does not carry over. The tenant experience as your customers know it, any tenant-side integration written against the Cloud Director tenant API, custom UI plugins, and any operational process that assumes the vApp as the primary unit of consumption.
The third bucket determines the programme timeline, and it is almost entirely outside your control, because the work sits with your tenants. A provider can rebuild its own tooling on a schedule. It cannot rebuild a customer's automation for them, and it cannot make them prioritise it.
4. How Tenant Constructs Map
This table gives the shape of the mapping. Treat it as an orientation aid rather than a specification, because the detail varies by release and by how your existing environment was designed. Our construct mapping reference works through each row in detail.
| Cloud Director construct | Nearest VCF Automation equivalent | Planning note |
|---|---|---|
| Organization | Organization | The closest thing to a direct carry-over, and the natural migration unit |
| Provider VDC | Region and workload domain resources | The provider-side capacity model changes shape rather than translating |
| Organization VDC | Project with Namespaces | The central mapping decision, and rarely one to one |
| vApp | No direct equivalent | Workloads land in Namespaces; vApp-centric process needs rethinking |
| Org VDC network | VPC subnet | Addressing is preserved only if it is planned for deliberately |
| Edge Gateway | VPC and Transit Gateway constructs | Firewall services delivered through vDefend in 9.1 |
| IP Spaces | External IP Blocks | Mirror these before moving anything, not during |
| Storage policy | Storage class | Confirm the protection level actually matches, rather than the name |
| Catalog | Content library and catalog items | Template estates usually need rationalising anyway |
| Rights bundles and roles | RBAC model | Rebuild deliberately rather than transliterating |
Table 1 - Cloud Director to VCF Automation construct mapping at a glance.
If one line deserves early attention it is IP Spaces. Mirroring them into External IP Blocks before any workload moves is what makes address preservation possible, and address preservation is what determines whether a tenant migration is an infrastructure event or a project for the tenant's own application teams. Where re-addressing genuinely cannot be avoided, network extension buys time, and it should have an expiry date written down at the moment it is created.
5. The Two Migration Routes
In-place migration
VCF Automation 9.1 provides a Migration Tool for performing an in-place migration from Cloud Director, with the Migration Service automating the transfer of workloads and configurations into VCF 9.1 with minimal downtime. Access to the tooling and its documentation is arranged through your Broadcom representative rather than being generally published.
This route is attractive when your Cloud Director estate is reasonably standard, your tenants are numerous and small, and the prospect of individually negotiating a hundred migrations is worse than the prospect of a smaller number of larger, riskier events. The trade-off is that the rollback position is weaker, because you are converting the environment your tenants are currently being served from.
Side-by-side migration
Build VCF Automation as a new environment, stand up the provider constructs cleanly, and move organisations across one at a time. Cloud Director continues serving unmigrated tenants throughout. This is the route most providers with significant or contractually sensitive tenants take, because each migration is scoped to a single customer, can be scheduled with them, and can be abandoned without affecting anybody else.
The costs are real: capacity for both platforms, parallel metering so that billing remains correct while tenants are split across two systems, and a longer overall programme. What you buy is the ability to fail safely, which on a platform that carries customer workloads is usually worth more than the saving.
| Factor | In-place | Side-by-side |
|---|---|---|
| Additional capacity | Minimal | Seed footprint, reducing as tenants move |
| Rollback per tenant | Limited | Strong, source remains intact |
| Tenant scheduling | Grouped, harder to negotiate | Individual, easier to negotiate |
| Design quality achieved | Constrained by existing model | Clean, if you resist copying |
| Programme duration | Shorter, less predictable | Longer, more predictable |
| Suits providers with | Many small standard tenants | Fewer large or sensitive tenants |
Table 2 - Choosing between in-place and side-by-side migration.
6. The Tooling and the Assessment Stage
The current documented path begins with assessment rather than with deployment.
- Run the Environment Assessment Tool against your Cloud Director deployment to collect environment-specific metadata about how it is actually configured.
- Send the results to your Broadcom Account Manager to request the migration documentation for your environment.
- Connect the VCF Automation Migration Service to Cloud Director and work through the migration step by step.
Two implications for planning. First, the assessment is a gate, and the sooner it runs the sooner you have a realistic picture, so treat it as a first-week activity rather than something that happens once the project is approved. Second, because the detailed documentation is issued in response to your assessment, your programme plan has an external dependency in it from the very start. Build that into the schedule.
Separately, be aware of how workload mobility has changed between releases. Under VCF 9.0, importing a vCenter-managed virtual machine into a VCF Automation Namespace could be done through the vCenter migrate option by changing the management layer, selecting the target VPC, subnet and storage class, but the workload required a reboot and re-addressing. VCF 9.1 introduced the Mobility Operator, a Supervisor service that allows running virtual machines to be migrated non-disruptively. For a provider, that is the difference between a tenant migration that needs an outage and one that does not.
7. What Your Tenants Experience
- The portal changes completely. The tenant-facing experience derives from Aria Automation rather than Cloud Director. Your customers are not getting an updated version of something familiar, they are getting a new product. Every runbook, screenshot and internal training document they hold becomes wrong on cutover day.
- Tenant API integrations break. Any customer who automated against the Cloud Director tenant API has work to do, and it is work they did not plan for and are not being paid to do. Identify these customers early, because they set your programme timeline.
- Addressing may or may not survive. It can be preserved with deliberate planning around IP Spaces and External IP Blocks. Without that planning, tenants re-address, which turns your infrastructure project into their application project.
- Billing must remain correct throughout. While tenants are split across two platforms, metering runs in both. Getting this wrong is more damaging to the relationship than a technical fault, because it is visible to the customer's finance team rather than their engineers.
- Support and escalation paths change. Your own service desk needs to know which platform a given tenant is on before they can help them, for as long as the split persists.
Tenant communication starts months before the first migration, not weeks. Providers who treat this as a change notification exercise discover that their largest customers have opinions, and those opinions arrive late enough to reshape the plan.
8. Phasing the Programme
| Phase | What happens | Typical duration |
|---|---|---|
| Assessment | Environment Assessment Tool, tenant inventory, integration discovery | 2 to 4 weeks |
| Design | Construct mapping, VCF Automation architecture, RBAC and network design | 4 to 8 weeks |
| Build and pilot | Platform build, internal tenant migrated end to end, runbook produced | 4 to 8 weeks |
| Friendly tenants | Small, tolerant customers migrated first to prove the process | 4 to 6 weeks |
| Main migration | The bulk of the tenant base, paced by customer availability | 3 to 9 months |
| Complex tenants | Heavy API integration, unusual networking, contractual constraints | Variable, often longest |
| Decommissioning | Cloud Director retired, capacity reclaimed, documentation handed over | 2 to 4 weeks |
Table 3 - A workable programme shape for a provider tenant base.
Migrate your own internal tenant first. Every provider has one, whether it is a lab, a demo environment or the systems the business runs on itself, and it is the only tenant you can afford to get wrong. If your pilot is a paying customer, the pilot is not a pilot.
Sequence the rest by tolerance rather than by size. The instinct is to start with small tenants because they seem lower risk, but small and tolerant are not the same thing, and a small customer with a brittle integration is a worse first migration than a large one with an engaged technical team.
9. Readiness Checklist
Platform position
- Current Cloud Director version recorded, with a plan to reach 10.6.2 as the migration baseline
- Lifecycle position confirmed against the Broadcom Product Lifecycle Matrix rather than inferred
- Target VCF and VCF Automation versions agreed, with 9.1 or later confirmed if non-disruptive workload mobility matters
- Environment Assessment Tool run and results submitted to your Broadcom account manager
- Hardware and capacity position established for the target platform
Tenant estate
- Full tenant inventory with organisation count, virtual data centre count and workload count per tenant
- Tenants using the Cloud Director tenant API identified, since they set the programme pace
- Custom UI plugins and provider extensions catalogued, with a decision recorded for each
- Per-tenant addressing requirements established, specifically whether addresses must be preserved
- Contractual constraints reviewed: notice periods, service credits, change control obligations
Design decisions
- Migration route chosen, in-place or side-by-side, with the reasoning recorded
- Organisation VDC to Project and Namespace mapping agreed as a pattern rather than per tenant
- IP Spaces mirrored into External IP Blocks before any workload moves
- RBAC model rebuilt deliberately rather than transliterated from existing rights bundles
- Storage class definitions confirmed to match existing protection levels in substance
- Catalogue estate rationalised rather than migrated wholesale
Operational readiness
- Parallel metering designed and tested before the first tenant moves
- Service desk briefed on which platform serves which tenant, with a lookup they can use under pressure
- Tenant communication plan drafted, with the first notification issued months ahead of the first migration
- Write-freeze discipline agreed for migrated organisations, so nothing is changed on the old platform after cutover
- Exit date set for the parallel running period, with an owner attached
- Rollback trigger and procedure written per tenant migration and rehearsed at least once
10. Where These Programmes Go Wrong
Treating it as an infrastructure project. The infrastructure is the straightforward part. The programme is paced by tenant conversations, contract variations and customer engineering availability, none of which respond to adding engineers.
Reproducing the Cloud Director design in VCF Automation. Providers frequently attempt to recreate their existing organisation virtual data centre model exactly, which fights the platform and preserves compromises that existed for reasons that no longer apply.
Discovering tenant API integrations late. These customers need the longest lead time and they are invisible in an infrastructure inventory. Ask them directly, early, and do not rely on usage data alone.
Leaving addressing until the migration design. Address preservation is decided at the point IP Spaces are mirrored, which is well before the first workload moves.
Running two platforms without an exit date. Parallel running is a legitimate phase and a terrible permanent state. Without a date and an owner, the last dozen tenants never move and Cloud Director stays alive for years.
Getting billing wrong during the split. A migration that is technically flawless and produces one incorrect invoice will be remembered for the invoice.
Frequently Asked Questions
Is VMware Cloud Director end of life?
Broadcom have not published a standalone end of life date in the way they did for vSphere 7, and the authoritative source is the Product Lifecycle Matrix rather than any blog. What is documented is that Cloud Director 10.6.2 shares its end of life with VCF 9.1, that VCF Automation supersedes Cloud Director, and that the migration tooling now exists. Our Cloud Director end of life guide covers the lifecycle position in detail.
Is VCF Automation just Cloud Director renamed?
No. It is a new platform that absorbed the roles of both Cloud Director and Aria Automation. The provider layer, Tenant Manager, is built on the Cloud Director codebase and will feel familiar. The tenant layer derives from Aria Automation and will look entirely new to your customers. See VCF Automation for Cloud Director administrators.
Can we run Cloud Director and VCF Automation side by side?
Yes, and if you take the side-by-side route you will do so for months. That is expected and manageable, provided metering runs correctly across both, your service desk knows which tenant is where, and the parallel period has a documented exit date. Coexistence is not the risk. Coexistence without an end date is.
Will our tenants keep their IP addresses?
They can, if the work is done. Mirror IP Spaces into External IP Blocks before anything moves, and use network extension where re-addressing genuinely is not feasible yet. Without that preparation, tenants re-address, which converts your migration into a project for their application teams.
How much downtime does a tenant migration need?
It depends on your target version. Under VCF 9.0, importing workloads into a VCF Automation Namespace required a reboot and re-addressing. VCF 9.1 introduced the Mobility Operator, which allows running virtual machines to be migrated non-disruptively.
How long does the whole programme take?
For a provider with a meaningful tenant base, six to eighteen months from assessment to Cloud Director decommissioning. The spread is almost entirely explained by tenant count, integration complexity and how quickly customers engage.
What should we do first?
Run the Environment Assessment Tool and inventory your tenants, specifically identifying which of them have automated against the Cloud Director tenant API. Those two activities cost very little and between them determine the shape of everything that follows.
Where Consult Circle Fits
This transition is unusual in that the technical difficulty is moderate and the consequences of getting it wrong are severe, because the thing being replaced is the interface between you and the customers who pay you. Most providers will do it once, which is not enough repetitions to develop judgement about which tenants to sequence where.
We work on this as continuous practice rather than as an occasional project. Engagements run from a fixed assessment through construct mapping and platform design to hands-on tenant migration and decommissioning, and we are equally happy to review a plan your team has already built.
Consult Circle
Get a second opinion on your assessment results
Run the Environment Assessment Tool, find out which tenants have automated against the tenant API, and we will talk through what it means for a provider your size.
Talk to a VCD specialistRelated guides in this series
- VMware Cloud Director End of Life: What the VCF Automation Transition Means for Your Provider Business
- VCF Automation for VMware Cloud Director Administrators: What Carries Over and What Does Not
- Mapping VMware Cloud Director Constructs to VCF Automation: Org VDCs, Edge Gateways, Catalogs and IP Spaces
- VMware Cloud Director 10.x vs VCF Automation 9.1: A Feature Parity Comparison for Service Providers
- The Complete VCD to VCF Automation Migration Checklist: 72 Checks for Service Providers
- The VMware Cloud Director API for Day-to-Day Operations: The Calls You Will Actually Use
- VMware Cloud Director Common Errors and Known Issues: Symptoms, Causes and Workarounds