VMware Cloud Foundation has changed substantially between the VCF 5.x generation and VMware Cloud Foundation 9.x. For organisations operating VCF 5.2, VCF 5.2.1 or an estate built around standalone vSphere 8, the move to VCF 9 is more significant than a conventional infrastructure software upgrade.
VCF 9 Services
Planning a move to VCF 9?
Consult Circle delivers VCF 9 design, upgrade, deployment and migration services, starting with an assessment of your current VCF 5.x estate.
VCF 5.x already provided an integrated software-defined data centre platform built around vSphere, vSAN, NSX, SDDC Manager and VMware Aria components. VCF 9.x develops that model into a more unified private cloud platform with integrated operations, infrastructure automation, modern application services, stronger fleet-level management and a more consistent consumption model.
Broadcom describes VCF 9 as a platform for traditional virtual machines, cloud-native applications and AI workloads, with vSphere, vSAN, NSX, VCF Operations and VCF Automation brought together as an integrated private cloud foundation.
For infrastructure architects, VMware administrators and IT leaders planning a VMware Cloud Foundation 5.x to VCF 9.x upgrade, the architectural and operational differences need to be understood before the first upgrade bundle is downloaded.
This article compares the two generations and explains what those changes mean for VCF design, deployment, upgrade planning and workload migration.
VCF 5.x vs VCF 9.x comparison table
The table below uses VCF 5.2 and 5.2.1 as the practical reference point for the 5.x generation. Individual features can vary between VCF 5.0, 5.1 and 5.2.
| Area | VMware Cloud Foundation 5.x | VMware Cloud Foundation 9.x |
|---|---|---|
| Platform model | Integrated SDDC stack centred on vSphere, vSAN, NSX, SDDC Manager and Aria products | Unified private cloud platform for VMs, containers, modern applications and AI workloads |
| Primary management model | SDDC Manager is central to VCF deployment, workload domains, upgrades and lifecycle workflows | Greater consolidation around VCF Operations, VCF Automation and platform-level services |
| Infrastructure deployment | Workload-domain architecture provisioned and maintained through SDDC Manager workflows | More automated deployment through the VCF Installer, APIs and declarative configuration |
| Existing vSphere adoption | VCF 5.2 introduced VCF Import for bringing compatible existing vSphere and vSAN environments under VCF management | Expanded convergence and adoption workflows for bringing existing infrastructure into the VCF private cloud operating model |
| Lifecycle management | SDDC Manager coordinates component compatibility, upgrade sequencing and workload-domain lifecycle | More integrated lifecycle and fleet management, with VCF 9.1 further consolidating management services |
| vSphere lifecycle | vSphere 8 generation, with both historic lifecycle approaches still encountered in customer environments | vSphere 9 requires image-based lifecycle management for clusters and hosts; baseline/VUM-managed clusters are not supported |
| Operations | Aria Operations provides monitoring and operational analytics alongside VCF management components | VCF Operations becomes a core integrated private cloud operations platform with health, compliance, fleet and lifecycle capabilities |
| Automation | VMware Aria Automation provides IaaS and private cloud consumption functionality | VCF Automation provides a more integrated self-service private cloud consumption and governance model |
| Networking | NSX 4.x integrated into VCF. VCF 5.2 includes NSX 4.2 capabilities | NSX remains a core VCF networking and security layer, with tighter integration into the overall VCF operating model |
| Security and compliance | Security distributed across vSphere, NSX, identity, certificates and Aria/VCF operational components | Configuration compliance monitoring, identity integration, certificate management and security operations are more deeply integrated |
| Workload mobility | HCX available for migration and mobility, including large-scale migrations in VCF 5.2-era environments | VCF Operations HCX 9 adds deeper VCF integration, unified HCX management and integrated migration planning |
| Kubernetes and modern apps | vSphere with Tanzu and related cloud consumption capabilities available depending on configuration | Modern application and Kubernetes services form a more explicit part of the unified private cloud platform |
| Infrastructure efficiency | vSAN ESA, modern vSphere 8 capabilities and storage optimisation available | Adds technologies such as advanced memory tiering, storage efficiency enhancements and expanded hardware acceleration |
| Management experience | Multiple administrative products and consoles remain part of normal operations | Greater emphasis on a common operating experience and reduced management fragmentation |
| API and automation strategy | Automation available through individual platform APIs, SDDC Manager and Aria tooling | Increased emphasis on API-driven infrastructure operations, automation and repeatable private cloud deployment |
| Target operating model | Software-defined data centre and private cloud infrastructure management | Cloud operating model with infrastructure services presented as a standardised internal platform |
1. The biggest change is the private cloud operating model
VCF 5.x is already much more than vSphere with additional software.
VCF 5.0 shipped with vSphere 8.0 Update 1, vSAN 8.0 Update 1, NSX 4.1 and the associated management stack. Its workload-domain architecture allowed infrastructure teams to create standardised pools of compute, storage and networking and manage them through SDDC Manager.
VCF 9 pushes the model further.
Instead of viewing each component as an individual VMware product that happens to participate in a VCF deployment, VCF 9 is designed around an integrated private cloud experience. The intention is to give infrastructure teams, application teams and platform engineering teams a common foundation from which infrastructure services can be provisioned, governed and operated.
This distinction matters during a VCF 5.2 to VCF 9 migration.
An organisation that reproduces its existing VCF 5.x architecture without reviewing its operating model may complete the software upgrade but gain little from the architectural improvements available in VCF 9.
The design exercise should therefore consider management boundaries, workload placement, network topology, identity, storage policy, automation, tenancy, lifecycle management and application consumption before determining the final VCF 9 architecture.
2. SDDC Manager is no longer the whole management story
SDDC Manager is one of the defining components of VCF 5.x.
It provides automation and workflow functionality for deployment, workload-domain creation, scaling, patching, upgrading and other Day 2 operations. VCF 5.x lifecycle workflows also perform health and interoperability checks before sequencing upgrades across components.
VCF 9 introduces a broader integrated management approach.
VCF Operations has moved beyond the role traditionally associated with standalone infrastructure monitoring. Broadcom describes VCF Operations in VCF 9 as a comprehensive private cloud management component covering operational intelligence and increasingly lifecycle-related functions.
VCF 9.1 takes this consolidation further through VCF Management Services. Broadcom’s 9.1 upgrade guidance describes fleet-level and instance-level services being consolidated into a common services architecture, with existing separate lifecycle-related appliances decommissioned as part of the transition from VCF 9.0.x.
For administrators accustomed to VCF 5.x, this changes both architecture diagrams and operational procedures.
The important question becomes less about which individual VMware appliance performs a task and more about how the VCF platform delivers the service across the private cloud.
3. Lifecycle management becomes more prescriptive
VCF has long provided managed lifecycle workflows, so lifecycle automation itself is not new in VCF 9.
The difference is the degree of platform standardisation.
VCF 5.x introduced useful lifecycle improvements. VCF 5.0 supported skip-level upgrades from selected VCF 4.x releases, while VCF 5.2 introduced a flexible Bill of Materials model that could reduce the need for separate upgrade and patch operations.
VCF 9 places additional requirements around lifecycle consistency.
For example, vSphere 9 uses image-based lifecycle management. Baseline-managed VUM clusters and standalone hosts are not supported by vSphere 9, and vCenter 9 does not manage ESX 7.0 or earlier.
That has direct consequences for organisations planning a VMware VCF 5.x to VCF 9.x upgrade.
Before upgrading, teams should identify:
- ESXi versions and hardware compatibility
- vCenter versions and topology
- cluster lifecycle-management mode
- vSAN architecture and disk groups
- NSX version and topology
- third-party VIBs and integrations
- backup products
- monitoring integrations
- storage and network dependencies
- certificate and identity configuration
- unsupported or deprecated hardware
- workload maintenance constraints
The upgrade should be treated as an infrastructure transformation programme, particularly where the existing estate has been running for several years.
4. VCF Operations becomes strategically more important
Many VCF 5.x environments use Aria Operations primarily for capacity, performance, alerting and infrastructure analytics.
VCF 9 changes the operational emphasis.
VCF Operations is positioned as a central element of the private cloud control and management experience, with capabilities covering infrastructure health, operational intelligence, compliance and lifecycle workflows.
VCF 9.0 introduced continuous configuration compliance monitoring against standards including CIS, NIST and custom baselines, together with broader identity and certificate management improvements.
VCF 9.1 continues this development with security patching, observability and operational improvements. For example, vCenter quick patch in VCF 9.1 is designed to deploy selected security fixes by updating only the affected binaries or RPMs rather than carrying out a conventional complete in-place patch.
For organisations subject to security frameworks and audit requirements, the move towards continuous configuration assessment can be as important as the infrastructure upgrade itself.
5. Automation moves closer to the centre of the platform
VCF 5.2 already had significant automation capability.
VMware Aria Automation 8.18, included within the VCF 5.2 generation, introduced improvements around private cloud quick start, modern IaaS consumption and infrastructure consumption.
VCF 9 builds on this approach through VCF Automation.
The objective is to provide infrastructure consumers with controlled self-service access while allowing platform teams to enforce governance, policy and standardisation.
Broadcom reports that organisations using VCF Automation have reduced both the time required to deliver application environments and the manual effort involved across the application lifecycle, based on a customer survey conducted in March 2026.
For a VCF 9 design, automation should therefore be considered during architecture workshops rather than being added after the infrastructure platform has gone live.
Questions should include:
What services will developers consume?
Which VM and application templates should be offered?
What network services can be requested?
How will IP addressing be managed?
Which policies determine placement?
How will quotas be enforced?
Which services require approval?
How will infrastructure-as-code interact with VCF APIs?
These are private cloud design questions, not simply automation product configuration.
6. The networking difference is integration, not a move from NSX-V to NSX-T
A common oversimplification is to compare VCF 5.x networking with VCF 9.x as an NSX-V to NSX-T transition.
That is incorrect for VCF 5.x.
VCF 5.0 already incorporated NSX 4.1, and VCF 5.2 added NSX 4.2 capabilities including improvements to virtual networking adoption, availability, performance and observability.
The more relevant difference is how networking and security participate in the wider private cloud operating model.
An upgrade assessment should examine existing Tier-0 and Tier-1 gateways, VLAN-backed networks, overlay segments, BGP design, edge clusters, load balancing, distributed firewall policy, IP addressing, DNS, MTU configuration and physical network dependencies.
Existing network design decisions frequently determine whether a VCF migration is straightforward or requires remediation before the platform upgrade begins.
7. HCX becomes more closely integrated with VCF migration planning
VMware HCX remains highly relevant where organisations must move workloads between existing VMware environments and new VCF infrastructure.
VCF 5.2 included HCX 4.10 capabilities aimed at improving large-scale and high-volume migrations.
With VCF Operations HCX 9.0, migration planning becomes more closely integrated with the VCF platform. Enhancements include a unified HCX Manager appliance, shared VCF licensing and SSO integration, plus migration planning that can begin in VCF Operations for Networks and synchronise into HCX for execution.
This can make HCX valuable not only as a workload movement tool but as part of a broader VCF 9 workload assessment and migration strategy.
Before migrating applications, organisations should classify workloads according to dependency, network requirements, downtime tolerance, migration method, data volume, business criticality and target landing zone.
The migration wave plan should be built from those facts rather than from VM inventory alone.
8. VCF 9 places greater emphasis on infrastructure efficiency
VCF 5.x already supports modern infrastructure features including vSAN Express Storage Architecture. VCF 5.1 added VCF support for vSAN ESA on NVMe-focused storage platforms.
VCF 9.x goes further with technologies aimed at improving hardware utilisation.
VCF 9 introduced NVMe memory tiering and additional storage efficiency capabilities. VCF 9.1 enhances the memory tiering model and Broadcom states that, in supported scenarios, the technology can reduce server costs by allowing colder memory pages to use NVMe capacity while hotter data remains in DRAM.
VCF 9.1 also adds enhancements for hardware acceleration, including GPU-related capabilities and network processing offload designed for high-performance and AI workloads.
These capabilities do not remove the need for capacity planning. They make good workload assessment more important because the target architecture can be designed around actual CPU, memory, storage and accelerator requirements rather than simply reproducing the capacity ratios of an older cluster.
9. Upgrading from VCF 5.x to VCF 9 requires assessment before execution
Broadcom’s own guidance characterises the move from VCF 5.2 to VCF 9.0 as a significant architectural evolution that introduces changes to management methodology and requires phased execution.
That is the right way to approach the project.
A technical VCF 5.x to VCF 9.x upgrade assessment should cover at least five areas.
First, establish the existing state. Document every management component, workload domain, vCenter, cluster, host, NSX object, storage platform, external integration and dependency.
Second, validate interoperability. Hardware, firmware, drivers, third-party products and VMware component versions must be checked against the supported target configuration.
Third, define the target VCF 9 architecture. Do not assume that existing workload-domain boundaries, cluster design or management topology should be copied unchanged.
Fourth, determine the transition method. Some environments are best upgraded in place. Others benefit from deploying a new VCF 9 environment and migrating workloads. Mixed estates may require both approaches.
Fifth, build a rollback and validation plan. Infrastructure upgrades should have explicit technical checkpoints, business validation criteria and recovery procedures.
Broadcom now provides a VCF 9.1 Upgrade Planning Tool specifically because the correct upgrade sequence can vary depending on deployed components, configuration and features.
Consult Circle VCF 9 design, upgrade, deployment and migration services
The technical capability of VCF 9 is only part of a successful modernisation project. Architecture decisions made before deployment determine how easy the platform will be to operate, scale, secure and upgrade over the following years.
Consult Circle provides VMware Cloud Foundation design, VCF upgrade, VCF deployment and workload migration services for organisations moving from existing vSphere and VCF environments to VMware Cloud Foundation 9.x.
A Consult Circle engagement can cover the complete transformation lifecycle, including current-state discovery, VMware workload assessment, VCF 9 architecture design, hardware and compatibility assessment, management-domain design, workload-domain planning, NSX network architecture, vSAN design, lifecycle planning, security architecture, automation design, deployment, upgrade execution and HCX workload migration.
For organisations running older vSphere environments, the engagement can also establish whether workloads should be imported, upgraded in place or migrated into a newly deployed VCF 9 environment.
This is particularly useful where an estate contains multiple vCenters, different hardware generations, separate security zones, legacy network designs or application dependencies that make a single upgrade method unsuitable.
A well-designed migration programme allows each workload group to follow the transition path that best matches its business and technical requirements.
Should you upgrade from VCF 5.x to VCF 9.x?
For most organisations, the answer should be based on operating-model requirements rather than feature count.
VCF 5.x remains an important generation of VMware Cloud Foundation and introduced capabilities that continue to shape the platform, including workload domains, SDDC Manager lifecycle automation, VCF Import, modern NSX networking and increasingly capable private cloud consumption.
VCF 9.x builds a different level of integration on top of that foundation.
The reasons to move are strongest where an organisation wants more centralised private cloud operations, integrated automation, improved lifecycle consistency, stronger configuration governance, modern application support, API-driven infrastructure management or greater efficiency from compute and storage infrastructure.
VCF 9.1 further develops that model by consolidating management services and adding operational, performance, infrastructure efficiency and security improvements. Broadcom describes VCF 9.0 as the architectural shift and VCF 9.1 as an optimisation of that foundation.
The key point is that VCF 5.x to VCF 9.x is not simply a version-number change.
It is an opportunity to review how private cloud infrastructure is designed, consumed and operated.
Organisations that begin with workload discovery, dependency analysis and target-state architecture can use the transition to remove years of accumulated infrastructure complexity. Organisations that treat it as a routine patching exercise risk carrying the same complexity into a newer platform.
For businesses evaluating VMware Cloud Foundation 9 migration services, VCF 9 upgrade consulting, VMware private cloud modernisation, VCF 9 deployment services or HCX workload migration, Consult Circle can provide the architecture, engineering and migration expertise needed to take the project from initial assessment through production deployment.
The most successful VCF 9 projects start before the upgrade window. They start with understanding the existing estate, defining the target operating model and establishing exactly how applications will move from where they are today to where the organisation needs them to run next.
VCF 9 upgrade
Want your VCF 9 upgrade plan reviewed?
Consult Circle assesses VCF 5.x estates, validates hardware and lifecycle readiness, and plans the upgrade or migration path to VCF 9 before the first bundle is downloaded.
Related Guides in This Series
- VMware Migration Services: How to Scope, Price and Run a VCF Move
- How to Migrate to VCF Using HCX: A Step by Step Walkthrough from Site Pairing to Cutover
- vSphere to VCF Migration and Upgrade Paths: In-Place, Side-by-Side or Greenfield
- VCF Migration Services for vSphere 7 and 8 Estates: What Changes After End of Support
- The Complete VMware HCX Migration Checklist: 70 Checks Before, During and After Cutover
- VMware HCX Migration Problems and How to Fix Them: Service Mesh, Network Extension and Failed Transfers
- Migrating from Legacy vSphere to VMware Cloud Foundation (VCF) Using HCX