VMware Cloud Director 10.x vs VCF Automation 9.1: A Feature Parity Comparison for Service Providers

VCD 10.X VS VCFA 9.1

A Consult Circle side-by-side assessment of what VCF Automation 9.1 does better, what it does differently, and what Cloud Director still does that VCFA does not.

Parity is the word every provider uses when evaluating VCF Automation, and it is only half the right question. A straight feature-for-feature comparison assumes the two platforms are trying to do the same thing in the same way, and in several important areas they are not. VCF Automation is not attempting to be Cloud Director with a newer interface. It expresses multi-tenancy through a different resource model, and a fair number of apparent gaps turn out to be things done elsewhere or done differently rather than things missing.

That said, the question underneath is entirely legitimate: if we move, what can we no longer sell, and what will our tenants notice. This comparison answers that directly. It covers tenancy, self-service, networking, storage, catalogues, Kubernetes, identity, extensibility, metering and operations, with an honest section on where Cloud Director still does something VCF Automation does not.

One caveat worth stating up front, because it affects how you should use this. Broadcom have not published a definitive feature parity matrix between the two products. What follows is assembled from release documentation, published provider guidance and practitioner reporting, and it reflects VCF Automation 9.1 including its patch releases. Anything you sell commercially should be validated in a proof of concept against your own service definitions rather than taken from any comparison table, including this one.

What this comparison covers

• The architectural difference that explains most of the table
• Tenancy and the resource model
• Self-service and tenant consumption
• Networking, which is where VCFA is furthest ahead
• Storage and data efficiency
• Catalogues and image governance
• Kubernetes and containers
• Identity, RBAC and extensibility
• Metering, billing and tenant economics
• Operations and lifecycle
• Where Cloud Director still wins, and known issues to plan around

The Architectural Difference Behind Most of the Table

Almost every row below follows from one structural change. Cloud Director sits above vSphere as a separate multi-tenancy layer with its own object model: provider virtual data centres, organisation virtual data centres, vApps, organisation networks. It translates tenant intent into vSphere and NSX operations.

VCF Automation does not sit above the platform in the same way. It consumes vSphere Supervisor constructs directly. Tenant infrastructure is presented through Namespaces, which are Kubernetes namespaces managed by the Supervisor with assigned compute resources, storage classes and NSX VPCs, organised into Projects within Organizations. The abstraction layer is thinner and the platform underneath is doing more of the work.

That is why the provider experience feels familiar while the tenant experience does not. Tenant Manager, the provider-facing layer, is built on the Cloud Director codebase. The tenant layer derives from Aria Automation and expresses a different model. It is also why several Cloud Director constructs have no direct equivalent: they existed to bridge a gap that the Supervisor now bridges natively. The construct-by-construct detail is covered in our Cloud Director to VCF Automation construct mapping guide.

Tenancy and Resource Model

Table 1 - Tenancy and resource model comparison.

The vApp row is the one to take seriously. There is no direct equivalent, and any part of your service that treats the vApp as the unit of consumption needs redesign rather than translation. In practice this matters less than it sounds for most estates, because sampling usually shows the majority of vApps contain a single virtual machine. Where vApps are genuinely used for multi-tier applications with start ordering and vApp networks, that is a real conversation with the tenant.

The allocation model row is subtler and affects your commercials. Cloud Director's allocation models are a pricing construct as much as a technical one, and providers have built tiered offerings around them for a decade. VCF Automation expresses governance through namespace classes, infrastructure policies and project-level controls, which is capable of the same outcomes but not by the same route. Whoever owns your pricing needs to be in that design conversation.

Self-Service and Tenant Consumption

This is an area where VCF Automation 9.1 is materially ahead, and it is worth being specific because it changes what you can sell.

Table 2 - Self-service and tenant consumption comparison.

The delegation model deserves emphasis because it changes provider economics rather than just capability. Every namespace request, firewall rule change and load balancer configuration that a tenant can safely perform themselves is a ticket that leaves your queue. Providers who have spent years handling these as managed requests will find the margin arithmetic changes, and it is worth modelling that before assuming the migration is purely a cost.

Networking

Networking is where VCF Automation 9.1 is furthest ahead of Cloud Director, and where the change is most disruptive to your existing designs. It is also the area where the migration mapping is least mechanical.

Table 3 - Networking comparison.

Two things follow for a provider. First, edge sprawl is one of the genuine operational pain points at scale, and the distributed model removes it for north-south traffic while keeping stateful services on a dedicated appliance cluster. If you currently run an edge per tenant, the operational saving is real and worth quantifying in the business case.

Second, the connectivity policy model changes how multi-tier tenant networking is delivered. Patterns you currently build with per-rule firewall configuration, such as separating development from production or providing shared services, become a policy assignment. That is faster to deliver and it means your existing network service definitions describe a method that no longer applies.

Storage and Data Efficiency

Table 4 - Storage and data efficiency comparison.

The storage rows mostly reflect the platform rather than the management layer, and they are commercially significant because data reduction goes straight to your cost per usable terabyte. If you are building a business case, the storage efficiency gains are among the easier numbers to defend.

The object storage row needs care. Native S3-compatible object storage on vSAN is a genuinely interesting new service tier on existing hardware, and it is a technology preview in the 9.1 patch stream. If you currently sell object storage through the Cloud Director extension, confirm the migration path and the support position before assuming continuity of that service line.

Catalogues and Image Governance

Table 5 - Catalogue and image governance comparison.

Project-scoped content libraries are a meaningful improvement for providers with regulated tenants or tiered catalogues, because image availability can be restricted below the organisation boundary rather than only at it. If you currently maintain separate organisations to achieve image separation, that constraint goes away.

Kubernetes and Containers

Table 6 - Kubernetes and container services comparison.

If you have carried Container Service Extension as a service line, this is one of the clearest wins in the migration. Kubernetes stops being an extension you maintain separately and becomes part of the platform you already operate, with density and provisioning speed that make it viable to sell rather than tolerate.

Identity, RBAC and Extensibility

Table 7 - Identity, RBAC and extensibility comparison.

The extensibility rows are where providers with significant investment need to be most careful. Cloud Director's UI plugin model has been used by many providers to surface their own services inside the tenant portal, and that investment does not transfer. Catalogue what you have built, establish what each plugin actually does for tenants, and decide per item whether it is replaced, delivered another way or retired. Discovering this during migration is expensive; discovering it during assessment is not.

On blocking tasks, the mechanism survives and its purpose is unchanged, but the scope narrows to provider workflows. Any extensibility that depends on intercepting tenant workflows needs rethinking.

Metering, Billing and Tenant Economics

Table 8 - Metering, billing and tenant economics comparison.

Showing tenants a price before they click deploy is a genuine change to provider economics rather than a cosmetic feature. It reduces billing disputes, it reduces waste, and it makes self-service safer to offer widely. If your current showback is a monthly report produced after the fact, this is one of the more sellable improvements in the whole platform.

The metering row carries the highest verification priority in this entire comparison. Your billing chain is the thing that must not break, and it is provider-specific in a way that no comparison table can address. Validate it against a real billing run during the proof of concept, not during the migration. The commercial framing of that work is covered in our guide to scoping and pricing a VCD to VCF Automation programme.

Operations and Lifecycle

Table 9 - Operations and lifecycle comparison.

The first row is the one that costs your team time. The cell and transfer share model that every Cloud Director operator has internalised does not apply. Failure modes, log locations, health checks and upgrade behaviour all follow the containerised platform pattern instead, and diagnostic instinct built over a decade needs partial rebuilding. Budget lab time rather than classroom time. Our guide on VCF Automation for Cloud Director administrators goes through what carries over and what does not.

The cyber recovery clean room is worth flagging commercially rather than technically. On-premises ransomware recovery with network isolation is a service tier providers can sell to regulated tenants who cannot use cloud-based recovery, and it arrives with the platform rather than as a third-party integration.

Where Cloud Director Still Does Something VCFA Does Not

An honest comparison needs this section, and most vendor material does not have one. These are the areas where a provider should plan for redesign, replacement or a conversation with a tenant.

• The vApp as a consumption unit. No direct equivalent. Multi-tier applications with start ordering and vApp networks, and any tenant process or documentation built around vApps, need redesigning rather than translating.
• Tenant UI extensibility. The Cloud Director UI plugin model has been used by many providers to surface their own services inside the tenant portal. That investment does not carry across. Catalogue yours and decide per plugin.
• Tenant-scoped blocking tasks. Blocking tasks survive but are tied to provider workflows. Extensibility that intercepted tenant workflows needs another approach.
• Allocation models as a commercial construct. Cloud Director's allocation models underpin many providers' tiering and pricing. The equivalent outcomes are achievable through namespace classes and infrastructure policies, but your service definitions and price list need rewriting.
• A decade of operational familiarity. Not a feature, and the most underestimated item on the list. Every runbook, every diagnostic habit and every piece of tenant documentation assumes the old platform.
• Object storage continuity. If you sell object storage through the Cloud Director extension, the native platform alternative is a technology preview in the 9.1 patch stream. Confirm the path and support position before assuming service continuity.
• Tenant API compatibility. Anything a tenant automated against the Cloud Director tenant API needs rework by them. This is the single largest external dependency in a migration programme.

Known Issues Worth Planning Around

VCF Automation 9.1 is a maturing platform and its patch release notes are worth reading before you design against it. Several documented issues have direct planning consequences rather than being cosmetic.

• Services have not always recovered cleanly after a full cluster restart, with one or more remaining in a non-running state and needing manual intervention. Later patches address the blocking housekeeping task behind this, but it is a reason to rehearse platform restart in a lab rather than discovering the behaviour in production.
• A group pagination defect has affected user and group association with project principals and namespace access, where more groups exist than the page size. Providers with large directory group counts should test identity integration deliberately rather than assuming it scales.
• Token lifetime and refresh behaviour has produced forced logouts in the orchestrator interface after the access token lifetime, which defaults to one hour. Worth knowing before your team concludes the platform is unstable.
• Content library creation has failed on certain images due to manifest validation behaviour. Test your actual image estate rather than a sample.
• Patch level matters. Track the 9.1 patch stream rather than evaluating the base release, since several of these are addressed in patches and your evaluation should reflect what you would actually deploy.

None of these are reasons not to migrate. They are reasons to run a proof of concept against your own configuration, at your own scale, with your own directory and image estate, before committing dates to tenants.

Running Your Own Parity Assessment

No published comparison substitutes for testing against your own service catalogue. This is how we structure it.

• Every service in your published catalogue listed, with the Cloud Director capability that delivers it identified
• Each service classified as parity, different model, gap or improvement against VCF Automation
• Different model services flagged for service definition and price list rewriting, since these outnumber the genuine gaps
• Genuine gaps assigned an owner and a decision: replace, deliver differently, or retire
• UI plugins catalogued individually, with what each does for tenants recorded
• Tenant API integration inventory completed by asking tenants directly
• Billing chain validated end to end against a real billing run in the proof of concept
• Object storage service continuity confirmed if you sell it today
• Identity integration tested at your actual directory scale, including group counts
• Image estate tested rather than sampled, in content library workflows
• Platform restart and recovery rehearsed in a lab
• Patch stream position decided, so you evaluate what you would actually run
• Net commercial effect modelled, including tickets removed from your queue by self-service delegation

The last item is the one providers skip and the one that most often changes the business case. A migration assessed purely as cost and disruption looks worse than it is, because it ignores the managed requests that stop arriving once tenants can create namespaces, configure firewalls and provision load balancers themselves.

Frequently Asked Questions

Is VCF Automation 9.1 at feature parity with Cloud Director 10.x?

Not in a strict row-for-row sense, and that is the wrong test. The honest framing is that most capabilities exist but are expressed through different constructs, a smaller number are genuinely absent, and networking, Kubernetes, self-service delegation and fleet operations are materially stronger. Broadcom have not published a definitive parity matrix, so validate against your own catalogue.

What is the biggest genuine gap?

The vApp as a consumption unit, closely followed by tenant UI extensibility. Neither is fatal, both need design work, and the vApp gap is usually smaller in practice than it appears because most vApps in most estates contain a single virtual machine.

Where is VCF Automation clearly better?

Networking, by some distance: transit gateways decoupled from Tier-0, distributed north-south connectivity that avoids tromboning through edge appliances, VPC connectivity policies and network services without per-tenant edges. Also Kubernetes, self-service delegation with granular guardrails, pre-deployment cost visibility for tenants, and fleet-scale lifecycle and identity.

Will our tenants notice the difference?

Yes, unavoidably. The tenant portal derives from Aria Automation rather than Cloud Director, so it is a new product from their point of view rather than an updated one. What they gain is real, including cost visibility before deployment and self-service firewall and load balancer configuration, but the transition needs managing as a customer programme.

Can we still sell the same services?

Mostly, but several service definitions describe a delivery method that no longer applies, and your price list may reference constructs such as allocation models that do not exist in the same form. Plan for rewriting service definitions rather than only for migrating infrastructure.

Should we wait for a later release?

The migration tooling and the provider capabilities landed in 9.1, and the patch stream continues to address known issues. Waiting does not reduce the programme duration, which is set by tenant conversations rather than by platform maturity, and it consumes runway. Evaluate on the patch level you would actually deploy rather than on the base release.

How do we assess parity for our own platform?

List every service in your published catalogue, classify each against the four categories above, and validate the commercially critical ones in a proof of concept, particularly the billing chain. Pay attention to the different model category rather than only the gaps, because there are more of those and they carry more programme effort.

Can Consult Circle run a parity assessment for us?

Yes. We run it against your published service catalogue rather than in the abstract, producing a service-by-service classification with owners assigned to the gaps and an estimate of the rewriting effort. It is a self-contained engagement and the output is yours regardless of who delivers the migration.

Where Consult Circle Fits

The parity question is usually asked as a technical one and answered best as a commercial one. What matters is not how many rows say parity, but which of the services you actually sell survive unchanged, which need a rewritten definition, and which need a tenant conversation. That is a different exercise from reading a comparison table, and it is the one that determines the size of your programme.

We run parity assessments against a provider's published service catalogue, alongside Cloud Director design, upgrade and VCFA migration work, and the wider VMware Cloud Foundation platform build where the target environment is also in scope.

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