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:

Area	Evidence to Collect
vCenter	Version, build, appliance health, certificates, identity configuration
ESX / ESXi	Host versions, builds, cluster membership, image/profile state
NSX	Manager version, edge clusters, transport nodes, Tier-0/Tier-1 dependencies
VCF Operations / Aria Operations	Current version, integrations, collectors, management packs
VCF Automation / Aria Automation	Current version, identity dependencies, blueprints/templates
SDDC Manager	Version, domain inventory, lifecycle health, depot access
VxRail, if present	VxRail Manager version, cluster mapping, lifecycle ownership
Adjacent services	Backup, monitoring, logging, identity, PKI, DNS, load balancing

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:

Group	Examples	Planning Implication
Must remain available	Critical business apps, identity, DNS, backup, monitoring	Requires explicit impact review and communication
Can tolerate controlled impact	Internal apps, batch systems, dev/test workloads	Can be aligned to phased maintenance
Can be paused or deferred	Non-critical workloads, lab clusters, unused integrations	Good candidates for later waves

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:

Item	Required Decision
Management Services IP pool	CIDR or range confirmed and reserved
Future scale-out headroom	12 minimum versus 30 maximum decision
Internal runtime overlap	Confirm 198.18.0.0/15 does not overlap, or document approved alternative
DNS records	Forward and reverse records assigned
FQDN ownership	Naming convention approved
Firewall rules	Required management paths reviewed
Monitoring	New management services added to observability scope

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:

Licensing Question	Required Answer
Who owns license entitlement access?	Named owner
Where will the license server live?	Network, IP, FQDN
Are A and PTR records ready?	Confirmed
Is license assignment part of validation?	Yes / No
Who handles post-upgrade license alarms?	Named owner

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:

Window	Purpose
Readiness window	Final health checks, backups, DNS validation, binary staging
Management plane window	VCF Operations, SDDC Manager, Management Services, licensing
Network/control window	NSX management and edge-related work where applicable
Compute window	vCenter and ESX host rolling upgrades
Validation window	Application smoke testing, monitoring review, cleanup
Deferred workload-domain windows	VI domain upgrades or lower-risk phases

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:

Category	Meaning
Retry	The task can be safely retried after correcting a known issue
Pause	The upgrade can stop at a supported checkpoint while the team investigates
Recover	The team must restore, rebuild, or engage support based on documented guidance

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:

Timing	Communication
T-minus two weeks	Upgrade intent, scope, expected impact, owner contacts
T-minus one week	Final window confirmation, application testing expectations
T-minus 24 hours	Freeze reminder, escalation bridge, validation schedule
Start of window	Execution started, current phase
Phase checkpoints	Completed phase, next phase, issues if any
End of window	Completion status, known issues, validation request
T-plus one business day	Final summary, lessons learned, follow-up tasks

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:

Check	Pass Criteria
Inventory	Versions and builds exported or confirmed from authoritative systems
Starting state	Deployment type documented
Ownership	RACI complete
IP plan	Management Services IP pool reserved
DNS	Forward/reverse records planned and tested where possible
Licensing	License server deployment approach documented
Backups	Recent backup and restore expectations confirmed
Certificates	Expiration and trust paths reviewed
Maintenance windows	Phased windows drafted
Communication	Stakeholder plan ready
Support path	Entitlement and escalation process known
Risk log	Open risks assigned

After the planner:

Check	Pass Criteria
Planner output	Saved with date and input assumptions
Source docs	Release notes, upgrade docs, KBs, matrix, and HCL reviewed
Exceptions	Any unsupported or unclear condition assigned
Runbook	Planner steps translated into operational tasks
Go/no-go	Decision meeting scheduled with required owners

Fallback Guidance

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

Use this rule:

Failure	Action
Unknown product version	Stop and collect inventory
Unclear starting state	Stop and classify the environment
No IP space	Resolve IPAM/network design before planning
DNS owner unavailable	Delay planner session
License server plan missing	Assign owner and define deployment path
No backup evidence	Complete backup validation first
Maintenance window unrealistic	Re-phase the change
No application validation owner	Do not submit change request
Unsupported path suspected	Validate with official docs and support

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.