Upgrade Runway

Work backwards from your VCF end of general support date, through change freezes and approval lead time, to the latest date you could still start.

A month-by-month timeline with an arrow running backwards from the end of general support to the latest viable start date

Every upgrade tool tells you the sequence. None of them tell you whether the sequence fits. This works backwards from your end of general support date, through your change freezes and your approval lead time, to the latest date you could still start and finish.

Change one input at a time and watch which one actually moves the date. For most estates it is not the host count.

Runs entirely in your browser. Nothing you enter is sent anywhere.

Your constraints

Minor releases carry 27 months of general support, so a patch inherits its minor line’s date rather than getting one of its own. Confirm yours on the Product Lifecycle Matrix against the SKUs you hold.
Each path contains the one before it in scope.
Count only windows this platform can actually have.
Licence conversion, IP allocation, SFTP target, backup tool validation. Approvals, not engineering.
—Latest date you could start

—

today
Work Frozen Slack Prerequisites
Windows required
—
Windows available
—
Binding constraint
—

Where the time goes

StageWhat happensWindowsElapsed weeks
Total——

What this does not know

  • Whether your hardware passes. CPU support state, network and storage adapter end of life, and vSAN ESA device certification are per cluster, and a failure there turns part of this into a procurement project rather than a change window.
  • Your entitlement. Perpetual licensing blocks every path until it is converted, and that conversation runs on its own clock.
  • Contention. These windows are assumed to be yours. In most estates they are shared with storage, network and application changes.
  • Rework. No allowance is made for a stage that fails validation and repeats. If you want one, add it to the prerequisite weeks.
  • That there is no documented rollback for a 9.1 upgrade. The back-out plan is restore from backup, which is slower than most change records assume.

Stage durations and the order of operations come from The staged path from vSphere 8 to VCF 9.1. The reasoning behind counting stoppable stages rather than hosts is in You are estimating from the wrong number.

For the hop sequence and the bill of materials for each hop, use the Upgrade Path Advisor at VirtualBytes. That tool tells you what the sequence is. This one tells you whether it fits.

Free to use, including with customers and in internal planning packs. Nothing you type is sent anywhere, so there is no account, no telemetry and nothing to clear afterwards. The other tools are at mohammadsiddiqui.com/tools.

A planning aid, not a commitment. Verify every date against current Broadcom documentation before it reaches a plan.