Using the VCF Automation Migration Tool: Environment Assessment Through to Tenant Cutover

VCF AUTOMATION MIGRATION TOOL

A guide to the supported migration path from Cloud Director to VCF Automation: the assessment stage, the Migration Service, workload mobility by version, and what to have ready at each gate.

Until recently, moving a provider estate off Cloud Director was a bespoke exercise. That changed with Cloud Director 10.6.2, which made migration to VCF Automation 9.1 a supported, documented and tool-assisted path rather than something negotiated case by case. There is now a defined sequence with defined artefacts, and knowing that sequence is what lets you build a programme plan instead of an intention.

This guide covers that path: what the Environment Assessment Tool does and why it comes first, how the documentation is issued, what the Migration Service handles, how workload mobility differs between VCF 9.0 and 9.1, and what needs to be ready before each stage. It also flags where the publicly available detail runs out, because the migration documentation is issued in response to your assessment rather than published openly.

One note on scope. The step-by-step behaviour of the tooling in your environment comes from the documentation Broadcom issue to you. Everything below is the structure of the process and the preparation it demands, which is the part you can plan against today.

What this guide covers

• The three-stage supported path, end to end
• Getting to the 10.6.2 baseline first
• The Environment Assessment Tool and what it collects
• Requesting the migration documentation
• The VCF Automation Migration Service
• Workload mobility, and why the target version matters
• Gates, artefacts and a readiness checklist

1. The Supported Path in Three Stages

The documented sequence is short to describe and consequential to plan around.

• 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.

What makes this different from most migration tooling is that stage two is a human process with a turnaround time attached. Your plan has an external dependency in its first phase, which is unusual and easy to underestimate. Providers who treat the assessment as something that happens after approval discover that the documentation arrives weeks into a programme that was already running.

2. Stage Zero: Getting to the 10.6.2 Baseline

Before any of that, you need to be on Cloud Director 10.6.2. It is the release that enables the supported path, and it exists largely for that purpose: it closes security vulnerabilities identified since the previous release, resolves defects reported by providers running Cloud Director in production, and validates interoperability so that the platform you are leaving is stable and hardened while you leave it.

Plan this as its own piece of work rather than as a preliminary. It is a Cloud Director upgrade on a live provider platform, which means change windows, tenant notification if your process requires it, and the usual validation afterwards. On a multi-cell deployment serving production tenants, allow two to six weeks of elapsed time even though the technical work is shorter.

It is also worth doing regardless of migration timing. The security fixes apply whether or not you have decided when to move, and a provider running an internet-facing tenancy portal has a poor argument for deferring them.

3. Stage One: The Environment Assessment Tool

The Environment Assessment Tool collects environment-specific metadata from your Cloud Director deployment. The purpose is to establish how your environment is actually configured rather than how it is documented, and the gap between those two things is usually where a migration programme finds its surprises.

Two reasons this matters more than a typical pre-flight check. First, it produces the input for the migration documentation you receive, so the quality of what you get back depends on the state of what you send. Second, it forces an early, honest look at an environment that in most provider estates has been accumulating configuration for the better part of a decade.

What to have in order before you run it

• A current Cloud Director inventory, reconciled against your own records rather than assumed to match them.
• A tenant list with organisation count, virtual data centre count and workload count per tenant.
• Awareness of any non-standard configuration: custom extensions, unusual networking, bespoke arrangements made for a particular customer years ago.
• A named owner for the output, because the results need reviewing rather than forwarding.

Run it early even if your decision is not final. The assessment is informative regardless of what you subsequently choose, and it costs a fraction of what a delayed programme costs.

4. Stage Two: Requesting the Migration Documentation

The assessment results go to your Broadcom Account Manager, who arranges the migration documentation for your environment. Access to the Migration Tool and its documentation is routed through your Broadcom representative rather than published openly.

Three practical implications for your plan. Build turnaround time into the schedule as a dependency with a date rather than as an assumption. Establish who owns the Broadcom relationship on your side and make sure they know this request is on the critical path. And expect the documentation to be specific to what your assessment found, which means the more accurately your environment is represented, the more useful the guidance you receive.

If your account relationship is thin, this is a reason to strengthen it now rather than at the point you need something from it.

5. Stage Three: The Migration Service

The VCF Automation Migration Service connects to Cloud Director and drives the migration step by step through the interface. Broadcom describe it as automating the transfer of Cloud Director workloads and configurations into VCF 9.1 with minimal downtime, and VCF Automation 9.1 provides the Migration Tool for performing an in-place migration from Cloud Director.

The important framing for planning is what the tooling does and does not decide. It moves workloads and configuration. It does not decide what your organisation virtual data centres should become, how your addressing should be preserved, which storage class corresponds to which existing policy, or what your RBAC model should look like. Those are design outputs that must exist before the tooling is useful, which is why construct mapping runs in parallel with the assessment rather than after it.

• The tool executes a design. It does not produce one. A provider who reaches this stage without a construct mapping will find the tooling asking questions nobody has answered.
• Migration is per organisation in practice. Organisations are the natural unit, which suits tenant-by-tenant scheduling and gives each customer their own validation and rollback conversation.
• Minimal downtime is not no downtime. What that means for a given tenant depends on your target version and on how the workloads are moved.
• Validation is yours. The tool reports technical success. Only the tenant can confirm their service is working, and that sign-off belongs in your definition of a completed migration.

6. Workload Mobility, and Why Target Version Matters

This is the detail with the largest commercial consequence in the entire programme, and it turns on a version difference.

Under VCF 9.0, bringing a vCenter-managed virtual machine under VCF Automation management meant migrating it into a VCF Automation managed Namespace, which could be done through the vCenter migrate option by changing the management layer and selecting the target VPC, subnet and storage class. That migration required the virtual machine to be rebooted and re-addressed.

VCF 9.1 introduced the Mobility Operator, a new core Supervisor service that allows non-disruptive migration of running virtual machines. For an enterprise, that is a convenience. For a provider, it is the difference between telling a customer their service will be interrupted and telling them it will not, which is a different conversation with a different approval path and a different effect on your programme timeline.

Table 1 - Workload mobility by target version.

If you are choosing a target version, treat this as a primary criterion rather than a feature comparison item. The programme time saved in tenant negotiation alone typically exceeds any advantage of targeting the earlier release.

7. Gates and Artefacts

Each stage should produce something you could hand to a different team and have them continue. If a stage produces no artefact, it produces no evidence of progress either.

Table 2 - Gates and artefacts by stage.

Migrate your own internal tenant as the pilot. Every provider has one, and it is the only tenant whose migration you can afford to get wrong. A pilot conducted on a paying customer is not a pilot, it is a first attempt with an audience.

8. Readiness Checklist

Before the assessment

• Cloud Director inventory reconciled against provider records, with discrepancies investigated
• Tenant list complete with organisation, virtual data centre and workload counts
• Non-standard configuration and custom extensions catalogued
• Named owner assigned for the assessment output

Before the migration service is connected

• 10.6.2 baseline reached and validated
• Migration documentation received and reviewed against your design
• Construct mapping complete, with the organisation VDC pattern decided
• IP Spaces mirrored into External IP Blocks where addresses are to be preserved
• Storage classes defined and confirmed to match existing protection levels in substance
• RBAC model designed and built on the target platform
• VCF Automation environment built, validated and monitored

Before each tenant migration

• Tenant notified with adequate lead time and a named contact on your side
• Tenant API integrations identified and their remediation confirmed as complete
• Addressing approach agreed with the tenant specifically, not assumed
• Change window booked with the tenant rather than imposed
• Rollback trigger and procedure written for this tenant and understood by whoever is on the night
• Metering confirmed correct for a tenant on the new platform before the invoice run
• Validation criteria agreed with the tenant, including who signs off

After each tenant migration

• Tenant sign-off received in writing rather than assumed from silence
• Write freeze applied to the organisation on Cloud Director so nothing diverges
• Service desk records updated so support knows which platform serves this tenant
• Monitoring and backup coverage confirmed on the new platform
• Any network extension created recorded with an expiry date and an owner

9. Where This Goes Wrong

Running the assessment late. It gates the documentation, which gates the migration. It is the cheapest item in the programme and the one most often scheduled after approval rather than before it.

Reaching the tooling without a design. The Migration Service executes a construct mapping. It does not create one, and a provider who arrives without one will stall at the first decision.

Targeting the wrong version. Choosing VCF 9.0 to save time on the platform build costs considerably more in tenant negotiation, because workload mobility requires a reboot and re-addressing rather than being non-disruptive.

Treating technical success as completion. A migration the tool reports as successful and the tenant has not validated is not finished. Build customer sign-off into the definition of done.

No write freeze after cutover. If the old organisation remains writable, configuration drifts between platforms and the rollback position quietly disappears.

Piloting on a customer. The first migration will surface something. Let it surface on your own tenant.

Frequently Asked Questions

How do we get access to the Migration Tool?

Through your Broadcom representative. The documented route is to run the Environment Assessment Tool against your Cloud Director deployment and send the results to your Broadcom Account Manager to request the migration documentation, after which the Migration Service is connected to Cloud Director and the migration proceeds step by step.

Do we have to be on Cloud Director 10.6.2?

It is the release that enables the supported path, and it exists largely for that purpose. It also carries security fixes and defect resolutions worth having regardless of migration timing. Plan the upgrade as its own piece of work with change windows rather than as a preliminary step.

Does the Migration Service decide how our constructs map?

No. It moves workloads and configuration according to a design you supply. Deciding what organisation virtual data centres become, how addressing is preserved and what your RBAC model looks like is design work that must be complete before the tooling is useful.

Will tenants experience downtime?

It depends on your target version. Under VCF 9.0, bringing workloads under VCF Automation management required a reboot and re-addressing. VCF 9.1 introduced the Mobility Operator, a Supervisor service enabling non-disruptive migration of running virtual machines. If tenant outage matters commercially, and for a provider it does, target 9.1 or later.

Can we migrate one tenant at a time?

Organisations are the natural migration unit, which suits tenant-by-tenant scheduling and gives each customer their own validation and rollback conversation. That is also what makes the side-by-side route attractive for providers with contractually sensitive customers.

How long between requesting documentation and receiving it?

That depends on your Broadcom relationship and is outside your control, which is precisely why the assessment should run in week one. Treat it as a dependency with a date in your plan rather than as an assumption.

Can Consult Circle run the migration for us?

Yes. We work with providers across the whole path: reaching the 10.6.2 baseline, running the assessment, construct mapping and platform design, tenant migration execution and Cloud Director decommissioning. We also review plans built by internal teams before the first tenant moves.

Where Consult Circle Fits

The tooling has made the mechanical part of this migration considerably more predictable than it was a year ago. What it has not changed is that the tool executes decisions somebody has to make first, and that the pace of a provider migration is set by customer conversations rather than by technology.

We work with providers on both halves: the design that has to exist before the tooling is useful, and the tenant-by-tenant execution that follows. Where an internal team is running the programme, a review before the pilot is the cheapest point at which to find a problem.

Related guides in this series

• VMware Cloud Director to VCF Automation Migration: The Complete Guide for Service Providers
• Mapping VMware Cloud Director Constructs to VCF Automation
• VMware Cloud Director Migration Services: Scoping and Pricing a VCD to VCF Automation Programme
• Migrating Tenants Off Cloud Director Without Losing Them
• 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