Why This Isn’t a Rebranding Exercise
It’s tempting to treat VCF Automation (VCFA) as “VCD with a new coat of paint.” That framing is wrong and will mislead a migration plan. VCFA is a new solution that reuses code from both predecessors it supersedes — VMware Cloud Director and Aria Automation — but combines them into a genuinely different architecture. The provider-facing layer, Tenant Manager, is built on the VCD codebase, so provider administrators will find the UI and APIs familiar. The tenant-facing layer, by contrast, inherits heavily from Aria Automation and will look entirely new to VCD end users who are used to the classic tenant portal.
For a VCSP, that split matters operationally: your provider-side operations team has a shorter learning curve than your tenant-facing support and enablement teams do.
What Changed With 9.1: The Official Migration Tool
VCF 9.0 introduced VCFA as the unified cloud management platform, but migration from VCD was largely a manual, professional-services-led exercise. VCF Automation 9.1 changes this materially: it ships an official, in-place Migration Tool that automates the transfer of VCD workloads and configurations into VCFA with minimal downtime. This is the single biggest unlock for VCSPs who have been sitting on VCD, waiting for a credible path forward rather than a forced re-platform.
There are two broad migration paths to plan against:
- In-place migration using the 9.1 Migration Tool — the recommended default for most VCSPs, minimizing tenant disruption.
- Parallel build-and-cutover — standing up VCFA alongside the existing VCD environment and migrating tenants in waves, useful when networking or organizational complexity makes in-place migration too risky to do in one pass.
The Three Timeline Killers
Field experience migrating VCD environments to VCFA consistently surfaces the same three risk areas — get ahead of these in planning, not during execution:
1. Networking disposition: extend vs. re-IP. Every tenant network either needs to be extended into the new environment or re-IPed. This decision needs to be made tenant-by-tenant, not fleet-wide, and it’s the single biggest driver of both migration timeline and tenant-facing risk.
2. Automation porting, especially legacy XML API callers. Tenants and internal tooling that call the classic VCD XML API need to be inventoried explicitly. VCFA’s API surface is fundamentally different (REST/Cloud API-first, aligned with the rest of VCF’s Unified SDK direction), and legacy XML API automation will not simply “keep working” post-migration.
3. Billing continuity against VCF Operations. If your VCSP billing model is metered off VCD usage data, that integration needs to be re-pointed and validated against VCF Operations metering before cutover — not discovered as a gap during the first billing cycle after go-live.
Construct Mapping: What Maps Where
At a conceptual level, the important translations to plan around:
- VCD Organizations → VCFA Organizations, managed through Tenant Manager (structurally familiar to VCD provider admins).
- VCD Org VDCs → VCFA VPCs / Namespaces, depending on whether the workload is VM-centric (mapped to VPC networking constructs) or moving toward the Supervisor/VKS model.
- VCD Edge Gateways → NSX Tier-0/Tier-1 or the newer VPC-based connectivity model — and this is where the “centralized vs. distributed” external connection decision (see our VCF 9.1 features post) becomes directly relevant to a VCSP’s tenant network design.
- VM import, as of 9.1, can use the new Mobility Operator — a core Supervisor service — to move running VMs into VCFA-managed namespaces without a reboot or re-IP, a substantial improvement over the 9.0 “Change management layer” approach, which forced both.
Non-Disruptive Import: How It Actually Works
For VMs already sitting under a regular vCenter (not VCD-managed), 9.1’s VirtualMachineInfraMigration (vmim) custom resource, delivered by the Mobility Operator, enables a batch-oriented import model: an administrator defines an ImportOperationBatch specifying the group of VMs to migrate, the target namespace, subnet/network configuration (whether networking changes or stays as-is), and storage class — and the migration executes without disrupting the running workload. This is a meaningfully lower-risk primitive than the 9.0-era approach and is worth demoing directly to VCSP customers who are nervous about migration-induced downtime.
Recommended VCSP Readiness Sequence
- Inventory and tenant classification — do this first; it costs nothing and informs every downstream decision, especially the network extend-vs-re-IP call per tenant.
- Confirm VCF 9.1 core platform readiness (see our upgrade and features posts) — VCFA 9.1 deploys as a Day-N operation on top of VCF Management Services, so the underlying fleet needs to be healthy and on 9.1 first.
- Validate Fleet Depot sync for VCFA binaries specifically — the VCD Migration Engine component ships as part of the VCFA binary set, and deployment fails outright if the depot hasn’t synced it.
- Pilot with a low-risk tenant using the in-place Migration Tool before committing to a fleet-wide wave plan.
- Re-point billing and automation integrations against VCF Operations and the VCFA REST API surface, validated end-to-end before the first production cutover.
The Strategic Case for VCSPs
Beyond the mechanics, 9.1 gives VCSPs a genuine growth story on the other side of migration: core tenancy improvements support hundreds of isolated tenants on shared infrastructure with self-service networking (VPNs, NAT, firewall rules) delegated to tenants through vDefend, and Advanced Kubernetes support lets providers offer up to 500 clusters per Supervisor while cutting container workload costs meaningfully. In other words, the migration isn’t just defensive modernization — it’s the on-ramp to selling AI, Kubernetes, and sovereign-cloud-grade services that VCD alone was never architected to deliver.
