VMware Cloud Director End of Life: What the VCF Automation Transition Means for Your Provider Business

VMWARE CLOUD DIRECTOR END OF LIFE

The Cloud Director lifecycle position, what 10.6.2 actually changes, and how much runway a provider migration to VCF Automation really needs.

Every VMware Cloud Service Provider is now asking the same question, usually in a board paper rather than a design document: how long do we have. It is a reasonable question and the answer is less tidy than anyone would like, because Broadcom have not handled the Cloud Director lifecycle the way they handled vSphere 7. There is no single published date sitting on a slide waiting to be quoted.

What there is, is a direction that has become unambiguous over the last eighteen months, and a set of concrete facts that let you plan properly without waiting for an announcement. This guide sets out what those facts are, what actually changes for a provider, how to assess your exposure, and how much runway a migration to VCF Automation consumes from a standing start.

In this article

• The lifecycle facts, and what is genuinely unclear
• What Cloud Director 10.6.2 changes and why it exists
• What actually happens as support winds down
• Assessing your exposure as a provider rather than as an enterprise
• The four options, including the ones nobody likes
• How much runway the migration needs
• What to do in the next ninety days, and a readiness checklist

1. The Lifecycle Position, Stated Plainly

• VCF Automation supersedes Cloud Director. This was established when VCF 9 launched. VCF Automation absorbed the roles previously performed by both Cloud Director and Aria Automation, and it is where the tenancy investment is now going.
• The Cloud Director codebase continues inside VCF. Tenant Manager, the provider-facing layer of VCF Automation, is built on it. The product is being replaced; the engineering is being carried forward.
• Migration tooling is real and supported. VCF Automation 9.1 includes a Migration Tool for in-place migration from Cloud Director, and the Migration Service automates the transfer of workloads and configurations into VCF 9.1.
• Cloud Director 10.6.2 shares its end of life with VCF 9.1. That is the closest thing to a published date, and it ties the lifecycle of your tenancy platform to a VCF release rather than to an independent schedule.
• There is no standalone published end of life date. Not in the way vSphere 7 had one. Check the Broadcom Product Lifecycle Matrix for the authoritative position on your specific version and entitlement, and get the answer in writing.

The temptation is to read the absence of a hard date as breathing room. For an enterprise running vSphere that reading might be defensible. For a provider it is not, because your constraint is not the deadline. It is the number of tenant conversations you can hold per month, and that number is fixed regardless of when the date lands.

2. What Cloud Director 10.6.2 Changes

The September 2026 release is worth understanding on its own terms, because its purpose is different from every Cloud Director release that preceded it.

It is a migration release. It closes security vulnerabilities identified since the previous version, resolves defects reported by providers running Cloud Director in production, and validates interoperability so that the platform you are migrating from is stable and hardened while you do it. It is not a feature release and it is not trying to be. The point is to give you a solid baseline from which to leave.

It also establishes the supported migration path. With 10.6.2, moving to VCF Automation 9.1 is a documented, tool-assisted process rather than something negotiated case by case. The sequence is: run the Environment Assessment Tool to collect environment-specific metadata from your Cloud Director deployment, send the results to your Broadcom Account Manager to request the migration documentation, then connect the VCF Automation Migration Service to Cloud Director and work through the migration step by step.

Two conclusions follow. First, getting to 10.6.2 is a prerequisite, so it belongs in your plan as its own piece of work with its own change windows. Second, because the detailed documentation is issued in response to your assessment, there is an external dependency in your programme from the very first phase.

3. What Actually Happens as Support Winds Down

Nothing switches off. The changes are gradual and they compound, which is precisely why they get discounted in planning meetings.

Security patches stop

This is the material one, and it is materially worse for a provider than for an enterprise. Cloud Director is internet-facing by design. It is the portal your tenants log into, which means it is also the portal everyone else can reach. A tenancy platform that no longer receives security fixes is a different risk proposition from an internal management appliance sitting behind a jump host, and it will be assessed as such by your customers' security teams as well as your own.

Compensating controls help and should be in place regardless: strict access control, multi-factor authentication for provider administration, web application filtering in front of the portal, and enhanced monitoring. They reduce exposure. They do not answer the question a tenant asks during their annual supplier review.

Your customers start asking

Your tenants have their own auditors, their own insurers and their own procurement cycles. When their questionnaire asks whether their cloud provider is running supported infrastructure, somebody in your organisation has to answer it, and the answer becomes a commercial issue rather than a technical one. Providers routinely discover the compliance consequence before the technical one, often with a renewal attached.

The compatibility window closes

Backup tooling, monitoring integrations, billing systems and the ecosystem of provider extensions all certify against supported versions. As Cloud Director ages out, new versions of the things around it stop supporting it. This rarely causes an incident directly. What it does is progressively remove options, so that the migration you deferred becomes harder rather than merely later.

4. Assessing Your Exposure as a Provider

• Tenant count and concentration. Twenty tenants is a programme. Two hundred is a different programme with the same technology. If three customers represent most of your revenue, their timelines are your timelines.
• Integration depth. How many tenants have automated against the Cloud Director tenant API? These customers need the longest lead time and they are invisible in an infrastructure inventory. This single number is the best predictor of programme duration we have found.
• Contractual position. Notice periods, change control obligations, service credits and any commitment that references the platform by name. Some provider contracts make a platform change a formal variation, which adds legal time to engineering time.
• Regulatory profile of your tenant base. Public sector, financial services and healthcare tenants carry supplier assurance obligations that will surface the support question earlier and more formally.
• Portal exposure. How the Cloud Director interface is published, what sits in front of it, and how quickly you could respond to a critical vulnerability with no patch available.
• Internal capacity. How many customer-facing migrations your team can genuinely run per month alongside business as usual. This is almost always the binding constraint and it is almost always overestimated.

5. The Four Options

Migrate to VCF Automation

The strategic answer for providers staying on the VMware platform. It resolves the lifecycle position, puts you on the platform receiving investment, and unlocks the capabilities landing in VCF Automation such as vDefend firewall delegation to organisation administrators and self-service load balancing. It also has the longest lead time, which is why the decision needs making well before the deadline is uncomfortable. Our complete VCD to VCFA migration guide covers the programme end to end.

Stay on Cloud Director and accept the risk

Defensible for a defined period, and only as a documented, dated decision with a named owner and a review date. Write down the compensating controls, what would trigger an earlier response, and how you will answer the tenant assurance question. If you cannot write that down, you have not accepted the risk, you have deferred thinking about it.

Move to a different platform

Some providers are using this moment to evaluate alternatives entirely. It is a genuine option and it is a larger programme than the VCF Automation migration, not a smaller one, because it changes your operating model, tooling, commercial constructs and skills alongside the platform. Evaluate it properly if you evaluate it at all, and set a decision date.

Exit the business or consolidate

Worth naming because it is happening. For some smaller providers the arithmetic of the new licensing model plus a platform migration does not work, and the realistic options are consolidation or partnering. If that conversation is live in your organisation, have it before you spend the migration budget rather than after.

6. How Much Runway You Actually Need

Table 1 - Phase durations for a provider with no existing VCF Automation environment.

Phases overlap, so the total is not the sum. A realistic end to end figure is six to eighteen months from decision to Cloud Director decommissioning, and the spread is explained almost entirely by tenant count and integration complexity rather than by anything technical.

The phase that cannot be compressed by spending more is tenant migration, because its pace is set by customer availability. Doubling your engineering team does not double the number of maintenance windows your tenants will agree to, and it does not make a customer's development team refactor their API integration any faster.

7. What to Do in the Next Ninety Days

1. Confirm your lifecycle and entitlement position with Broadcom in writing rather than inferring it from published summaries.
2. Run the Environment Assessment Tool against your Cloud Director environment and submit the results, since the response is an external dependency you want started early.
3. Build a tenant inventory that records organisation count, workload count and, critically, which tenants have automated against the Cloud Director tenant API.
4. Review your contracts for notice periods, change control obligations and anything that names the platform.
5. Plan the upgrade to the 10.6.2 baseline as its own piece of work, because it is a prerequisite regardless of which route you choose.
6. Implement the compensating controls worth having anyway: administrative access review, multi-factor authentication, portal filtering and monitoring.
7. Draft the tenant communication, even if you will not send it for months, because writing it forces the questions your customers will ask.
8. Name an owner. Lifecycle programmes drift most often because they belong to everybody in general and nobody in particular.

8. Readiness Checklist

Know your position

• Current Cloud Director version and patch level recorded
• Lifecycle and support entitlement confirmed in writing with Broadcom
• Target VCF and VCF Automation versions identified
• Environment Assessment Tool run and results submitted

Reduce exposure now

• Provider administrative access reviewed, with multi-factor authentication enforced and dormant accounts removed
• Tenant portal exposure reviewed, with filtering or protection in front of it
• Cloud Director logging forwarded to security monitoring with alerting on anomalous provider activity
• Backups verified as isolated and restore tested within the last quarter
• Risk formally accepted, dated, owned and scheduled for review

Prepare the exit

• Tenant inventory complete, including API integration usage per tenant
• Contractual obligations reviewed and any required variations identified
• Migration route chosen, in-place or side-by-side
• 10.6.2 upgrade scheduled as a prerequisite piece of work
• Tenant communication plan drafted with a first notification date set
• Cloud Director decommissioning included in the business case rather than assumed

Where Providers Get This Wrong

Waiting for a published date. The absence of an announcement is not runway. Whenever the date lands, your programme still takes six to eighteen months, and starting later only compresses it.

Planning against engineering capacity. The pace is set by tenant availability and customer engineering time. Plan against the constraint that actually binds.

Discovering API integrations during migration. These tenants need the longest lead time and are invisible in infrastructure data. Ask them directly, early.

Skipping the 10.6.2 baseline. It is a prerequisite and it carries security fixes you want regardless.

Leaving Cloud Director running after the last tenant moves. The exposure persists until the platform is switched off, along with the cost and the assurance question. Decommissioning is part of the plan.

Underestimating the customer conversation. Your largest tenants will have opinions about a change to the portal they work in every day, and those opinions arrive late enough to reshape the plan if you have not sought them out.

Frequently Asked Questions

When exactly does VMware Cloud Director go end of life?

There is no standalone published date equivalent to the vSphere 7 announcement. What is documented is that Cloud Director 10.6.2 shares its end of life with VCF 9.1. Confirm the authoritative position for your specific version and entitlement through the Broadcom Product Lifecycle Matrix and get it in writing, since this is the kind of question your tenants will eventually ask you formally.

Should we upgrade to 10.6.2 if we are migrating anyway?

Yes. It is the supported baseline for the migration path, it carries security fixes and defect resolutions you want regardless, and the assessment tooling assumes it.

What happens to our tenants when support ends?

Nothing operationally. What changes is that the platform they log into stops receiving security fixes, which becomes a question in their supplier assurance processes rather than an outage.

How long does a migration to VCF Automation take?

Six to eighteen months from decision to decommissioning for a provider with a meaningful tenant base. The tenant migration phase does not compress by adding engineers.

Can we buy extended support for Cloud Director?

Discuss it with your Broadcom account manager, since availability and scope vary by product and entitlement. Where it exists, treat it as a bridge to a migration that is genuinely underway rather than as a substitute for a decision, and understand precisely whether security fixes are included or only technical guidance.

We are a small provider. Is this worth it?

That is a legitimate question rather than a rhetorical one. For some smaller providers the combination of the current licensing model and a platform migration changes the economics enough that consolidation or partnering becomes the better answer.

Can Consult Circle help if we have not started?

Yes, and that is the usual starting point. The first work is an exposure assessment and a tenant inventory, run alongside compensating controls that reduce risk immediately. Being late changes the urgency rather than the approach.

Where Consult Circle Fits

We work with service providers on this transition specifically, which is a narrower thing than working on VMware migrations generally. The provider version of this problem is dominated by the tenant relationship, and the useful experience is knowing how much lead time an integration-heavy customer needs and which tenants to sequence where, rather than knowing how the platform installs.

Engagements run from a fixed assessment through design and tenant migration to Cloud Director decommissioning. Where an internal team is running the programme, we review the plan before the first tenant moves, which is a considerably cheaper way to find the problem.

Related guides in this series

• VMware Cloud Director to VCF Automation Migration: The Complete Guide for Service Providers
• VCF Automation for VMware Cloud Director Administrators: What Carries Over and What Does Not
• Mapping VMware Cloud Director Constructs to VCF Automation: Org VDCs, Edge Gateways, Catalogs and IP Spaces
• 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