Migrating Tenants Off Cloud Director Without Losing Them: Communication, Cutover and Parallel Running

VCD MIGRATION TENANT CUTOVER

The part of a VCD to VCF Automation migration that has nothing to do with infrastructure: telling customers, sequencing them, running two platforms, and getting the billing right.

A Cloud Director migration can be technically flawless and still damage your business. The workloads land correctly, the addressing is preserved, the platform performs, and three months later a customer does not renew because the portal changed without warning, their integration broke, and their first invoice on the new platform was wrong.

This is the part of the programme that has no equivalent in an enterprise migration. When an enterprise migrates, the affected users work for the same organisation and can be instructed. When a provider migrates, the affected users are customers with contracts, alternatives and opinions, and the only leverage you have is how well you handle them.

What follows is that half of the programme: what your tenants actually experience, how to sequence them, what to send and when, how to run two platforms without the billing going wrong, and how to make sure parallel running ends. It assumes the technical planning is happening elsewhere.

What this guide covers

• What your tenants actually experience
• Identifying the tenants who set your timeline
• Sequencing by tolerance rather than by size
• The communication plan, and when each message lands
• Running two platforms: metering, support and write freezes
• The cutover itself, and what counts as done
• Ending parallel running, with a checklist

1. What Your Tenants Actually Experience

It is worth being precise about this, because provider teams consistently underestimate it by extrapolating from their own experience. Tenant Manager, the provider layer, is built on the Cloud Director codebase, so your engineers find the transition familiar. The tenant-facing layer derives from Aria Automation and is, from the customer's point of view, a different product.

• A new portal, not an updated one. Different interaction model, different terminology, different capabilities. Every screenshot in their internal documentation becomes wrong on cutover day, along with the training they gave their own staff.
• Broken integrations. Anything automated against the Cloud Director tenant API needs rework, done by them, funded by them, scheduled against their own priorities.
• Possible re-addressing. Preservable with deliberate work around IP Spaces and External IP Blocks, and if that work was not done, this becomes their project rather than yours.
• A different consumption model. The vApp has no direct equivalent. Customers who think in vApps need to be told what replaces that thinking, in advance and in their language rather than yours.
• New capabilities they did not ask for. Firewall self-service through vDefend delegation and self-service load balancing through Avi are genuine gains. Presented well, they change the conversation from disruption to upgrade.

That last point is worth taking seriously as a communication strategy rather than as a consolation. A migration framed as something being done to a customer generates resistance. The same migration framed as capability they are gaining, with the disruption acknowledged honestly, generates a different reaction from the same facts.

2. Identifying the Tenants Who Set Your Timeline

Not all tenants are equal in a migration programme and the differences are not the obvious ones. Size is a weak predictor. These are the categories that actually matter.

Table 1 - Tenant categories and the lead time each demands.

The first row is the one to establish in week one, and the only reliable way to establish it is to ask. Usage data will tell you which tenants call the API. It will not tell you which of them have built something that matters around it, and the difference between an occasional script and an integrated provisioning pipeline is months of lead time.

3. Sequencing by Tolerance, Not by Size

The instinct is to migrate small tenants first because they look like less risk. It is the wrong instinct. Small and tolerant are different properties, and a twelve-workload customer with a brittle provisioning integration is a considerably worse first migration than a large customer with an engaged technical team who has been asking about VCF Automation for a year.

• Your own internal tenant. Every provider has one, and it is the only tenant you can afford to get wrong. If your pilot is a paying customer, it is not a pilot.
• Friendly tenants. Customers with a good relationship, technical engagement and tolerance for a first attempt. Ask them, do not assign them, and be honest that they are early.
• The straightforward majority. Portal users without automation, flexible on addressing. This is the bulk of most estates and where the programme finds its rhythm.
• Addressing-sensitive tenants. Once the preservation approach has been proven several times rather than designed once.
• Contractually or regulatorily constrained tenants. Started early in terms of paperwork, migrated late in terms of execution.
• Deep integration tenants. Migrated when their remediation is genuinely complete, which is their milestone rather than yours.

Note that the paperwork sequence and the migration sequence are different. Contract variations and assurance processes for late-stage tenants should start in the first month even though those customers migrate last, because legal and governance elapsed time runs in parallel with everything else and is wasted if it starts late.

4. The Communication Plan

Tenant communication starts months before the first migration, not weeks. The purpose of the early messages is not to inform, it is to surface the objections and dependencies you do not yet know about.

Table 2 - A tenant communication timeline that works.

Three things make these messages work. Name a person rather than a mailbox, because customers escalate to individuals and a mailbox reads as an organisation avoiding contact. Be specific about what changes rather than reassuring in general, since vague reassurance is what customers remember when something does change. And offer a sandbox to technically engaged tenants ahead of their migration, because the customers who will complain loudest are usually the ones who would have engaged constructively if given something to look at.

5. Running Two Platforms

For the duration of the programme, some tenants are on Cloud Director and some are on VCF Automation. This period is normal, it is longer than most plans assume, and it is manageable provided three things are designed rather than improvised.

Metering and billing

Billing must remain correct throughout, and it is the single most damaging thing to get wrong. A technical fault is visible to your customer's engineers, who understand that migrations are difficult. An incorrect invoice is visible to their finance team, who do not, and it arrives in writing.

• Design parallel metering before the first tenant moves, and test it against a real billing run rather than in principle.
• Validate the first invoice for every migrated tenant manually, however confident you are in the automation.
• Establish clearly what happens to a tenant who migrates mid-billing-period, and be able to explain it in one sentence.
• Reconcile both platforms monthly during the parallel period, since drift is easier to catch at the point it appears.

Support and the service desk

Every support interaction now begins with an unspoken question: which platform serves this customer. Give your service desk a lookup they can use under pressure, brief them on the tenant portal rather than only the provider interface, and make sure escalation paths exist for both platforms. A first-line agent who confidently gives Cloud Director instructions to a migrated tenant does more relationship damage than the original fault.

Write freeze discipline

Once an organisation has migrated and been validated, the Cloud Director side must be frozen. No configuration changes, no new workloads, no accommodating a customer request "just this once" on the old platform. Without this discipline the two environments diverge, and the moment they diverge your rollback position has quietly disappeared without anybody noticing.

Make the freeze technical rather than procedural where you can. A policy that relies on everyone remembering will fail at 2am during an incident, which is exactly when a divergence causes the most harm.

6. The Cutover Itself

A tenant cutover is a customer event with an infrastructure component. Treat the customer half with the same rigour as the technical half.

• Window agreed with the tenant rather than imposed, and confirmed in writing
• Named contact on your side available throughout, and known to the customer in advance
• Tenant technical contact available during the window, not merely notified of it
• Rollback trigger written down, with a named person authorised to call it
• Addressing approach confirmed with this specific tenant one final time
• Their integration remediation confirmed complete, if applicable
• Validation criteria agreed in advance, including who signs off and what they will test
• Support briefed that this tenant moves tonight, before it happens rather than after

A migration is not complete when the workloads are running. It is complete when the tenant has confirmed in writing that their service works. Infrastructure green and application green are different states, and only the customer can report the second one. Build that sign-off into your definition of done or you will accumulate tenants in a state of nearly migrated, with no reliable measure of progress.

7. Ending Parallel Running

Parallel running is a legitimate phase and a terrible permanent state. Providers who do not set an exit date discover that the last handful of tenants never move, and Cloud Director stays alive for years carrying licensing, support, security exposure and the assurance question you started this programme to answer.

• Set the exit date at the start of the programme and attach a named owner to it, not a team.
• Report against it monthly with the count of remaining tenants, so drift is visible early rather than discovered late.
• Escalate the stragglers commercially rather than technically. A tenant who has declined three proposed windows is a commercial conversation, and pretending otherwise simply delays it.
• Have a defined position for a tenant who genuinely cannot move by the date, agreed in advance rather than negotiated in the final month.
• Decommission Cloud Director promptly once the last tenant has gone, since the benefit case depends on switching it off rather than on emptying it.
• Wind down parallel metering deliberately, and validate one full billing cycle afterwards.

The final decommissioning is also worth communicating. Tenants who have migrated appreciate knowing the old platform is retired, particularly the ones whose assurance processes prompted the question in the first place.

8. Where This Goes Wrong

Announcing too late. Six months is not excessive for a change to the portal a customer uses daily. Early communication surfaces the dependencies you do not know about, which is its actual purpose.

Sequencing by size. Tolerance predicts a good first migration far better than size does, and a small tenant with a brittle integration is a poor pilot.

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

Treating tenant sign-off as optional. Without it you accumulate nearly-finished migrations and lose any reliable measure of progress.

Allowing changes on migrated organisations. One accommodation on the old platform and the environments diverge, taking your rollback position with them.

No exit date for parallel running. The programme never ends, the saving never arrives, and the exposure you were addressing persists.

Getting one invoice wrong. It will be remembered longer than any technical incident in the entire programme.

Frequently Asked Questions

How far in advance should we tell tenants?

Six months for the initial roadmap announcement, with individual notification around eight weeks before a tenant's own slot. The early message is not really about informing people, it is about surfacing the integrations, contractual constraints and objections you do not yet know about, and that only works if it goes out early enough to act on the answers.

Which tenants should we migrate first?

Your own internal tenant, then friendly customers who have agreed to be early rather than been assigned to it. Sequence by tolerance rather than by size, since a small tenant with a brittle integration is a worse first migration than a large one with an engaged technical team.

How long will we be running two platforms?

For most providers, several months to a year depending on tenant count and integration complexity. The duration is manageable. What is not manageable is running it without a documented exit date and a named owner, because that is how the final tenants never move.

What if a tenant refuses to migrate?

Treat it as a commercial conversation rather than a technical one, and have the position agreed in advance. Some providers offer a final window with a defined consequence, some negotiate individually with strategic customers. What does not work is repeatedly rescheduling, which teaches every other tenant that the date is negotiable.

How do we keep billing correct during the migration?

Design parallel metering before the first tenant moves and test it against a real billing run. Validate the first invoice for every migrated tenant manually, and reconcile both platforms monthly. An incorrect invoice does more relationship damage than a technical fault, because it is visible to people who do not accept that migrations are difficult.

Should we offer tenants a sandbox?

Yes, for technically engaged customers ahead of their migration. It converts the tenants most likely to complain into the ones best prepared, and their feedback improves the documentation you give everybody else.

What counts as a completed tenant migration?

Written confirmation from the tenant that their service works, not a successful task in the tooling. Infrastructure green and application green are different states, and only the customer can report the second one.

Can Consult Circle help with the tenant side?

Yes. We work with providers on communication planning, sequencing, per-tenant runbooks and the parallel running disciplines around metering, support and write freezes, alongside the technical migration itself. In practice this is the half of the programme that determines whether it is judged a success.

Where Consult Circle Fits

Most migration failures we are asked to help with are not technical. They are programmes where the infrastructure worked and the customer relationship did not, usually because tenant communication started late, sequencing followed size rather than tolerance, or parallel running had no end date.

We work with providers on both halves, because separating them is what causes the problem. Engagements cover the technical migration alongside communication planning, tenant sequencing and the operational disciplines that keep two platforms running correctly until one of them can be switched off.

Related guides in this series

• VMware Cloud Director to VCF Automation Migration: The Complete Guide for Service Providers
• 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
• VMware Cloud Director End of Life: What the VCF Automation Transition Means for Your Provider Business
• 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