The Complete VCD to VCF Automation Migration Checklist: 72 Checks for Service Providers

VCD TO VCFA MIGRATION CHECKLIST

A Consult Circle working checklist covering assessment, construct mapping, platform build, per-tenant migration, cutover, parallel running and decommissioning - seventy-two checks in the order the work actually happens.

This is the checklist we work through on Cloud Director to VCF Automation migrations. It is not a summary of the product documentation. Every item exists because it caused a problem on somebody's platform, and in a provider migration most of them cost a customer conversation rather than an afternoon.

It is ordered the way the work happens: assessment first, then the lifecycle baseline, construct mapping, platform build, per-tenant preparation, the cutover itself, post-migration validation, parallel running discipline and finally decommissioning. Work through it in order, because several later checks are meaningless until earlier ones have passed.

If you are running the migration with a partner, this doubles as a way of testing whether their runbook is thorough. If seventy-two items look excessive, that is a reasonable conclusion to reach after reading them rather than before.

What this checklist covers

• Assessment and platform discovery, nine checks
• Tenant discovery, ten checks
• Lifecycle and baseline, six checks
• Construct mapping decisions, twelve checks
• Platform build and validation, nine checks
• Per-tenant preparation, eight checks
• Cutover night, seven checks
• Post-migration validation, six checks
• Parallel running discipline, and decommissioning

1. Assessment and Platform Discovery

Everything downstream is planned against this. An inventory that has not been reconciled recently will be wrong in both directions, and in a provider estate both directions have customers attached.

• Environment Assessment Tool run against the Cloud Director deployment and the output reviewed rather than forwarded
• Assessment results submitted to your Broadcom Account Manager to request the migration documentation, with a date recorded
• Named owner assigned for the assessment output and for the Broadcom relationship
• Cloud Director version, patch level and cell count recorded for every environment, including any secondary sites
• Provider VDC inventory with the original reason for each boundary established, where anyone still remembers it
• Custom extensions, UI plugins and API extensions catalogued with a decision recorded for each
• Existing metering and billing integration documented, including exactly where usage data originates
• Backup, monitoring and identity integrations documented against the platform rather than assumed
• Total workload count and provisioned storage established from the platform, not from a spreadsheet

The mechanics of the assessment stage, and what the tooling does with its output, are covered in our guide to using the VCF Automation Migration Tool.

2. Tenant Discovery

This section predicts your programme duration more accurately than anything technical. The first item is the single most valuable question in the whole exercise.

• Every tenant asked directly whether they have automated against the Cloud Director tenant API, rather than inferred from usage data
• For each integrated tenant, the depth established: an occasional script is not an integrated provisioning pipeline
• Revenue concentration mapped, so the tenants whose timelines become your timeline are identified explicitly
• Per-tenant addressing requirement established tenant by tenant, not applied as a blanket assumption
• Regulated and assurance-bound tenants identified, with their supplier change processes understood
• Contractual constraints reviewed per tenant: notice periods, change control obligations, service credits, platform named in contract
• vApp usage sampled across the estate to establish how much genuine multi-workload grouping exists
• Tenant technical contacts identified by name, with confirmation those names are current
• Dormant or abandoned organisations identified, with a decision recorded to migrate, archive or delete
• Tenants who would be suitable as friendly early migrations identified and informally approached

Understanding what a tenant's own automation will have to absorb is easier if you know what they built against; our reference on the Cloud Director API for day-to-day operations sets out the calls most tenant integrations depend on.

3. Lifecycle and Baseline

• Lifecycle and support entitlement confirmed with Broadcom in writing rather than inferred from published summaries
• Cloud Director 10.6.2 upgrade planned as its own piece of work with its own change windows
• Tenant notification for the 10.6.2 upgrade issued where your change process requires it
• Target VCF and VCF Automation versions agreed, with the workload mobility implications understood
• VCF 9.1 or later confirmed as the target where non-disruptive workload migration matters commercially
• Interoperability confirmed for the specific combination of versions you intend to run

The commercial background to the lifecycle dates is set out in VMware Cloud Director end of life and what the VCF Automation transition means.

4. Construct Mapping Decisions

These are design decisions rather than checks, and they need to be made in roughly this order because several constrain the ones after them.

• IP Spaces inventoried and mirrored into External IP Blocks before any workload moves
• Address preservation decided per tenant, with the tenants requiring it identified explicitly
• Network extension candidates identified, each with an expiry date and a named owner recorded at creation
• Provider capacity model designed against Regions and workload domains rather than transliterated from provider VDCs
• A single Organization VDC to Project and Namespace pattern designed, with exceptions handled deliberately
• Pricing and contractual implications of the new construct model reviewed with whoever owns commercials
• Organisation VDC network types mapped against the VPC model rather than translated mechanically
• Edge Gateway responsibilities mapped across VPC, Transit Gateway and vDefend constructs
• Firewall delegation model decided: what organisation administrators can manage themselves
• Storage classes mapped to existing policies by protection level rather than by name
• Catalogue audited by actual deployment frequency, with a rationalisation decision recorded
• RBAC model designed fresh and validated against what tenants actually do, not transliterated from rights bundles

Each of these decisions is worked through construct by construct in Mapping VMware Cloud Director constructs to VCF Automation.

5. Platform Build and Validation

• Deployment route decided: VCF Operations Fleet Management or day zero through the VCF Installer
• VCF Automation deployed and the containerised platform beneath it understood by whoever will operate it
• Identity integration configured and tested with a real tenant authentication flow
• Monitoring extended to the VMSP appliances and the Kubernetes cluster, not only to the interface
• Backup coverage confirmed for the new platform and a restore tested
• Metering integration built and validated against a real billing run rather than in principle
• Certificate replacement procedure rehearsed in a lab before it is needed in production
• Transfer share expansion procedure rehearsed, since it is a routine task with an unfamiliar method
• Provider-side automation reviewed and reworked against the Tenant Manager API

Where the target platform build is also in scope, our VMware Cloud Foundation services cover the underlying environment.

6. Per-Tenant Preparation

Run through this for every tenant before their migration is scheduled, not before the programme starts.

• Tenant notified with adequate lead time and given a named contact rather than a mailbox
• Their API integration remediation confirmed complete by them, in writing, rather than assumed from silence
• Addressing approach confirmed with this specific tenant one final time
• Sandbox offered to technically engaged tenants ahead of their migration
• Change window negotiated with the tenant rather than imposed on them
• Their technical contact confirmed as available during the window, not merely notified of it
• Validation criteria agreed in advance, including who signs off and what they will actually test
• Rollback trigger written for this tenant, with a named person authorised to call it

7. Cutover Night

• Service desk briefed that this tenant migrates tonight, before it happens rather than after
• Migration Service connected and the construct mapping for this tenant confirmed against the design
• Storage class assignment verified for this tenant rather than accepted as default
• Network mappings confirmed per organisation network before execution, not selected from memory
• Escalation path live, with the named contact reachable throughout the window
• Rollback position confirmed as intact before the point of no return is passed
• Progress communicated to the tenant contact during the window rather than only at the end

The tenant-facing side of this - notification, sequencing and what to say when a window overruns - is covered in Migrating tenants off Cloud Director without losing them.

8. Post-Migration Validation

Infrastructure green and application green are different states. Only the tenant can report the second one.

• Tenant sign-off received in writing, confirming their service works rather than that the migration completed
• Addressing verified as preserved where that was the agreement
• Storage protection level confirmed to match what the tenant was previously receiving
• Metering confirmed correct for this tenant before the next invoice run, and the first invoice validated manually
• Backup and monitoring confirmed as covering the tenant at their new location
• Any network extension created for this tenant recorded with an expiry date and an owner

9. Parallel Running Discipline and Decommissioning

The period between the first and last tenant migration is where a well-executed programme quietly loses its rollback position and its end date.

• Write freeze applied to every migrated organisation on Cloud Director, enforced technically rather than by policy where possible
• Service desk lookup available showing which platform serves which tenant, usable under pressure
• Both platforms reconciled monthly for billing accuracy, with drift investigated rather than averaged
• Remaining tenant count reported monthly against the exit date
• Position agreed in advance for a tenant who genuinely cannot move by the exit date
• Stragglers escalated commercially rather than repeatedly rescheduled

Decommissioning

• All tenants confirmed migrated and validated, with sign-off recorded for each
• Network extensions all un-extended and routing normalised
• Cloud Director retired promptly rather than left running empty
• Parallel metering wound down and one full billing cycle validated afterwards
• Capacity reclaimed and returned to the platform
• Decommissioning communicated to tenants, particularly those whose assurance processes raised the question
• As-built documentation produced and handed to whoever operates the platform

Stranded organisations and virtual data centres that will not delete cleanly are common on long-lived estates; the patterns and the safe deletion order are in Cloud Director common errors and known issues.

Reading Your Results

The value is not the ticks, it is the pattern of what is missing. Three patterns come up repeatedly.

• Gaps clustered in tenant discovery. By far the most common, and the most expensive to leave. It means the programme is being planned against infrastructure data when its actual constraint is customer behaviour. Cheap to fix now, and it changes the timeline.
• Gaps clustered in construct mapping. The design has not been made yet, and the migration tooling executes a design rather than creating one. A programme that reaches the tooling with this section incomplete will stall at the first tenant.
• Gaps clustered in parallel running and decommissioning. The plan covers getting tenants across and stops. This is the pattern that produces migrations which are technically complete and never actually finish, with Cloud Director alive years later.

Twelve to twenty-five unanswered items on a first pass is normal. Fewer than five usually means the checklist has been read rather than worked through.

The Checks That Get Skipped Most

Asking tenants directly about API integrations. Usage data tells you who calls the API. It does not tell you who has built something that matters around it, and that difference is months of lead time.

Mirroring IP Spaces before anything moves. Leave this until migration design and the decision has already been made by default, and the default is that tenants re-address.

Testing metering against a real billing run. Validating in principle is not validating. An incorrect invoice does more relationship damage than any technical fault in the programme.

The write freeze. One accommodation on the old platform during an incident and the environments diverge, taking the rollback position with them without anyone noticing.

Piloting on your own tenant. Every provider has an internal tenant. It is the only one you can afford to get wrong, and using a customer instead makes the first migration an audience event.

Setting an exit date for parallel running. Without a date and a named owner, the final handful of tenants never move and the benefit case never lands.

Frequently Asked Questions

How long does it take to work through this checklist?

Assessment, tenant discovery and lifecycle typically take two to four weeks of effort and can run alongside commercial discussions. Construct mapping is a design phase of four to eight weeks. The remaining sections are gates within the programme rather than a separate exercise.

Which checks are genuinely non-negotiable?

Asking tenants directly about API integrations, mirroring IP Spaces before anything moves, testing metering against a real billing run, the write freeze on migrated organisations, and an exit date for parallel running. Those five catch the failures that are most expensive to discover late.

Can we skip sections if we only have a handful of tenants?

Some items collapse at small scale, particularly around sequencing and parallel running discipline. Tenant discovery, construct mapping and validation do not scale down, because a five tenant provider with one deeply integrated customer has the same problem as a fifty tenant one and proportionally fewer migrations to absorb it.

What if we are already mid-programme?

Work backwards from the section you are in and check the earlier ones anyway. Problems found mid-programme usually trace to a tenant discovery or construct mapping item that was skipped, and finding it now costs less than finding it at the next tenant.

Who should own this checklist?

One named person, with sections delegated to networking, billing, service desk and account management. Checklists owned collectively get completed optimistically, because nobody is accountable for the item that turns out to be wrong.

Can Consult Circle run this for us?

Yes. Our assessment engagements work through the first four sections and produce a findings report with a construct mapping design attached. It is a self-contained piece of work and the output is yours regardless of who delivers the migration afterwards.

Where Consult Circle Fits

This checklist reflects how we run provider migrations rather than being a condensed version of the documentation. Several items look trivial and none of them are, which is generally what a checklist derived from experience looks like.

We run the first four sections as an assessment engagement producing findings and a design, and we run the full lifecycle from assessment through tenant migration to Cloud Director decommissioning through our VMware Cloud Director services, with the target platform covered by our VMware Cloud Foundation services. Where your team is running the programme, we review the plan before the pilot.

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
• Mapping VMware Cloud Director Constructs to VCF Automation
• Using the VCF Automation Migration Tool: Environment Assessment Through to Tenant Cutover
• VMware Cloud Director Migration Services: Scoping and Pricing a VCD to VCF Automation Programme
• Migrating Tenants Off Cloud Director: Communication, Sequencing and Cutover
• VMware Cloud Director 10.x vs VCF Automation 9.1: A Feature Parity Comparison 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