Mapping VMware Cloud Director Constructs to VCF Automation: Org VDCs, Edge Gateways, Catalogs and IP Spaces

VCD TO VCFA CONSTRUCT MAPPING

A reference for the mapping that causes the most friction in a VCD to VCFA migration, with the design decisions each construct forces and the order to make them in.

Ask anyone who has planned a Cloud Director to VCF Automation migration where the difficulty sits and the answer is consistently the same: not the tooling, not the platform build, but working out what your existing tenancy constructs become on the other side. The tooling will move things. It cannot decide what they should be.

This is a design exercise disguised as a translation exercise, and that framing matters. Several of these relationships are not one to one. A few have no equivalent at all. Treating the mapping as a lookup table produces a VCF Automation environment that is a slightly worse version of your Cloud Director environment, which is a poor return on a migration.

In this article

• The mapping at a glance
• Organizations, the one clean carry-over
• Provider VDCs and the capacity model
• Organization VDCs, the decision that shapes everything
• vApps, and what to do about their absence
• Networking: org networks, Edge Gateways and IP Spaces
• Storage policies and catalogues
• RBAC and extensibility, plus the order to decide in

1. The Mapping at a Glance

Table 1 - The full construct mapping at a glance.

\n \n \n

2. Organizations: The Clean Carry-Over

Organisations remain the tenancy boundary and are the closest thing to a direct equivalent in the whole mapping. That makes them the natural migration unit: you migrate an organisation, you validate it with the tenant, you move to the next one.

The decision worth making deliberately is whether to preserve your existing organisation structure or use the migration to rationalise it. Providers who have been running Cloud Director for years frequently carry organisations created for customers who left, for pilots that ended, or for internal purposes that have since been absorbed elsewhere. Rationalising them is easy at this moment and hard afterwards.

3. Provider VDCs and the Capacity Model

The provider-side capacity model does not translate so much as change shape. Where a provider virtual data centre carved a slice of vSphere resource for allocation to tenants, VCF Automation expresses provider capacity through Regions and the resources of the underlying workload domains.

The design questions this forces are worth answering explicitly rather than by default. How many workload domains do you actually need, given that your Cloud Director provider VDC boundaries may have been drawn around hardware generations, storage tiers or acquisitions rather than around anything you would choose today. Where tenants are placed, and whether that placement is still driven by the reasons that originally drove it. Whether the tiering you offer commercially still maps to a technical boundary or has become a pricing construct with no infrastructure behind it.

Most providers find at least one provider VDC that exists for a reason that expired years ago. The migration is the cheapest opportunity you will get to remove it.

4. Organization VDCs: The Decision That Shapes Everything

This is the central mapping and it is rarely one to one. In VCF Automation, tenant infrastructure is presented substantially through Namespaces, which are Kubernetes namespaces managed by the vSphere Supervisor with assigned compute resources, storage classes and NSX VPCs, organised within Projects inside an organisation.

So an organisation VDC becomes some arrangement of Project and Namespaces, and how you arrange them is a genuine design choice with consequences for quota, isolation, self-service and how your tenants think about what they are buying.

The patterns providers actually choose

• One Project per organisation VDC. The most direct translation and the easiest to explain to an existing tenant. It preserves the commercial construct customers already understand, and it inherits whatever arbitrariness existed in the original boundaries.
• One Project per tenant environment. Production, test and development as separate Projects regardless of how they were carved before. Cleaner conceptually, and it frequently reveals that the existing organisation VDC boundaries were doing this badly already.
• Project per application or business unit. Suits larger, more sophisticated tenants who were already using organisation VDCs this way. Overkill for a customer with twelve virtual machines.
• Namespace granularity as the differentiator. A smaller number of Projects with Namespaces providing the finer isolation. This is where the platform is most naturally expressive and where most providers end up after a first attempt at direct translation.

The advice we give consistently is to design one pattern and apply it, with exceptions handled deliberately rather than per tenant. A provider with sixty tenants and sixty bespoke mappings has not migrated a platform, it has created sixty small platforms that happen to share hardware.

The commercial dimension matters here too. If your pricing and your contracts are expressed in terms of organisation VDCs, changing the shape of that construct has billing and contractual consequences. Involve whoever owns pricing in this decision at the design stage, not after the first tenant has moved.

5. vApps: Designing Around an Absence

There is no direct equivalent to the vApp, and this is the mapping that produces the most surprise because the vApp is so deeply embedded in how Cloud Director is used. Workloads land in Namespaces. The vApp as a container with its own networks, start order and lifecycle does not carry across in that form.

• Operational process. Any runbook, automation or provider procedure that treats the vApp as the primary unit needs redesigning around the new consumption model rather than translating.
• Tenant documentation and expectations. Customers who think in vApps need to be told what replaces that thinking, and told before cutover rather than discovering it.
• Application grouping. Where vApps were being used meaningfully to group an application's components, that grouping needs to be expressed some other way, and where they were being used simply as folders, that is worth knowing too.

A useful discovery exercise is to sample how vApps are actually used across your tenant base. Providers are frequently surprised to find that most contain a single virtual machine, which makes the migration considerably simpler than the conceptual gap suggests.

6. Networking: Org Networks, Edge Gateways and IP Spaces

Networking is the area with the most moving parts and the one where a mistake is most visible to the tenant, because it either preserves their addressing or it does not.

IP Spaces to External IP Blocks, and why this is first

This is the item to decide before anything else in the entire migration. Mirroring IP Spaces into External IP Blocks before any workload moves is what makes address preservation possible. Leave it until the migration design and you have already made the decision by default, and the default is that tenants re-address.

Address preservation is not a technical nicety for a provider. It is the difference between a migration your tenant experiences as an infrastructure event and one that becomes a project for their application teams, with their costs, their timelines and their opinion of your programme attached. Where re-addressing genuinely cannot be avoided, network extension buys time, and every extension should be created with an expiry date and an owner recorded at the moment it is created.

Org VDC networks to VPC subnets

Organisation networks become subnets within NSX VPCs. The construct is different enough that routed, isolated and direct network types need thinking through against the VPC model rather than mapped mechanically. VCF Automation 9.1 also introduced settings for default private VPC and private Transit Gateway IP blocks, which is worth understanding when you are establishing the pattern that all tenants will inherit.

Edge Gateways to VPC and Transit Gateway constructs

The Edge Gateway's responsibilities are distributed differently. Routing and connectivity sit with VPC and Transit Gateway constructs. Firewalling is delivered through vDefend, and VCF Automation 9.1 introduced vDefend Distributed Firewall and Gateway Firewall support directly within the platform, with provider administrators able to delegate firewall services to organisation administrators to manage their own Transit Gateway Firewall and Distributed Firewalls. Out-of-the-box security profiles provide uniform vDefend security for new and existing VPCs, with role-based access control labelling supporting dynamic security groups.

For most providers this is an improvement rather than a compromise, particularly if you have been fielding tenant requests for firewall self-service that Cloud Director made awkward to satisfy. It also means the security model is a design decision in its own right rather than a translation.

Load balancing

VCF Automation 9.1 introduced full self-service support for Avi Load Balancer. If load balancing was a managed service you delivered on request in Cloud Director, this is an opportunity to change what you sell as much as how you deliver it, and that decision belongs with your product team rather than only with engineering.

7. Storage Policies and Catalogues

Storage policies to storage classes

The intent maps cleanly and the substance needs verifying. A storage class with a familiar name is not necessarily delivering the same protection level, and a tenant whose workload silently lands on weaker protection has been given a worse service without being told. Map these by what they actually provide rather than by what they are called, and confirm the resulting assignment per tenant before their migration completes.

This is also a reasonable moment to rationalise. Providers accumulate storage policies over years, some of which exist to serve a single customer requirement that has since lapsed.

Catalogs to content libraries

Catalogues become content libraries and catalog items. Mechanically this is among the more straightforward mappings. Practically, it is the part of the migration where rationalisation pays the most obvious dividend, because catalogue estates grow without bound and nobody ever deletes a template.

Audit what is actually being deployed before deciding what to migrate. In most provider estates a small number of templates account for the overwhelming majority of deployments, and carrying the remainder forward costs storage, maintenance and tenant confusion for no return.

8. RBAC and Extensibility

Rights bundles and roles have a counterpart in the VCF Automation RBAC model, and the strong recommendation is to rebuild rather than transliterate. Cloud Director rights bundles in a mature provider estate are archaeology: layers of adjustment made for particular customers at particular moments, most of which nobody now remembers the reason for. Reproducing them faithfully preserves that archaeology in a new platform.

Design the roles you would want if you were starting today, validate them against what tenants actually do, and treat any gap as a question rather than as an omission to be patched.

On extensibility, blocking tasks continue to exist and serve the same purpose of inserting external automation such as CMDB updates or metadata tagging into a workflow. The scope has narrowed: they are tied to provider workflows in Tenant Manager. Any extensibility that depended on blocking tenant workflows needs a different approach, and identifying those dependencies is a discovery item rather than something to find during cutover.

9. The Order to Decide In

1. IP Spaces and address preservation, because this must be settled before anything moves.
2. Provider capacity model, since it determines where tenants can be placed.
3. Organization VDC pattern, because it shapes quota, isolation and the commercial construct.
4. Networking design, following from the organisation VDC decision.
5. Security model, including what firewall capability is delegated to organisation administrators.
6. Storage class definitions, verified against existing protection levels.
7. Catalogue rationalisation, which can proceed in parallel once the pattern is set.
8. RBAC model, designed against the platform you have now defined rather than the one you left.

Construct Mapping Checklist

• IP Spaces inventoried and mirrored into External IP Blocks before any workload moves
• Per-tenant address preservation requirement established, tenant by tenant rather than as a blanket assumption
• Network extension candidates identified, each with an expiry date and a named owner
• Provider VDC boundaries reviewed against whether the original reasons still apply
• A single organisation VDC to Project and Namespace pattern designed, with exceptions handled deliberately
• Pricing and contractual implications of the organisation VDC pattern reviewed with whoever owns commercials
• vApp usage sampled across the tenant base to establish how much genuine grouping exists
• Operational runbooks audited for vApp-centric assumptions
• Storage classes mapped by protection level rather than by name, and confirmed per tenant
• Catalogue audited by actual deployment frequency, with a rationalisation decision recorded
• RBAC model designed fresh and validated against real tenant activity
• Blocking task dependencies identified, particularly any relying on tenant workflow scope

Frequently Asked Questions

What does an Organization VDC become in VCF Automation?

A Project containing Namespaces, though the arrangement is a design decision rather than a fixed translation. Namespaces are Kubernetes namespaces managed by the vSphere Supervisor with assigned compute resources, storage classes and NSX VPCs. Choose one pattern and apply it across the tenant base, handling exceptions deliberately.

Is there a vApp equivalent?

No direct one. Workloads are presented through Namespaces, so anywhere the vApp is the primary unit in your process, automation or tenant documentation, that content needs redesigning. Sample how vApps are actually used first, because many contain a single virtual machine and the practical gap is smaller than the conceptual one.

How do we preserve tenant IP addresses?

Mirror IP Spaces into External IP Blocks before any workload moves. This is the first decision in the whole mapping exercise, because leaving it until migration design means the decision has already been made by default and the default is re-addressing.

What happens to Edge Gateway firewall rules?

Firewalling moves to vDefend. VCF Automation 9.1 supports vDefend Distributed Firewall and Gateway Firewall directly, with the ability to delegate to organisation administrators and out-of-the-box security profiles for uniform policy. Treat this as a security design exercise rather than a rule-by-rule export and import.

Should we migrate our catalogue as it is?

Almost certainly not. Audit by actual deployment frequency first. In most provider estates a small number of templates account for the majority of deployments, and migrating the remainder carries storage, maintenance and tenant confusion forward for no benefit.

Can we keep our existing roles and rights bundles?

You can attempt to reproduce them and we would advise against it. Mature Cloud Director rights structures accumulate adjustments whose original reasons are long forgotten. Design the model you would want today and validate it against what tenants actually do.

How long does the mapping exercise take?

For a provider with a meaningful tenant base, four to eight weeks of design work, running in parallel with the platform build. It is the phase where compressing the schedule costs the most later, because every shortcut becomes a pattern replicated across every tenant.

Can Consult Circle do this mapping for us?

Yes. Construct mapping is the piece of work we are most often asked for on Cloud Director migrations, and it produces a design document you own outright and can hand to any delivery team.

Where Consult Circle Fits

The risk in this exercise is not error, it is fidelity. A team that knows Cloud Director well will produce a mapping that reproduces their existing environment accurately in a platform that works differently, and the result is a migration that costs a year and delivers the design they already had.

We run construct mapping as a defined engagement producing a design document with the decisions and their reasoning recorded, which is useful regardless of who delivers the migration afterwards. Where a team has already drafted a mapping, reviewing it before it becomes concrete is a cheaper way to find the problem.

Related guides in this series

• VMware Cloud Director to VCF Automation Migration: The Complete Guide for Service Providers
• 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
• 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