From Org VDC to Namespace: The Architect’s Field Guide to VCD → VCFA Migration

In July 2025 I wrote about navigating the shift from VMware Cloud Director to VCF Automation — what stays familiar, what changes, and why VCFA is not a rebranding exercise. That post answered the “what.” With VCF 9.1 now generally available and shipping an official VCD-to-VCFA Migration Tool, it is time to answer the harder question: how do you actually plan this migration?

This guide is written for cloud service providers and enterprise architects running Cloud Director today. It covers the two migration paths, a full construct-by-construct mapping, the networking decisions that will make or break your timeline, and a readiness checklist you can take into your planning workshop.

Why this is a migration, not an upgrade

Let’s be honest about what Cloud Director got right, because it explains why this transition deserves respect. VCD gave providers a battle-tested multi-tenancy model, a mature API that an entire ecosystem built against, and constructs — Org VDCs, Edge Gateways, vApps, catalogs — that thousands of operators know by muscle memory. Fifteen years of production hardening is not something you wave away with a version number.

VCF Automation keeps the best of that lineage — the provider-facing Tenant Manager is built on the VCD codebase, so the provider experience will feel familiar — but the underlying resource model is fundamentally different. VCFA delivers infrastructure through vSphere Supervisor namespaces and NSX VPCs, not through Org VDCs carved out of Provider VDCs. That means workloads, networking, and tenancy boundaries all land on new primitives. Your VMs move; your mental model migrates.

The payoff for making that jump is real: a single platform that serves VMs, Kubernetes (VKS), and AI workloads to the same tenants under the same quota and governance model, with self-service networking (vDefend firewalling, Avi load balancing, tenant-managed NAT/VPN) that VCD needed extensions and bolt-ons to approximate. VCF 9.1’s tenancy improvements are explicitly aimed at providers running hundreds of isolated tenants on shared infrastructure.

The two migration paths

There are exactly two credible strategies, and most providers will end up using both across their estate.

Path 1: In-place migration with the Migration Tool

New in VCFA 9.1, the Migration Tool performs an in-place migration of VCD workloads and configuration into VCF Automation. The critical planning facts:

• Your VCD environment must first be updated to the specific VCD version the tool requires — verify the current prerequisite in the official migration documentation before scheduling anything.
• The target is a deployed and configured VCF 9.1 landing zone — VCFA does not exist as a standalone product, so the fleet (SDDC Manager, VCF Operations, NSX, Supervisor-enabled workload domains) must be in place first.
• “In-place” refers to the workloads: the goal is migrating tenants and their VMs with minimal downtime, not a forklift.

Path 2: Side-by-side build and move

Stand up VCF 9.1 with VCFA greenfield, design your organizations and regions natively, and move workloads tenant by tenant. VM import into VCFA namespaces is a documented pattern — including VLAN-backed connectivity options (Distributed VLAN Connections attached to a tenant’s Transit Gateway) that let imported VMs keep their existing L2 networks during transition.

Construct mapping: VCD to VCFA

First, the picture. The left stack is what your operations team knows by muscle memory; the right stack is where each piece lands:

Now the detail. This is the table to keep open during every design session. “Closest equivalent” does not mean “identical behavior” — read the notes.

Networking: where the timeline is won or lost

Everything else in this migration is bookkeeping compared to networking. Three decisions dominate:

1. VPC-native or VLAN-extended? The clean end state is tenants inside NSX VPCs. But brownfield tenants have VMs on VLAN-backed networks with hardcoded IPs, external firewall rules, and neighboring physical systems. VCFA supports Distributed VLAN Connections and VLAN extension subnets precisely for this — imported VMs keep their L2 while the tenant’s Transit Gateway provides the routed path. Decide per tenant which networks extend and which re-IP into VPC subnets, and record it in your migration runbook.

For a VLAN-extended tenant, the provider-side sequence looks like this in practice:

1. Deploy the VNA cluster in NSX. In the VCF 9.1 networking model, Virtual Network Appliances take over the role Edge Nodes played — the tenant’s Distributed Transit Gateway (DTGW) needs them in place before any VLAN-backed connectivity works.
2. Create a shared Distributed VLAN Connection (VLAN-backed) that the DTGW uses as its uplink path. This is provider-scoped plumbing, created once.
3. Create a dedicated Distributed VLAN Connection per legacy subnet, using the exact VLAN ID of the existing portgroup the source VMs sit on. This is what preserves L2 adjacency for the imported workloads.
4. Configure the tenant’s region network connectivity to use the Distributed VLAN Connection option, attaching the DTGW to the shared connection, then assign the dedicated per-subnet connection to the organization (Organization > Networking > Connections).
5. Import the VMs into the tenant’s namespace. The VMs keep their IPs and VLAN; north-south routing and firewalling now flow through the tenant’s self-managed Transit Gateway.

2. IP addressing continuity. Map every VCD IP Space to an External IP Block before moving anything. The 9.1 additions (multiple CIDRs, exclusion ranges, Infoblox integration) make it possible to mirror your existing allocations exactly — use that to keep tenant SNAT/VIP addresses stable so their downstream firewall rules and DNS survive the move.

3. Security policy rebuild. Treat the vDefend transition as an opportunity, not a chore. Export and rationalize existing DFW rule sets, then rebuild them as delegated vDefend policy with dynamic groups. If you are automating this (and at provider scale, you should be), the VCFA cloud template path with Cloud.SecurityGroup resources lets you express tenant micro-segmentation as code from day one — a topic I will cover in depth in a follow-up post.

Under the hood: what a tenant actually consumes now

In VCD, a tenant consumed an Org VDC — an opaque slice of a Provider VDC with allocation-model semantics that only VCD understood. In VCFA, the consumption unit is a Supervisor namespace, and it is worth being precise about what that bundle contains, because it is what your migrated VMs land inside:

• VM classes — t-shirt-sized CPU/memory shapes the provider curates and the tenant selects from (the successor to VCD sizing policies).
• Storage classes — vSphere storage policies (vSAN ESA policies included) surfaced as Kubernetes storage classes; this is how storage tiering reaches the tenant.
• An NSX VPC — the tenant’s private routing domain, with subnets, SNAT, and the Transit Gateway attachment.
• Content library bindings — the curated image catalog (your old VCD catalogs, post-hygiene).
• Quota enforcement — counted against the organization’s region quota, which in 9.1 can span multiple Supervisors.

The practical consequence: a “VM” in VCFA is a declarative object served by the VM Service, not a row in the VCD database. The same VM a tenant deploys through the VCFA catalog can be expressed — and lifecycle-managed — as YAML against the namespace:

apiVersion: vmoperator.vmware.com/v1alpha3
kind: VirtualMachine
metadata:
  name: app-vm-01
  namespace: tenant-a-prod        # the Supervisor namespace
spec:
  className: guaranteed-medium     # provider-curated VM class
  imageName: ubuntu-22.04-lts      # from the bound content library
  storageClass: vsan-esa-gold      # vSphere storage policy
  network:
    interfaces:
      - name: eth0                 # lands on a VPC subnet

Why this matters for migration planning: VMs, VKS clusters, and (in All-Apps orgs) AI workloads are all served through the same namespace primitive. When you classify a tenant as All-Apps, you are not enabling a feature flag — you are placing them on a consumption plane where their VCD-era VMs and their future Kubernetes estate share quota, networking, and governance. That is the architectural payoff that justifies the migration effort, and it is why tenant classification (checklist item 3) deserves a real workshop rather than a default.

What your tenants will notice

Your migration communication plan should be built around this table — it is the difference between tenants experiencing an upgrade and tenants filing tickets:

The API transition: where your automation goes

If you run a service provider practice, your VCD automation — onboarding pipelines, billing extracts, tenant portals — is the part of this migration nobody budgets properly. The mapping:

One concrete example of the tenant-side upgrade. In VCD, giving a tenant firewall self-service meant DFW sections scoped through the VCD proxy and a lot of provider hand-holding. In VCFA, security intent lives directly in the cloud template alongside the workload it protects:

resources:
  web_sg:
    type: Cloud.SecurityGroup
    properties:
      name: web-tier-sg
      securityGroupType: new       # provisions the group at deploy time
  web_vm:
    type: Cloud.vSphere.Machine
    properties:
      image: ubuntu-22.04-lts
      flavor: guaranteed-medium
      networks:
        - network: '${resource.vpc_net.id}'
          securityGroups:
            - '${resource.web_sg.id}'   # micro-seg attached as code

The deployment provisions the security group, attaches the workload, and — with 9.1’s delegated vDefend model — keeps the whole thing inside guardrails the provider defines once. Tenant micro-segmentation becomes a code review, not a ticket queue. This deserves its own deep dive, and it will get one in the follow-up post.

Migration readiness checklist

Decision framework: which path for which tenant

Putting it on a calendar: the phased wave plan

Durations below assume a mid-size provider (50–200 tenants) with a dedicated migration team. Scale accordingly — but keep the phase boundaries, because each phase gates the next:

Five ways this migration goes wrong

Patterns worth naming, because every one of them is avoidable and every one of them happens:

1. Migrating the mess. Fifteen years of VCD accumulates orphaned vApp templates, dead orgs, and firewall rules nobody can explain. Running the Migration Tool over an uncleaned estate turns technical debt into migrated technical debt on a platform where it is now unfamiliar debt. Hygiene first.
2. Classifying every tenant as All-Apps “to be safe.” Org type drives Supervisor placement and consumption design. Defaulting everyone to All-Apps burdens VM-only tenants with a model they will not use and complicates your capacity math. Classify on evidence, not hedging.
3. Treating VLAN extension as the destination. It is a bridge. Providers who extend everything “temporarily” find themselves running a permanent hybrid L2 estate with double the operational surface. Expiry dates, owners, tracked in the same register as the migration itself.
4. Discovering the XML API callers in Phase 2. The billing script someone wrote in 2016 against the legacy API will fail loudly mid-wave. The API caller inventory (checklist 8a) is boring, which is why it gets skipped, which is why it becomes the outage.
5. Underinvesting in tenant communication. The tenant experience genuinely improves — but only tenants who were told what changed will experience it as improvement. Budget real effort for the porting guide, the vApp-to-deployment explanation, and the “your new self-service powers” message. Your NPS through this migration is a comms outcome, not a technical one.

Frequently asked questions

Does this mean Cloud Director is end-of-life?
Check the official Broadcom product lifecycle matrix for authoritative dates rather than blog speculation (including mine). What is unambiguous from the 9.1 release is strategic direction: the Migration Tool exists, the VCSP tenancy investment is landing in VCFA, and the Tenant Manager carries the VCD codebase forward inside VCF. Plan on the trajectory, not the deadline.

Can I run VCD and VCFA side by side during migration?
Yes — and you will, for months. That is precisely why the phased plan includes parallel metering and a VCD write-freeze discipline for migrated orgs. The risk is not coexistence; it is coexistence without an exit date.

Do my tenants’ IP addresses survive?
They can, if you do the work: mirror IP Spaces into External IP Blocks before moving anything, and use VLAN extension where re-IP is not yet feasible. IP continuity is a design outcome, not a tool feature.

What happens to my vApps?
The VMs inside them migrate; the vApp construct itself (fencing, start order, leases) does not have a 1:1 successor in VCFA. Grouping lands on namespaces and deployments, and orchestration behavior is re-expressed in cloud templates. Audit your production vApp patterns during the inventory phase and validate each against the official migration documentation — this is the single biggest tenant-facing conceptual change, so put it at the top of your comms plan.

How does object-level access control change?
Significantly, and it needs design work before migration. VCD scoped object access at the vApp and catalog level; VCFA scopes it at the Project level — a new construct where org admins group users and namespaces, and the same user can hold different roles in different projects. Translate your existing vApp-sharing and catalog-permission patterns into a project design per tenant as part of the classification workshop, so access lands correctly on day one instead of being retrofitted after tickets.

What to do next

1. Run the inventory and classification exercises (checklist items 2 and 3) — they cost nothing and inform everything.
2. Work through the official VCFA 9.1 migration documentation and stage the prerequisite VCD update, with your inventory in hand.
3. Stand up the VCF 9.1 landing zone and pilot one tenant per network pattern before committing to a wave plan.

In the next post, I will go deeper on the security layer of this story: rebuilding tenant micro-segmentation as code with VCFA cloud templates and Cloud.SecurityGroup — turning the DFW rationalization exercise from this guide into delegated, self-service lateral security.

Have you started planning a VCD-to-VCFA migration? I would love to hear which construct mappings are causing you the most friction — drop a comment below.