The VCF Upgrade Readiness Review: Decisions Before You Open the Planner

Broadcom’s VCF Upgrade Planner is a useful starting point, but it should not be the first planning activity.

The planner can help generate a tailored upgrade path from your current deployment and version inputs. It asks for the current deployment type, selected products, product versions, and target VCF 9.1 version, including inputs for vCenter, ESX, VCF Operations / Aria Operations, VCF Automation / Aria Automation, NSX, Dell VxRail, and current VCF versions. The tool also notes that vCenter and either ESX or VxRail must be selected to proceed with upgrade paths.

That is valuable.

But the planner cannot decide who owns DNS. It cannot tell you whether the network team has actually reserved the management IPs. It cannot negotiate a change freeze with application owners, decide whether the business accepts a phased maintenance approach, or confirm whether the rollback plan is more than “restore from backup and hope.”

That work belongs to the readiness review.

This runbook covers the practical decisions you should make before opening the planner so that the generated plan becomes executable instead of becoming another artifact that still needs operational translation.

Scenario

You are preparing an upgrade path toward VMware Cloud Foundation 9.1. Your environment may be a traditional VCF deployment, a VCF 5.2.x or 9.0.x estate, a vSphere-centric estate moving toward VCF, or a mixed environment with NSX, Aria Operations, Aria Automation, VxRail, or adjacent lifecycle components.

The team wants to open the VCF Upgrade Planner and start entering versions.

Before that happens, you need a readiness checkpoint that answers a more practical question:

Are we ready to produce an upgrade plan that the organization can actually execute?

Why This Matters Operationally

VCF 9.1 is not just a component version bump. Broadcom’s VCF 9.1 guidance calls out management-plane changes such as the replacement of the standalone 9.0 Fleet Management Appliance with Fleet Lifecycle and SDDC Lifecycle services running inside VCF Management Services, the introduction of a centralized VCF License Server, and the consolidation of VMware Identity Broker into VCF Management Services.

For VCF 5.2.x and 9.0.x environments using SDDC Manager, Broadcom’s upgrade path guidance says to upgrade VCF Operations and then follow lifecycle management workflows to upgrade to VCF 9.1. Broadcom also notes that, when NSX is present in certain vSphere-based starting states, the path is through VCF Installer converge workflows with convert/import operations rather than independent component upgrades.

That changes the readiness conversation.

The upgrade path is not only about versions. It is about control planes, identity, licensing, IP space, lifecycle ownership, communication, and maintenance sequencing.

Symptoms of a Weak Upgrade Plan

A weak upgrade plan usually looks complete on paper but fails during execution because the operational details were assumed instead of confirmed.

Typical warning signs include:

• The current inventory is based on memory, not exported evidence.
• The team knows the vCenter version but not the NSX, VCF Operations, Aria, VxRail, or edge-state dependencies.
• DNS and reverse DNS ownership is unclear.
• Management network IP capacity is treated as a future task.
• The license server is assumed to be “handled later.”
• The maintenance window is sized around the first click, not the full sequence.
• Rollback language is vague.
• Application owners are notified after the technical team has already committed to dates.

The VCF Upgrade Planner can help with the product-aware path. It cannot fix those gaps.

The Readiness Workflow at a Glance

Use the readiness review as a gate before entering data into the planner. The point is not to slow the project down. The point is to keep the planner from becoming a false sense of readiness.

What matters in this diagram is the ordering. The planner should consume verified facts. It should not be used as the first discovery exercise.

Readiness Decisions Before You Open the Planner

Decision: Define What Is Actually Being Upgraded

Start with a current-state inventory that can be reviewed by more than one team.

At minimum, capture:

The planner only works with the inputs you give it. If your inventory is stale, the generated path may still be internally logical but operationally wrong.

Decision: Classify the Starting State

The upgrade path differs depending on whether you are starting from full VCF, VCF 5.2.x, VCF 9.0.x, vSphere Foundation, vSphere-only deployments, or a converged environment with NSX and Aria components.

Broadcom’s guidance separates upgrade paths based on existing deployment type, including vCenter/ESX-only deployments, vCenter/ESX with Aria Operations or VCF Operations, deployments with NSX, deployments with Aria Automation, VCF 5.2.x or 9.0.x using SDDC Manager, and VCF 9.0.x environments with Fleet Management Appliance or VMware Identity Broker.

Before you open the planner, write down the starting-state classification in plain language.

Example:

“This is a VCF 5.2.x management domain with NSX, vSAN, Aria Operations managed by lifecycle tooling, and two VI workload domains. VxRail is not present.”

That sentence is more useful than a spreadsheet with five product names and no operating context.

Decision: Assign Upgrade Ownership

VCF upgrades cross team boundaries. Treat ownership as a prerequisite, not an afterthought.

You need named owners for:

If a decision has no owner, it is not ready.

Decision: Identify What Must Stay Online

Not every upgrade window has the same business risk.

Separate the platform into three groups:

This matters because VCF upgrade sequencing may touch management components, networking, compute, and observability in different phases. A technically valid upgrade path can still fail organizationally if the business expected zero impact and the platform team planned for rolling disruption.

Decision: Validate Management IP Space

VCF 9.1 Management Services planning deserves its own review.

Broadcom’s VCF 9.1 related-issues guidance states that up to 30 IP addresses may be required, that these can be added as ranges in the Lifecycle section of the VCF Operations UI, and that all IP ranges must be on the management network. It also notes an internal VCF services runtime range of 198.18.0.0/15, with documented alternatives if that overlaps with the management network.

Broadcom’s IP guidance for VCF Management Services says the minimum is 12 IPs and the maximum is 30 IPs for a fully scaled-out deployment. For upgrades, the UI expects a CIDR range within the existing management network, with a minimum /28 and up to a /27 for a fully scaled-out deployment.

Do not treat this as a form field.

Make a reservation table before the planner session:

If IP space is tight, solve that before the upgrade plan is generated.

Decision: Prepare FQDNs and DNS Records

The VCF Management Services wizard requires FQDNs for VCF services runtime, fleet components, instance components, Identity Broker, and the License Server. Broadcom’s guidance also states that all FQDNs must resolve to unique IP addresses outside the IP range provided for the VCF services runtime while still being inside the management network.

That detail is easy to miss.

Do not reserve a single generic block and assume the platform can consume it however it wants. Separate the runtime IP pool from the unique IPs backing required FQDNs.

Your DNS readiness check should include:

• Forward lookup validation.
• Reverse lookup validation.
• Lower-case naming convention.
• No stale records from failed lab attempts.
• No reuse of existing component FQDNs unless explicitly documented.
• Clear ownership for emergency DNS changes during the window.

DNS issues tend to show up late and look like product issues. Treat them as design inputs.

Decision: Plan Licensing Before the Window

Broadcom’s VCF 9.1 guidance identifies the Centralized VCF License Server as a new mandatory component for VCF and vSphere Foundation environments. It can be installed as a standalone OVA or as part of the installer, and the license server must have DNS A and PTR records.

That makes licensing a readiness item, not a post-upgrade cleanup task.

Before the planner session, confirm:

A license server dependency discovered during the execution window is a planning failure.

Decision: Validate Backups, Snapshots, and Support Bundles

The readiness review should define exactly what recovery evidence exists before execution.

That does not mean “we have backups.” It means:

• Backup jobs are current.
• Restore points are known.
• Restore method is understood.
• Component-level snapshot guidance is checked against the official upgrade documentation.
• Support bundles can be collected.
• Logs are retained somewhere outside the component being upgraded.
• The team knows which recovery actions require Broadcom support involvement.

For VCF upgrades, be careful with casual rollback language. A full-stack upgrade is not the same as patching a single appliance. Some phases may have a clear retry path. Others may require restore, support intervention, or forward-fix decisions.

The planner can describe sequence. It does not validate your recovery confidence.

Decision: Define the Maintenance Window Strategy

Do not ask, “How long does the upgrade take?” first.

Ask:

“What sequence of maintenance windows gives us the least operational risk while still moving the platform forward?”

A practical maintenance model usually has multiple windows:

Broadcom’s 5.2.x to 9.1 upgrade guide frames the transition as an orchestrated sequence that includes Aria Operations to VCF Operations, SDDC Manager, VCF Management Services, NSX, vCenter, ESXi hosts, and NSX Edges. Your environment may not match that exact sequence, but the operating principle still applies: break the change into phases that match control-plane risk.

Decision: Define the Rollback or Fallback Boundary

Every upgrade plan needs a fallback model, but the fallback model must be honest.

Use three categories:

Avoid writing “rollback” unless the specific phase is actually reversible.

Better language:

“If Management Services deployment validation fails, stop and correct IP/FQDN/API payload issues before continuing.”

“If a lifecycle task fails after component upgrade begins, collect logs, preserve task state, and engage support before attempting manual repair.”

The goal is not to predict every failure. The goal is to prevent improvisation.

Decision: Protect Workloads During Platform Work

A VCF upgrade is a platform event, but workload owners experience it as an application-risk event.

Before opening the planner, confirm:

• Cluster capacity supports maintenance operations.
• DRS behavior is understood.
• Host evacuation assumptions are realistic.
• NSX Edge placement and failover behavior are reviewed.
• Backup and replication jobs are not colliding with maintenance windows.
• Monitoring suppression is scoped, not global.
• Application owners know when to test.

If you have edge-sensitive workloads, latency-sensitive applications, or strict security segmentation requirements, include those teams before the planner output becomes a fixed change request.

Decision: Build the Communication Plan

The communication plan should exist before the technical plan is finalized.

At minimum, define:

Silence during a platform upgrade creates anxiety. Controlled communication creates room to work.

Optional Inventory Export Before the Planner Session

This PowerCLI snippet is not a replacement for SDDC Manager, VCF Operations, the planner, or official upgrade prechecks. It is a lightweight way to capture basic vCenter and host inventory evidence before the readiness review.

# Purpose:
# Export a lightweight vSphere inventory snapshot before VCF upgrade planning.
# Run from a workstation with VMware PowerCLI installed.

$timestamp = Get-Date -Format "yyyyMMdd-HHmm"
$outputPath = ".vcf-readiness-$timestamp"

New-Item -ItemType Directory -Path $outputPath -Force | Out-Null

# Connect to vCenter before running:
# Connect-VIServer -Server "vcenter.example.com"

Get-VMHost |
    Select-Object `
        Name,
        Version,
        Build,
        ConnectionState,
        PowerState,
        @{Name="Cluster"; Expression={$_.Parent.Name}},
        Manufacturer,
        Model |
    Export-Csv "$outputPathhost-inventory.csv" -NoTypeInformation

Get-Cluster |
    Select-Object `
        Name,
        HAEnabled,
        DrsEnabled,
        DrsAutomationLevel |
    Export-Csv "$outputPathcluster-inventory.csv" -NoTypeInformation

Get-VMHost |
    Get-VMHostNetworkAdapter -VMKernel |
    Select-Object `
        VMHost,
        Name,
        PortGroupName,
        IP,
        SubnetMask,
        Mtu,
        ManagementTrafficEnabled,
        VMotionEnabled,
        FaultToleranceLoggingEnabled |
    Export-Csv "$outputPathvmkernel-adapters.csv" -NoTypeInformation

Write-Host "Inventory exported to $outputPath"

Use the output as a review artifact. The important part is not the script itself. The important part is having evidence that can be compared against the planner inputs, SDDC Manager inventory, VCF Operations inventory, and the official upgrade documentation.

Runbook Stages

Stage: Freeze the Current-State Facts

Create a single upgrade intake sheet.

Include:

• Product versions and builds.
• Management domain and workload domain layout.
• NSX and edge topology.
• Aria / VCF Operations and Automation presence.
• VxRail presence, if applicable.
• Current known issues.
• Current certificates and expiration dates.
• Backup status.
• Monitoring/logging coverage.
• Support entitlement and case process.

Exit criteria:

The technical team agrees that the inventory is accurate enough to enter into the planner.

Stage: Build the Ownership Matrix

Create a RACI that names actual people, not teams only.

At minimum, include:

• VCF technical lead.
• Change owner.
• DNS owner.
• IPAM/network owner.
• PKI owner.
• Backup owner.
• Security reviewer.
• Application validation owners.
• Broadcom support contact path.
• Executive escalation contact.

Exit criteria:

Every required decision has a named owner and backup owner.

Stage: Validate Network, IP, FQDN, and Licensing Readiness

This is where many upgrade plans become real or fall apart.

Confirm:

• Management Services IP allocation.
• Minimum versus fully scaled IP allocation decision.
• Runtime CIDR overlap review.
• Unique FQDNs outside the runtime IP range.
• A and PTR records for the license server.
• Firewall rules.
• NTP consistency.
• Certificate readiness.
• Monitoring and logging targets.

Broadcom’s IP guidance also notes that the API method can be used for non-contiguous IPs or custom networks, including validation through POST /v1/vcf-management-components/validations and retrieval of validation results before deployment. That should be treated as an advanced planning path, not a last-minute workaround.

Exit criteria:

Network and DNS prerequisites are reserved, documented, and validated before planner input.

Stage: Confirm the Upgrade Path Assumptions

Now compare your starting state to Broadcom’s supported path guidance.

Questions to answer:

• Are we upgrading full VCF, converging into VCF, or upgrading vSphere Foundation?
• Is NSX present?
• Is Aria Automation present?
• Is VCF Operations already deployed?
• Is SDDC Manager present?
• Is VxRail part of the lifecycle path?
• Are any components outside the expected lifecycle model?
• Are we relying on independent component upgrades where Broadcom expects installer or lifecycle workflows?

Broadcom’s guidance explicitly distinguishes multiple starting states and upgrade paths, including cases where independent component upgrades are not the option when NSX is present.

Exit criteria:

The team has a written starting-state classification and no unresolved path assumptions.

Stage: Size the Maintenance Strategy

Translate the upgrade into windows.

For each phase, define:

• Start and stop time.
• Technical owner.
• Business impact.
• Validation step.
• Pause point.
• Escalation condition.
• Communication checkpoint.

Do not let the planner output become the maintenance strategy by default. The planner can help determine order. The operations team still needs to map that order to people, calendars, validation, and business risk.

Exit criteria:

The maintenance model has phase boundaries, owners, and validation gates.

Stage: Open the VCF Upgrade Planner

Only after the readiness artifacts exist should the team open the planner.

Use verified inputs:

• Current deployment type.
• Product selections.
• Product versions.
• Target VCF 9.1 version.
• VxRail presence and version, if applicable.
• NSX and Aria presence.
• Current VCF version, if applicable.

Do not guess. If an input is unknown, stop and collect evidence.

Exit criteria:

The generated plan is based on verified inventory, not assumptions.

Stage: Reconcile the Planner Output Against the Runbook

The planner output is not the end of planning. It is the start of execution design.

Reconcile the generated path against:

• Maintenance windows.
• RACI.
• IP/FQDN plan.
• License server plan.
• Backup and recovery plan.
• Application validation schedule.
• Monitoring and alert suppression plan.
• Support escalation path.
• Known issues and KBs.
• Official release notes, interoperability matrix, and hardware compatibility guidance.

Broadcom’s own 5.2.x to 9.1 guidance recommends validating the path against the interoperability matrix and consulting the VCF 9.1 release notes and hardware compatibility list before proceeding.

Exit criteria:

The planner output has been converted into an execution runbook with owners, windows, validation, and fallback steps.

Validation Checklist

Before the planner:

After the planner:

Fallback Guidance

If a readiness item fails, do not force the planner session.

Use this rule:

A failed readiness review is not a failure of the project. It is the project avoiding a bad maintenance window.

Common Gotchas

Treating the Planner as the Readiness Review

The planner helps produce a path. It does not replace inventory validation, ownership, DNS readiness, IP planning, or change governance.

Underestimating Management Services Planning

VCF Management Services brings IP, FQDN, DNS, runtime, and scaling decisions into the upgrade conversation. Broadcom’s guidance around 12 to 30 IPs, unique FQDNs outside the runtime IP range, and management network placement should be handled before execution planning.

Assuming Licensing Is a Cleanup Task

The centralized license server is a mandatory VCF 9.1 component according to Broadcom’s guidance, and it requires DNS planning.

Writing a Rollback Plan That Is Really a Wish

Rollback needs phase-specific detail. If the only recovery statement is “restore from backup,” the plan is not ready.

Forgetting the Communication Plan

Application owners rarely care that the upgrade sequence is technically correct. They care whether their service is available, whether they know when to test, and whether someone tells them what changed.

Conclusion

The VCF Upgrade Planner is where the upgrade path becomes product-aware.

The readiness review is where the upgrade path becomes executable.

Before you open the planner, make the decisions that matter: define the scope, classify the starting state, assign ownership, understand availability requirements, reserve IPs, prepare DNS, plan licensing, validate backups, phase the maintenance windows, define fallback boundaries, protect workloads, and communicate clearly.

A good VCF upgrade should feel boring during the maintenance window.

That usually means the hard decisions were made before the first planner input was entered.

External Sources

The following sources were used to validate version-sensitive and product-specific statements in this article. Recheck them before publishing or executing an upgrade, especially if Broadcom updates the VCF 9.1 documentation, upgrade sequence guidance, or known issues.

• Broadcom / VMware VCF Upgrade Planner
  https://vmware.github.io/vcf-upgrade-planner/
• Broadcom KB: Upgrade Sequence and Related Issues for VMware Cloud Foundation and vSphere Foundation 9.1
  https://knowledge.broadcom.com/external/article/440630/upgrade-sequence-and-related-issues-for.html
• Broadcom KB: Not all addresses from the VCF Management Services IP range are used
  https://knowledge.broadcom.com/external/article/440223/not-all-addresses-from-the-vcf-managemen.html
• VMware Cloud Foundation Blog: Modernizing Infrastructure, VMware Cloud Foundation 5.2.x to 9.1 Upgrade Guide
  https://blogs.vmware.com/cloud-foundation/2026/06/05/modernizing-infrastructure-vmware-cloud-foundation-5-2-x-to-9-1-upgrade-guide/

The post The VCF Upgrade Readiness Review: Decisions Before You Open the Planner appeared first on Digital Thought Disruption.