VCF 9 upgrade readiness: Plan architecture, hardware, and execution

For VMware Cloud Foundation (VCF) environments, a VCF 9 upgrade is ready to approve when your team can produce reviewable evidence across architecture, compatibility, dependencies, capacity, recovery, testing, ownership, and sign-off. A version check or a hardware list covers one slice of that decision, and a change window needs all of it.

This guide is for infrastructure architects, VMware administrators, and the platform and cloud operations leaders who sign off on change. It follows the order you'll meet these decisions in practice: define readiness, inventory the environment, choose the target and path, prove compatibility and headroom, protect identity and recovery, sequence the work, test and accept it, and know when to wait.

Define what "ready to upgrade" means

For a VCF 9 upgrade, readiness is a documented state that someone outside the project team could review and agree with. Before you approve a change window, you should be able to point to a supported starting point and target, compatible infrastructure, known dependencies, enough headroom to work safely, tested recovery, sequenced work, named owners, and acceptance criteria everyone has agreed to.

That's a wider bar than a technical precheck. A passed platform precheck tells you the platform found no blocking errors, but it says nothing about whether applications will pass acceptance, whether the business window fits, or whether you can roll back if a stage fails, so treat it as one input to a larger go/no-go decision.

A compact table keeps that decision visible. Give each readiness domain a row, record where its evidence lives, and name the person who can close the gate. The example below shows how a team might track status partway through planning.

Supported versions, hardware, and other release-specific facts come from current Broadcom and VMware documentation, linked at each decision point below.

Inventory the current environment and its dependencies

Every later decision about architecture, capacity, sequencing, and recovery depends on the baseline you build here. At minimum, the inventory should cover:

• Platform release and domain layout
• Cluster topology, host models, firmware, and drivers
• Storage and network services
• Identity, observability, backup, and recovery tooling
• External integrations
• Workload criticality
• Support and lifecycle status for each component

Judge the inventory by whether it helps you decide something. A huge export of configuration fields can still leave you unable to say which workloads can move during maintenance, so collect what the decisions in this article need and go deeper wherever a gap shows up.

Freshness and ownership matter as much as coverage. Give every important record a source, the date it was last verified, and an accountable reviewer. Evidence without a reviewer goes stale quietly.

Tools that gather infrastructure assessment data can show utilization, performance, and capacity trends across the environment. Workload criticality, ownership, and business dependencies still come from the people who run those systems.

Record the platform and lifecycle baseline

Start with the facts that decide which upgrade paths are open to you. Capture the current VCF release and component versions, the state of each management and workload domain, lifecycle manager state, custom images, host profiles, add-ons, and support status.

Check that baseline against the current VCF 9.1 documentation from Broadcom and the compatibility guide covered in the hardware section below, instead of a static bill of materials saved in a project folder. Release details change between updates, and a saved copy won't tell you when it has gone out of date.

Flag any combination that's expired, unsupported, or unclear, and send it to a technical SME before anyone commits to a target date.

Map workloads and application dependencies

Platform sequencing that ignores applications is how a technically successful upgrade still ends in an outage. Group workloads by business criticality, recovery objectives, maintenance constraints, regulatory requirements, and dependency chains.

Then record which of these services each workload depends on: east-west and north-south traffic, DNS, NTP, directory services, certificate dependencies, IP addressing, load balancers, firewalls, observability, backup, replication, and third-party integrations.

Finally, name the application owners who will validate behavior. They should capture a pre-upgrade baseline so they have something concrete to compare against once the change is done.

Assign owners before planning the change

An inventory becomes a plan once each material domain has people attached to it. For each one, name a technical owner, a business owner, a validation owner, and an escalation path.

If a provider or partner runs part of the environment, write down which tasks are for your team, which are with them, and which are shared. Keep that record focused on who does what during this upgrade. Then name a decision owner for go/no-go, rollback, and acceptance. When those calls belong to "the team," they tend to stall at the worst possible moment.

Choose the target architecture and upgrade path

Your upgrade plan should document the target architecture and the upgrade path separately. The target architecture is the environment you want to end up with, and the upgrade path is the supported set of steps to get there. Picking the latest release settles which version you'll run, while the architecture decision covers how that environment will be built and operated.

For readiness purposes, the VCF 9 architecture questions that matter are management and workload domains, cluster boundaries, networking and storage implications, availability, operational ownership, and any design change that alters the upgrade path. [NEEDED: link to the VCF 9 category hub for broader architecture education once it's published and canonicalized.]

If the target architecture is still an open question, settle it before sequencing starts, with your own architects or through Flexential architecture and transformation services.

Confirm the supported starting point and target state

Treat the VCF 9 upgrade path as a choice you can defend with evidence. VMware's walkthrough on how to upgrade to VCF 9.0 explains that the process depends on the VCF version you run today, along with environmental, software, and hardware considerations. Use current official upgrade documentation, which holds the exact path for your release, to validate allowable starting versions, any intermediate steps, the target release, component dependencies, and prerequisite remediation.

Record the assumptions that could change the path. Custom lifecycle images, unsupported hardware, and constraints in external integrations are common ones.

Decide which changes belong in the upgrade

Every upgrade attracts other projects. Separate the work the upgrade requires from optional changes such as a redesign, hardware refresh, network change, workload migration, automation change, or operating-model change.

Bundling can make sense when two changes can't be pulled apart, such as hardware that has to be replaced before the target release will support it. It's much harder to justify when it complicates fault isolation, rollback, or acceptance. If several changes land in one window and something breaks, your team first has to work out which change caused it before deciding what to undo.

When workload movement is on the table, bring cloud migration planning into the same conversation so the move and the upgrade don't compete for one window.

Capture each decision in a record that lists the change, the reason for it, its dependencies, its owner, the test that proves it worked, its effect on rollback, and its approval state.

Validate management- and workload-domain implications

Domain-level dependencies should be visible before you sequence anything. Management-domain health and shared services affect every workload domain that depends on them, and workload domains can differ from one another in hardware, configuration, or operational ownership.

These implications vary by deployed VMware Cloud Foundation architecture and release, so work through questions instead of assuming a fixed design:

• Is the management domain healthy today, and what evidence shows it?
• Which shared services does each workload domain depend on?
• Where do workload domains differ in hardware, configuration, or ownership?
• Which operational dependencies cross domain boundaries?
• What happens to each workload domain if a management-domain stage fails?

Validate hardware, software, firmware, and capacity

VCF 9 hardware requirements can change between releases, so a static list ages quickly. Build this part of your plan around proof: what's installed, what the target supports, what has to change, who owns the fix, and when you'll recheck the evidence.

That proof covers compute, memory, storage, networking, drivers, firmware, lifecycle images, third-party integrations, and capacity headroom. The Broadcom Compatibility Guide is the authoritative source for hardware and software compatibility, and the release documentation linked earlier covers release-specific requirements.

Build current compatibility evidence

Check each deployed combination against authoritative sources and write down what you found. Here's an example of the fields a compatibility record might hold:

Compatibility applies to the actual combination of hardware, firmware, drivers, software, and add-ons. A supported host model paired with an unsupported driver is still an unsupported configuration.

When evidence is uncertain or stale, mark it as a stop condition. "Probably supported" has no place in a gate column.

Check capacity and operational headroom

The environment has to carry its workloads while parts of it are being upgraded or failing. Evaluate usable compute, memory, storage, network, and operational headroom across the scenarios you'll actually run into: maintenance, evacuation, restart, resynchronization, rebuild, backup, and rollback.

Steady-state capacity describes what the environment needs on a normal day. Temporary capacity describes what it needs while hosts are out of service, data is resyncing, or a rollback is underway. Plan around the temporary figure, because that's the one your maintenance window depends on.

Headroom feeds directly into workload placement and window decisions. If a cluster can't absorb an evacuated host, that shapes where workloads run during the change and how long the window has to be. Any numeric threshold you apply should come from a technical SME who knows your environment.

Verify network and infrastructure services

Many upgrade dependencies sit with teams outside virtualization. Your workload map shows who depends on these services; this step confirms each service will hold up through the upgrade. Check whichever of these apply to your environment: DNS, NTP, routing, MTU, latency, IP capacity, firewall rules, load balancing, certificates, directory reachability, management connectivity, inter-site links, and out-of-band access.

Inter-site links need an owner too. If you use an interconnection service such as Flexential Cloud Fabric, add that path and its owner to the dependency map so inter-site checks have someone accountable for them.

Map identity, security, logging, and recovery dependencies

These controls are what make an upgrade operationally acceptable, so they need owners and acceptance tests like any other dependency. Where compliance applies, your job is to validate your own requirements and the evidence your auditors expect, so bring your compliance team in before the plan is final.

Verify identity and access

Administrators and services need working access at every stage of the change. Review privileged roles, service accounts, directory integration, multifactor requirements, break-glass access, certificate ownership, and escalation access.

Then decide which access paths you'll test before and after each major stage. Break-glass access that has never been tested is a hope with a password attached.

Preserve security and observability

Security controls and operational visibility have to stay intact through the transition. Map firewall and segmentation dependencies, vulnerability and endpoint tooling, logging pipelines, alerts, monitoring integrations, and evidence-retention needs.

Some controls may behave differently during maintenance, such as alerts firing on planned host reboots. Decide ahead of time how you'll handle temporary monitoring changes or exceptions, who approves them, and how they close when the window ends.

Prove backup, recovery, and rollback readiness

Failure handling needs to be testable before the window opens. Start by separating the layers, since each one protects something different: platform backups, configuration backups, workload protection, snapshots where official documentation supports them, replication state, and application-consistent recovery.

A successful backup job tells you the job finished. Recoverability needs restore evidence that's recent and matched to the failures you're planning for. Pair that evidence with a documented rollback decision point, which is the moment in the sequence where the team decides to continue or reverse.

Sometimes the analysis shows that rollback is technically impossible past a certain stage, or would take long enough to breach recovery objectives. Treat that finding as a trigger for an architect review or a delay until you have an acceptable recovery alternative. For workloads that need protection beyond the platform itself, disaster recovery planning belongs in that same review.

Build the sequence, maintenance window, and communication plan

With the evidence in place, you can turn it into a change plan. Build it from these parts:

• The authoritative sequence from official documentation
• A dependency graph showing what has to finish before each stage starts
• Durations and buffers for every stage
• Decision points where the team chooses to continue, pause, or reverse
• Validation checkpoints
• A communication cadence
• An escalation path

Exact component order and commands belong in official documentation and your project runbook. The plan references them and adds everything specific to your environment.

Sequence components and workstreams

Use the current official VCF upgrade sequence as your technical baseline. Then layer on your environment-specific prerequisites, application dependencies, operational reviews, and handoffs between teams.

Look for work that's genuinely independent and can run in parallel. Anything that shares risk or depends on the same recovery path runs in series, even if overlapping it would save time.

Design maintenance windows around business impact

Size the window for everything that has to happen inside it: preparation, backups, prechecks, execution, validation, contingency, rollback decision time, and buffers for communication. A window sized only for the nominal upgrade duration leaves no room for the things that go wrong.

Tie the window to workload criticality, support coverage, staffing, change freezes, and downstream business events.

Define failure handling

A rollback plan becomes executable when each stage has specific answers written down in advance. For every stage, define:

• The failure signals that mean the stage is in trouble
• Who has authority to decide the next step
• The evidence to collect before acting
• The maximum acceptable delay before escalating
• The escalation route
• The next permitted action: stop, retry, escalate, continue, or roll back

These fields keep the decision from being improvised under pressure.

Test the plan and define acceptance criteria

Build your tests from material dependencies and the business services that rely on them. A generic platform-only checklist will miss the application that breaks when a certificate changes.

Keep the test types separate so each one has a clear purpose: prechecks, rehearsals, stage validations, application acceptance, recovery tests, security verification, and Day 2 monitoring.

Run prechecks and rehearsals

Run the official prechecks alongside checks specific to your environment. When something fails, record who owns the fix, and run the checks again after any change, because a result from before remediation no longer reflects the environment.

If you have a representative environment, rehearse more than the technical steps. Walk through the decision flow, communications, validation, and recovery so the team has practiced the calls it may have to make for real.

Define technical and business acceptance

"Upgrade complete" should mean more than the platform reporting success. Set acceptance criteria for platform health, management access, networking, storage, identity, security, monitoring, backup, recovery, applications, performance, and business service availability. Give each criterion an owner, an evidence type, a validation time, a failure response, and a sign-off authority. That way, acceptance becomes a set of recorded decisions with names attached.

Prepare Day 2 operations

The upgraded environment still needs support after the change team stands down. Update monitoring, backup, automation, operating procedures, configuration records, support handoffs, known issues, capacity baselines, and escalation information.

Define an observation period and the criteria for closing the change, sized to your workloads and risk tolerance. If you plan to share ongoing operations with a provider through a service such as Flexential managed infrastructure, build that handoff into the same updates.

Delay the upgrade when readiness gates fail

The table below lists common stop conditions, why each one matters, and the evidence needed to reopen the gate. An unresolved stop condition goes into the go/no-go decision as it stands, and its evidence requirement holds even when a date is at risk.

The conditions here are qualitative on purpose. Add numeric values only where current official documentation or your technical SME supports them.

Use an architect review when key decisions remain unresolved

Some gaps are hard to close from inside the project. An architect review makes sense when:

• The supported path is unclear
• Architecture change and the upgrade can't be separated
• Compatibility or lifecycle evidence conflicts
• Headroom is marginal
• Network, storage, identity, security, or recovery dependencies cross teams
• Rollback is constrained
• Ownership and acceptance can't be resolved

A useful review should leave you with a validated current state, a documented set of decisions, a risk and dependency register, direction on the target architecture, a remediation sequence, and a roadmap for next steps. If the review points toward running VCF in a provider environment, Flexential hosted private cloud is one option to weigh.

The more gates you close before the window opens, the fewer decisions your team has to make under pressure during your VCF 9 upgrade. If key decisions are still open, Schedule an Assessment to work through them with a Flexential architect.