TL;DR · Key Takeaways
- The VCF 9.1 Upgrade Planning Tool is a free, browser-based tool at vmware.github.io/vcf-upgrade-planner. You enter your current stack and it builds a plan specific to it.
- It takes two things: your current environment type (vSphere-based or VCF-based) and the exact versions you run, then shows only the destinations you can actually reach.
- The output is a workflow split into discrete phases you can map to maintenance windows, plus resource and networking requirements, known pitfalls, and links to the matching docs.
- It is a planning aid, not an executor. It never touches your environment and it doesn’t replace the SDDC Manager precheck you still run later.
- Budget a /28 (14 usable IPs, 12 free minimum) for VCF Management Services. The tool surfaces that requirement while you’re still planning, not on the night.
- Export the whole plan or a single phase to PDF so the change ticket and the person running the window are reading the same steps.
In Part 3 I walked through the Planning and Preparation Workbook, which is where you record what your environment looks like and what it needs before an upgrade. This part is about the tool I open first, before I fill in a single workbook cell: the VCF 9.1 Upgrade Planning Tool. It answers a narrower question than the workbook, but it’s the question everyone asks first. Given what I run today, what’s the actual path to 9.1, and in what order?
I’ve planned enough of these to know where people lose time. It’s almost never the upgrade itself. It’s the two days spent cross-referencing the interop matrix, three KB articles and the docs to work out whether your particular mix of vSAN, NSX and Aria can even reach 9.1 in one pass. The Planning Tool collapses that into a few clicks, and it does it without asking you to log into anything. Let me show you what it is, how to drive it, and where it stops being useful so you don’t over-trust it.
What the Upgrade Planning Tool actually is
The VCF 9.1 Upgrade Planning Tool is an interactive, browser-based tool that the VCF team released in May 2026. It runs entirely in your browser at vmware.github.io/vcf-upgrade-planner, and the source lives on GitHub under vmware/vcf-upgrade-planner if you want to read it or file an issue. There’s no appliance to deploy, no login, and nothing that connects back to your fleet. You describe your environment, it generates a plan.
Why does a tool like this need to exist? Because 9.1 is deliberately flexible about where you start. You might be a standalone vSphere deployment with VCF Operations bolted on, a partial stack with vSAN and NSX, or a full VCF instance running Aria Automation. Each of those has a different order of operations to reach 9.1, and historically you pieced that order together yourself from product docs, KB articles and interop matrices. The tool takes your starting point as the input and hands back the order, so you’re reading one tailored plan instead of reconciling five generic ones.
How the tool builds your plan
The logic is simple once you see it. You give it two kinds of input, it filters the destinations you can reach, and it prints a structured plan for the destination you pick. Nothing about your answers leaves the browser.
What you feed it
First, whether you are a vSphere-based environment or a VCF-based one. Then the specific versions of what you run, so it knows if you’re on 9.0.x, a 5.2.x stack, or a standalone vSphere Foundation deployment with VCF Operations. That version detail matters because it decides whether you get a direct single-pass route or a staged one with an intermediate stop.
What it hands back
Once you select a destination, you get an overall upgrade workflow broken into discrete phases, so you can size each maintenance window separately instead of staring at one monolithic job. Alongside that it lists resource and networking requirements, the key considerations and pitfalls for your specific path, and links back into the VCF product documentation for each step. You can use all of it in the browser, or export the whole workflow or a single phase to PDF for offline use.
Inputs and outputs at a glance
| You provide | It returns | Why it matters |
|---|---|---|
| vSphere-based or VCF-based | Applicable destination scenarios | Hides paths you cannot take, so you don’t plan an impossible one |
| Exact current versions | Single-pass or staged route | Tells you if you need an intermediate stop before 9.1 |
| Chosen destination | Phased workflow + resource and network needs | Lets you size and book maintenance windows realistically |
| Nothing else | Pitfalls, doc links, PDF export | Gives you a document to attach to the change ticket |
Using the tool, step by step
There isn’t much ceremony here, which is the point. Open the tool, pick whether you’re vSphere-based or VCF-based, and set the versions to match what you actually run today, not what you think you run. Go and check SDDC Manager and VCF Operations for the real build numbers before you answer, because a guess here produces a plan for a different environment.
Next, look at the destinations it offers. If the destination you want is missing, that’s information: it usually means you need an intermediate hop first, or a component that is behind a minimum version. Pick your target, then read the generated workflow top to bottom. Note the resource and networking requirements early, because the VCF Management Services subnet is the one that trips people, and export the plan to PDF so it’s pinned to the change record rather than living in a browser tab you’ll close.
A worked example: a 9.0.2 full stack to 9.1
Say you run a full VCF 9.0.2 instance: management domain plus one workload domain, VCF Operations already in place, NSX and vSAN in use. You tell the tool VCF-based, versions 9.0.2, and pick 9.1 as the destination. The plan it gives you is a direct route, but it’s still broken into phases you can book separately. Here is roughly how that reads, with timings from real runs on a modest fleet. Treat the numbers as planning estimates, not promises, because host count and cluster size move them a lot.
The plan opens by telling you to upgrade VCF Operations first, then bring up VCF Management Services and the software depot, then SDDC Manager, then the domains. That order isn’t optional, and the tool surfaces it before you have committed to anything. It also flags the resource line that people miss: VCF Management Services wants at least 12 free IPs on the management VLAN, so plan a /28 that gives you 14 usable. Finding that out during planning is very different from finding it out with a change window open and a subnet that is one address short.
The riskiest rung on that ladder is Phase 4, the host reboots. Everything before it is appliance work that’s largely reversible with a snapshot and a backup. Once you start rolling ESX hosts through maintenance mode and reboots, you’re moving real workload around and leaning on vSAN or your storage to stay healthy under reduced capacity. That’s the phase I plan the most conservatively: I confirm every cluster can tolerate one host down, I check there are no lingering vSAN resync operations, and I never start it without a booked window long enough to finish the whole cluster. A half-upgraded cluster is the worst place to run out of change time.
Turning the plan into a change schedule
The tool gives you phases. It doesn’t give you a calendar, and that translation is where the planning actually earns its keep. I take each phase from the exported PDF and turn it into its own change record with its own window, its own rollback note, and its own go or no-go check at the start. Phases 1 through 3 (Operations, Management Services, SDDC Manager) are appliance work, and I’ll often group them into a single evening because each one is quick and reversible from a backup. Phase 4 onward, the domain work, gets its own window per domain, because that’s where the clock becomes unpredictable.
Sequence across domains, not just components
The tool’s workflow is ordered by component, but your risk is ordered by domain. I upgrade the management domain fully first and let it sit for a day or two so any latent problem shows up before I touch a domain carrying production workloads. Only then do I schedule each workload domain, one window each, least critical first. That deliberately spreads the work over more nights than the tool’s phase count suggests, and I’d take the extra calendar time over a rushed back-to-back run every time. If something odd surfaces after the management domain, you want room to stop and investigate, not a second domain already mid-flight.
Who needs to be in the room
The resource and networking output is not just for you. The /28 for Management Services is a networking team task, temporary vCenter IPs are theirs too, and the backup confirmation belongs to whoever owns your backup platform. I send those requirements out as soon as the plan is generated, days ahead, so nobody is chasing a free IP or a backup job status with the window already open. The plan is most useful as a shared document, not a private checklist.
What the tool does not do
This is where I want you to stay honest with yourself. The Planning Tool is a map, not the drive. It doesn’t read your environment, so it can’t know your certificates are about to expire, your passwords are stale, or your vSAN HCL database is out of date. Those are caught by the SDDC Manager precheck, which is a separate step you still run later in the process. The tool also doesn’t cover every permutation yet: at release, community feedback flagged gaps around VMware Cloud Director migration and some Supervisor and VKS import scenarios, and the team has been filling those in over time. If your destination isn’t offered, don’t force a workaround from memory. Check the docs the tool links to and confirm the path is real.
| Artifact | What it is for | Touches your env? |
|---|---|---|
| Upgrade Planning Tool | Work out the route and the phases | No, browser only |
| Planning and Preparation Workbook | Record the requirements the route needs | No, a document you fill in |
| SDDC Manager precheck | Prove the environment is actually ready | Yes, reads live state |
Pull the real build numbers from SDDC Manager and VCF Operations before you open the tool. A plan built on a guessed version is worse than no plan, because it looks authoritative and it’s wrong.
From the field
On one 9.0.2 site the plan looked trivial, a clean single-pass route, and the team nearly skipped reading the resource section. The Management Services subnet requirement was sitting right there in the output. Their management VLAN had exactly 10 free addresses. If we’d gone in blind, Phase 2 would have stalled halfway through deploying Management Services with no clean way forward mid-window. Instead we spent an afternoon reclaiming addresses and carving a proper /28 a week ahead of the change. The tool didn’t save the upgrade. It saved the window.
Run the Planning Tool on every upgrade, even the ones you think you know. It costs ten minutes and it catches the resource and ordering surprises while they’re still cheap to fix. Just don’t let it replace the precheck. It plans, it doesn’t verify.
Signs it worked
You know the planning step did its job when your change ticket has a PDF attached with named phases and rough durations, when the network team already has the /28 reserved before the window opens, and when nobody on the call is asking what upgrades first. If the answer to any of those is still open on the night, the plan wasn’t finished, whatever the tool printed.
The plan is not a green light. Before any phase that reboots hosts or redeploys appliances, take a fresh backup, confirm your rollback point, and run inside a booked change window. Nothing in an upgrade of this size is risk-free, and the appliance phases are only reversible if you actually captured the state first.
Common questions
Does the tool connect to my environment or send my data anywhere?
No. It runs entirely in your browser and you type the inputs yourself. That’s also why it can’t check live state like certificates or HCL, which is what the SDDC Manager precheck is for.
My destination isn’t in the list. Now what?
Usually it means you need an intermediate hop, or a component is below its minimum version, or that path isn’t covered yet. Open the docs the tool links, confirm the real route, and don’t improvise a path from memory.
Can I trust the timings in the plan?
Treat any duration as a planning estimate, not a guarantee. Host reboots in the ESX phase scale with host count and cluster size, so a big fleet can run far longer than a small one. Always book more window than the estimate.
Do I still need the Planning and Preparation Workbook?
Yes. The tool tells you the route and the requirements at a high level. The workbook is where you record the specific values for your environment and confirm each one is met. They’re complementary, not interchangeable.
References
VCF 9.1 Upgrade Planning Tool
Announcing the VMware Cloud Foundation 9.1 Upgrade Planning Tool
How to Upgrade to VMware Cloud Foundation 9.1
Related on this site: VCF 9.0 vs 9.1, VCF 9 Operations series, VCF 9 complete guide.
About The Author
DrJha