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 "$outputPath\host-inventory.csv" -NoTypeInformation
Get-Cluster |
Select-Object `
Name,
HAEnabled,
DrsEnabled,
DrsAutomationLevel |
Export-Csv "$outputPath\cluster-inventory.csv" -NoTypeInformation
Get-VMHost |
Get-VMHostNetworkAdapter -VMKernel |
Select-Object `
VMHost,
Name,
PortGroupName,
IP,
SubnetMask,
Mtu,
ManagementTrafficEnabled,
VMotionEnabled,
FaultToleranceLoggingEnabled |
Export-Csv "$outputPath\vmkernel-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.
