VMware Cloud Foundation 9.0.2 – VCF 9.x Upgrade, Lifecycle & Fleet Manager Explained

It has been a while since my last blog post on VMware Cloud Foundation, back then they were mostly related to components of VCF 5.x. That pause was deliberate. Over the past period, my role shifted heavily towards VCF-focused design work within PSO, requiring less writing and far more time spent inside actual architectures, lifecycle flows, design decisions, and customer constraints.

With the release of VMware Cloud Foundation 9.0.2, the VCF 9.x lifecycle model has reached a new level of operational maturity. In this post, we explain the key changes in VCF 9.0.2, how it impacts real-world lifecycle and upgrade scenarios, and why this build should be treated as a baseline for enterprise VCF 9.x environments

In this post, I will cover what VCF 9.0.x is really about, what changed in 9.0.2 compared to 9.0.0 and 9.0.1, how upgrade and migration paths look today, why lifecycle tooling and patch levels are critical, and why this release matters if you design, deploy, or operate VMware Cloud Foundation professionally.

VCF Basics : What VMware Cloud Foundation 9.0.x Represents

VMware Cloud Foundation (VCF) is VMware’s integrated private cloud platform that delivers compute, storage, networking, and cloud management as a single, validated stack. At its core, VCF combines:

• vSphere (compute)
• vSAN (storage)
• NSX (networking and security)
• Cloud management components for operations, automation, identity, and lifecycle

What differentiates VCF from a traditional “vSphere + add-ons” deployment is that it is opinionated by design. Architecture, compatibility, and lifecycle are predefined and enforced. In exchange, customers get predictable upgrades, integrated operations, and a platform that scales operationally, not just technically.

VCF 9.0.x is the most significant evolution of that platform since its inception.

VCF 9.0: A Major Architectural Reset

VCF 9.0 was not a routine major version bump. It fundamentally redefined how the platform is managed and operated.

From SDDC Manager to Fleet-Based Operations

Earlier VCF versions centered around SDDC Manager as the primary lifecycle and orchestration engine. With VCF 9.0, that model changed. Lifecycle, identity, certificates, licensing, and health are now centralized through VCF Operations, using a fleet-based model.

This shift enables:

• Consistent governance across multiple VCF instances
• Centralized lifecycle orchestration
• Better separation between platform operations and workload consumption

Integrated Lifecycle as a First-Class Capability

Lifecycle is no longer an afterthought or a collection of loosely coupled tools. In VCF 9.x, lifecycle is a core platform capability. ESXi, vCenter, NSX, and management components are upgraded as part of validated workflows, with dependency awareness built in.

Modernization and Cleanup

VCF 9.0 also removed or deprecated several legacy constructs such as host profiles, traditional baselines, and older federation mechanisms. While disruptive for some designs, this cleanup reduced technical debt and simplified long-term supportability.

VMware Cloud Foundation (VCF) 9.0 discontinues several legacy features to modernize infrastructure, replacing them with integrated SDDC Manager and vLCM functionalities. Key removals include Enhanced Linked Mode (ELM), Integrated Windows Authentication (IWA), vSphere Lifecycle Manager baselines, Storage I/O Control, Host Profiles, and Virtual Volumes (vVols).

Key Discontinued Features in VCF 9.0:

• vSphere Virtual Volumes (vVols): Deprecated in 9.0 and fully removed in VCF 9.1.
• Integrated Windows Authentication (IWA): Support removed for vCenter SSO; migration to Active Directory over LDAPS or Identity Federation is required.
• Enhanced Linked Mode (ELM): Replaced by unified management interfaces in SDDC Manager through vCenter Linking.
• vSphere Lifecycle Manager (vLCM) Baselines: Legacy VUM workflows are no longer supported, replaced by single-image management.
• Storage I/O Control (SIOC) & Storage DRS Load Balancer: Removed I/O latency/reservation-based load balancing and SIOC on individual datastores.
• Host Profiles: Deprecated in favor of vSphere Configuration Profiles.
• N-Port ID Virtualization (NPIV): Removed in 9.0.
• VCF Automation Pipelines: Not available in VCF Automation 9.
• Update Manager Download Service (UMDS): Functionality integrated into vLCM.
• vCLS (vSphere Cluster Service): Deprecated, with a recommendation to switch to “retreat mode“.

More deprecated functionality can be found in the Product Support Notes for VMware Cloud Foundation 9.

• PMem Discontinuation: PMem features will not be supported in VCF/VVF 9.0.
  Alternative Solution: VMware recommends using NVMe-based memory tiering, which provides low-latency, high-capacity memory, supported in VCF 9.0.
• Platform Support: Specific server models (SKUs) supporting PMem will not be listed in the Broadcom Compatibility Guide for 9.0.
• Upgrade Path: Customers using PMem in 8.x must transition to alternatives before upgrading to 9.0.

This change is part of a broader push towards standardized, high-performance NVMe storage for memory extension, replacing specialized hardware.

Also, VMware Identity Manager 3.3.x has no in-place upgrade to VCF 9.0. VMware Identity Manager or VIDM will continued to be managed by VMware Aria Suite Lifecycle 8.x.

vIDM to VIDB in VCF 5.x – No Migration, Only Redesign

With the move to VCF 5.x / VCXF 5.x, VMware has fundamentally changed how identity is handled across the platform.
One of the most impactful changes is the deprecation of VMware Identity Manager (vIDM) and the introduction of
VMware Identity Broker (VIDB).

vIDM – What It Did

In VCF 4.x, vIDM acted as a full identity provider and authentication hub. It handled user and group synchronization,
SAML federation, MFA integration, and authentication for vCenter, NSX, and the Aria Suite.
In many environments, vIDM became a critical control-plane dependency.

No Migration Path from vIDM to VIDB

There is no supported migration path from vIDM to VIDB. This is not a traditional upgrade.

• vIDM cannot be upgraded or converted to VIDB
• Configurations, users, groups, and federation settings cannot be imported
• All SAML trust relationships must be recreated

From an upgrade perspective, this means vIDM is removed and VIDB is deployed clean.
Identity integration must be redesigned as part of the VCF 5.x upgrade.

What VIDB Is (and Is Not)

VIDB is not a replacement for vIDM in terms of functionality.
It is a lightweight identity broker that delegates authentication to an external enterprise IdP.

• No local users or groups
• No MFA or conditional access logic
• No application catalog or identity lifecycle

VIDB relies entirely on an external IdP such as Microsoft Entra ID, Okta, or Ping Identity to perform authentication.
Authorization remains enforced within VMware components through roles and permissions.

Upgrade and Design Impact

The move from vIDM to VIDB is an architectural change, not a tooling change.
It must be treated as a first-class workstream during a VCF 5.x upgrade.

• External IdP readiness is mandatory
• All identity integrations must be redefined
• Access models and role mappings must be validated post-upgrade

Handled correctly, VIDB enables a cleaner, enterprise-aligned identity architecture.
Handled poorly, it becomes a major upgrade risk.

What’s New in VMware Cloud Foundation 9.0.2

VCF 9.0.2 is a patch release, but one that removes several real-world blockers that surfaced during early 9.x adoption.

1 GbE Management Network Support for Import

One of the most impactful changes in 9.0.2 is official support for 1 GbE management networks during brownfield import workflows.

Earlier 9.0.x releases implicitly assumed higher-bandwidth management connectivity. In practice, that excluded:

• Legacy datacenters
• Smaller environments
• ROBO or edge-style deployments
• Lab and staging platforms

With 9.0.2, those environments can now be imported into VCF without redesigning the management network first. For many customers, this single change determines whether VCF adoption is feasible at all.

Lifecycle Workflow Hardening

VCF 9.0.2 includes numerous lifecycle improvements that matter most to operators:

• Stronger pre-check validation
• More resilient bring-up and import workflows
• Better handling of partial failures
• Improved error messaging and state consistency

These changes are not headline features, but they directly influence trust in lifecycle automation.

Operational Refinements

Small UI and workflow refinements reduce friction during day-to-day operations. Individually subtle, collectively meaningful—especially in environments that evolve frequently.

VCF 9.0.2 vs VCF 9.0.0/9.0.1: What Changed

Understanding where 9.0.2 fits requires context:

• 9.0.0 introduced the new architecture and operational model
• 9.0.1 stabilized early adoption issues
• 9.0.2 removes adoption blockers and hardens lifecycle execution

If 9.0.0 defined the direction, 9.0.2 makes that direction viable in real environments.

VCF 9.x Upgrade Paths: Import, In-Place, and Transitions

Brownfield Import

Existing vSphere environments can be imported into VCF using supported workflows. With 9.0.2, the bar for doing so is significantly lower from a network perspective.

Design considerations include:

• DNS, NTP, and certificate readiness
• Storage compatibility (especially deprecated features)
• Version alignment before import

Upgrading Existing 9.0.x Environments

Upgrading from 9.0.0 or 9.0.1 to 9.0.2 is strongly recommended before expanding or importing additional workloads. The lifecycle improvements alone justify the upgrade.

Upgrading from VCF 5.x: Why Lifecycle Tooling Becomes Critical

Upgrading from VMware Cloud Foundation 5.x to 9.x is not a single upgrade operation. It is a multi-stage transition between two fundamentally different lifecycle models.

VCF 5.x environments are centered around SDDC Manager for infrastructure lifecycle and Aria Suite Lifecycle Manager (ASLCM) for Aria Operations and Automation. In VCF 9.x, lifecycle ownership shifts to Fleet Manager, integrated into VCF Operations, which orchestrates lifecycle for the entire platform.

Stabilize and Patch the Existing VCF 5.x Environment

Before any transition, the existing VCF 5.x environment must be upgraded to a supported and stable patch level. This includes ESXi, vCenter, NSX, vSAN, and the Aria stack. Skipping this step commonly results in blocked upgrade paths later.

Upgrade Aria Suite Lifecycle Manager First

Aria Suite Lifecycle Manager, ASLCM, acts as a transitional tool. It is used to upgrade Aria Operations and Automation to versions that are compatible with VCF 9.x. At this stage, ASLCM still owns lifecycle for Aria components.

Transition Lifecycle Ownership to Fleet Manager

In VCF 9.x, Fleet Manager becomes the lifecycle authority. Aria components are brought under platform-level lifecycle control, and independent upgrades via ASLCM are no longer the standard model.

Import or Upgrade into VCF 9.x

Most real-world environments use a brownfield import into VCF 9.x rather than an in-place upgrade. This approach reduces risk, allows better control, and aligns well with the new fleet-based operational model. With VCF 9.0.2, management networks with 1 GbE bandwidth are now supported for import scenarios.

Post-Transition Lifecycle Model

After transition, Fleet Manager orchestrates lifecycle for the VCF platform. ASLCM becomes secondary or obsolete for day-to-day operations, and lifecycle is executed through validated platform workflows.

Aria Suite Lifecycle Manager vs Fleet Manager

Historically, Aria Suite Lifecycle Manager (ASLCM) was responsible for deploying and upgrading Aria components.

In VCF 9.x, that responsibility largely shifts to Fleet Manager, integrated into VCF Operations. Fleet Manager orchestrates lifecycle operations across the entire stack as a single platform workflow.

Key implications:

• ASLCM may need to be upgraded to a minimum supported patch level before transition. ASLCM 8.18 Patch 6 has recently been released, which enables “installation of VCF Operations fleet management appliance 9.0, 9.0.1, or 9.0.2”
• Patch mismatches can block upgrades
• Lifecycle ownership becomes centralized and enforced

Lifecycle is no longer optional tooling—it is the backbone of the platform.

Why Patch Levels Matter in VCF 9.x

In VCF 9.x, patch levels determine:

• Supported upgrade paths
• Import capabilities
• Lifecycle stability
• Feature availability

Running early 9.0.x builds without subsequent patches significantly increases operational risk. From a design and operational standpoint, VCF 9.0.2 should be treated as a baseline, not an option.

Design and Operational Observations

• Lifecycle planning must be part of initial design
• Expect more management appliances and plan capacity accordingly
• Re-evaluate storage and networking assumptions
• Identity and federation models have changed significantly

Conclusion

VMware Cloud Foundation 9.0.2 marks an important maturation point for the 9.x platform. It does not redefine the architecture introduced in 9.0, but it removes several practical blockers that limited adoption.

Support for 1 GbE management networks, hardened lifecycle workflows, and improved operational consistency make VCF 9.x far more approachable for real-world environments.

The pause in writing about VCF coincided with moving deeper into PSO design work. That experience reinforced one thing: VCF succeeds or fails on lifecycle execution. With 9.0.2, VMware is clearly moving in the right direction.