lifecycle

The Staged Path From vSphere 8 to VCF 9.1

Rushing a full adoption to hit a compliance date produces a worse VCF outcome than staging it. Five stages, three stopping points, a fourth option worth naming, and why going to 9.0 first may cost you a year.

Updated 3 November 2026

Broadcom’s 9.1 documentation has moved since this was written, so this is revision 4. The 12 October patch set now has component version numbers, which were an open item here. One claim about VMware vSphere Foundation entitlement was wrong and has been corrected in place. Several constraints that were previously community-sourced are now in Broadcom’s own KBs, and three new ones have appeared that affect Stage 0 discovery. The full list, and what is still unverified, is in the revision note at the end. All five diagrams have also been redrawn today, because the old ones rendered their body text at about seven pixels on a phone, which is the same as not having them.

A version of this conversation is happening in a lot of places right now. The customer runs vSphere 8, vCenter 8, vSAN 8 and Aria Operations 8.x. They hold VCF licences. Support dates are approaching. And the full VCF 9.1 adoption they want to do will not fit in the time available.

The destination is not in question. VCF is where the platform is going, the licences are already held, and the capabilities in the full stack are the reason the customer bought it. The question is sequencing, and specifically what happens when a support deadline and a platform programme collide.

Rushing a full adoption to hit a compliance date is the worst of both outcomes. You get a tenancy model designed under pressure, an operating model nobody was trained for, and a self-service platform the application teams route around. I have seen that outcome more than once, and it takes longer to recover from than it would have taken to do properly.

The staged approach below reaches the same destination. It puts the compliance deadline behind you first, then does the adoption work on a timeline that gives it a chance of succeeding. Every stage is a step toward full VCF, not away from it.

Before any of this: is there actually a deadline?

I wrote the paths above assuming the clock is already running. Worth pausing on that, because for a fair number of estates it is not, and the honest first question is whether this needs to happen at all this year.

vSphere 8.0 and VCF 5.x reach end of general support on 11 October 2027, which Broadcom confirmed in writing in October 2026, with technical guidance running beyond that. If you are on 8.0 Update 3 and patching normally, you are supported for roughly another year regardless of what anyone tells you about 9.x. That is not an argument for doing nothing. It is an argument for choosing your own date rather than inheriting one.

Confirmed since this was first published

When this went up the dates came from secondary tracking rather than a Broadcom page I could cite. They are now stated by Broadcom directly: vSphere 8.0 and VCF 5.x to 11 October 2027, VCF 9.0 to 17 September 2027, VCF 9.1.1 to August 2028. Still pull your own dates off the Product Lifecycle Matrix for the exact SKUs you hold before you put a number in a steering pack, and if your account team gives you a different date, theirs is the one that counts.

Path Zero: stay where you are, deliberately

There is a fourth option the original three paths did not name, and it is legitimate. Stay on vSphere 8, keep patching, and schedule the move for a window that suits the business rather than one that suits a renewal conversation.

When this is the right answer

You have just completed a hardware refresh. You are mid-way through a different programme that owns the same people. Your boot devices and Auto Deploy position mean Stage 0 would surface procurement you cannot fund this financial year. Or the estate is stable, patched, and nothing in 9.x solves a problem you currently have.

What it costs you

If you hold VCF or VVF subscription entitlement, you are paying for capability you are not running. That is the same waste the article argues against elsewhere, just at an earlier point on the line. Be honest about it in the business case rather than pretending the delay is free.

What you must still do

Resolve the perpetual to subscription question now rather than later, because that gate has commercial lead time and is independent of when you upgrade. Run Stage 0 anyway. Discovery is days of effort and it tells you whether your eventual upgrade is a four-week job or a hardware project.

The trap

Deciding not to decide. Path Zero is a position with a review date attached. Without one it becomes the same drift the Stage 2 section warns about, only with less supported runway left when you finally move.

The reason to say this out loud is that customers are being told the move is urgent, and for some of them it genuinely is. For others the urgency is somebody else's quarter. Knowing which situation you are in is worth more than any of the sequencing detail that follows.

Which 9.x, and why the obvious answer is wrong

If you do decide to move, the next question is which target, and this is where I have seen people lose a year without realising it.

The instinct is to go to 9.0 because it has been out longer and feels more settled. The problem is that support windows are set per release, not per major version. VCF 9.0 reaches end of general support on 17 September 2027, which is earlier than vSphere 8. VCF 9.1.1 runs to August 2028. Broadcom has since put it in its own words: stopping at VCF 9.0 does not extend the support runway.

Read that again if it did not land

Upgrading from vSphere 8 to vSphere 9.0 can leave you with less supported runway than you had before you started, and a full upgrade programme behind you. If those dates hold, 9.0 is a transit point rather than a destination, and the only sensible target for an estate moving now is 9.1.

Verify the dates for your own SKUs before you build a plan on this. But ask the question explicitly, because "we will go to 9.0 first and 9.1 later" sounds prudent and may be the most expensive sequence available.

The restriction that used to make you choose

Until recently there was a trap in this that nobody enjoyed explaining. Applying the latest security patches to an 8.0 Update 3 estate could land you on a build with no supported forward path, so you were choosing between staying current on CVEs and keeping the upgrade available. For a regulated customer that is not a choice. The security obligation wins, and the upgrade quietly becomes a bigger project than it needed to be.

Broadcom lifted that in October 2026. Estates on vSphere 8.0U3j, 8.0U3k, VCF 9.0.2 EP2 or VCF 5.2.4 can now move forward to 9.1.1 directly, so patching and the upgrade path stop competing.

Two things follow from it

If you deferred a patch to protect an upgrade path, that reason has gone and the deferral is worth revisiting this month rather than next quarter. And Broadcom’s own post warns the window may not stay open, because a future out-of-band patch could introduce a new restriction. If you are in that position, the case for moving sooner just got stronger.

Worth knowing alongside it: the VCF Upgrade Planner now maps your current state to 9.1.1, flags prerequisites and interoperability, and produces a sequenced roadmap that identifies safe stopping points, exportable into Jira or ServiceNow. That is this article’s argument with tooling attached, and it is a better starting point than a spreadsheet.

The gate before any path

Perpetual licences block the upgrade entirely

Customers holding perpetual entitlements must transition to subscription before they can upgrade to 9.1. This is not a technical constraint you can design around, and it applies to all three paths below. Establish it in writing before anyone books a change window.

One destination, three stopping points

The paths are cumulative, not alternative. Choosing Path A is choosing where to stop first.

The distinction that determines your scope is a naming problem more than a technical one.

VCF Operations is mandatory. In 9.x you license the environment through it. Licence files created on the Business Services console upload into VCF Operations and get assigned to vCenter instances from there. There is no way to license a 9.1 estate without it.

VCF Management Services is not mandatory. That is the installer-driven fleet layer: Fleet Lifecycle, SDDC Lifecycle, and the services that log management 9.1.x depends on. Broadcom documents running vSphere Foundation 9.1 without it as a fully supported deployment model, with Management Services deployable later as a Day-N operation.

Two similar names, very different scope implications.

What the platform requires, and what is genuinely optional at first.

How this maps to Broadcom's own pathways

Broadcom publishes three pathways to VCF 9.1, and they are worth knowing because they answer a different question from the three paths at the top of this article. Mine are about scope, meaning how much of VCF you turn on. Broadcom's are about route, meaning how you get your existing estate there. You need an answer to both.

Converge vSphere to VCF

The one Broadcom recommends. Fix prerequisites, upgrade vSphere and NSX as needed, then either deploy a new VCF Installer and convert, or import into an existing VCF instance. This is the route most vSphere 8 estates will take.

Upgrade an existing VCF environment

In-place, using VCF lifecycle management. No workload migration, so lighter effort, but hardware and configuration still need validating first. For estates already running VCF.

Deploy a new VCF environment

Build alongside and migrate workloads across. For hardware refreshes, data centre expansion, or where the current estate cannot meet the upgrade requirements. More work, but it is the only route that gives you a clean design and a rollback that actually exists.

Cross the two and the planning conversation gets much sharper. A customer taking the Converge route to Path A is a few weeks of work. The same customer taking Deploy New to Path C is a programme with a business case. Both are reasonable. They are not the same conversation and they should not share a slide.

A note on the convergence prerequisites, which people miss

Converging or importing is not version-agnostic. Broadcom's own FAQ is specific about the floor:

Converging vSphere into a management domain supports vCenter Update 3 or higher
Converting an environment running NSX 4.2 to a VCF management domain is supported
Importing clusters as workload domains requires vSphere 8.0 Update 3 and NSX 4.2 or above

If any part of the estate sits below those, you have a prerequisite upgrade before the upgrade, and it belongs in Stage 0 output rather than being discovered in a change window.

The staged roadmap

Five stages. The first three get you compliant and supported. The last two are the VCF adoption itself. They are scheduled work, not optional extras.

Stages 0 to 2 are the compliance work. Stages 3 and 4 are the adoption, and they belong in the same plan.

COMPANION PIECE

This post covers the sequencing: which stage, in what order, and why. The engineering detail for each stage, physical and logical topology, network and storage requirements, management plane changes and third party integrations including APIs, is in The Engineer's Companion.

Read this one to agree the plan. Read that one to build it.

Stage by stage

Expand any stage for the detail. The checkboxes are for your own pass through the list, nothing is stored.

Stage 0: Discover (days)

No software is installed in this stage. The purpose is to find the things that turn into procurement or field work, because those have lead times measured in weeks and they are the reason projects slip.

Confirm the licensing position. Subscription in place, or perpetual still to be converted. Get it in writing from whoever owns the contract. Pull current vCenter and ESX build numbers across the estate. Minimum source versions for a 9.1.0 target are vCenter 8.0 Update 3j and ESX 8.0 Update 3. Anything behind that needs a prerequisite upgrade first. Inventory boot device sizes across every host. Anything under 128 GB, and particularly SD or USB, needs addressing. Establish whether Auto Deploy is in use, and whether those hosts have local disks. This determines whether a Zero Touch Provisioning transition is in scope. Check DNS capability for the License Server. You will need both an A record and a PTR record. Run the licence counting exercise. 9.x requires a minimum of 16 cores per CPU even where the physical CPU has fewer. Run the VCF Upgrade Planning Tool and export the generated plan for your change record.

Output of this stage is a document, not a change. If Stage 0 finds a boot device problem or an Auto Deploy estate, you have found it at the cheapest possible moment.

Stage 1: Comply (weeks)

The upgrade itself, in an order chosen so that the riskiest parts happen while nothing user-facing is affected. Strict upgrade path validation applies: you can only target a version released after your current version's release date. Since 9.1.1 shipped on 3 September 2026, estates on 5.2.x or 9.0.x upgrade directly to 9.1.1 without stopping at 9.1.0 first, which removes a step and lands you on the newer Bill of Materials.

Deploy VCF Operations 9.1. Your Aria Operations 8.x environment upgrades into this. No workload impact. Deploy the VCF License Server. New headless appliance in 9.1, mandatory for both VCF and vSphere Foundation. Standalone OVA or through the installer. Confirm the A record and PTR resolve before proceeding. Upload licence files from the Business Services console into VCF Operations and assign to vCenter. Upgrade vCenter 8 to 9.1. Management plane outage only, scheduled once. Upgrade ESX and vSAN cluster by cluster. vMotion carries the workloads, so no guest downtime. Stop between clusters. Verify licence assignment after the vCenter upgrade. If you see vCenter instances not connected to a license server, or licence assignment failures, the License Server is missing or its DNS is wrong.

At the end of this stage the platform is licensed and supported on 9.1. That is the deadline met.

Stage 2: Stabilise (weeks)

The work that turns a completed upgrade into an operationally sound one. None of it is urgent, all of it gets harder the longer it waits.

Upgrade VM hardware and VMware Tools, handed to application owners on their own schedule. This is the only phase requiring guest reboots. Establish the patch cadence for the 9.1 stream and write it into change policy. Assign an owner for the Bill of Materials and release notes review. These are living documents in the 9.x era, not launch-day artefacts. Validate backup, monitoring and security tooling against the new versions. Capture the evidence your compliance obligations require, and confirm it can be produced continuously rather than at audit time. Complete any boot device or Auto Deploy to ZTP remediation identified in Stage 0.

Compliance and support are achieved at this point. This is a safe place to pause, though see the section below on what it costs to stay here.

Stage 3: Operate (months)

Where the VCF operating model begins. This is the stage that converts held entitlement into delivered capability, and it should have a date in the plan from day one rather than being picked up when convenient.

Deploy VCF Management Services using the VCF Installer. Adopt Fleet Lifecycle and SDDC Lifecycle for centralised patching rather than per-cluster vLCM operations. Deploy log management 9.1.x, which depends on Management Services being present. Convert any legacy Log Insight content packs. The convergence of logs into VCF Operations means management packs now carry both metric and log content. Review the management packs relevant to your estate, particularly the database packs if you run SQL Server, Oracle, PostgreSQL, MySQL or MongoDB. Move from baseline-managed to image-managed clusters if you have not already. This is what unlocks Live Patch eligibility.

Note the edition boundary: application and management packs, including the database ones, require VCF or VCF Edge rather than vSphere Foundation.

Stage 4: Adopt (quarters)

The full VCF stack. This is a programme with an operating model change inside it, and it deserves its own business case, governance and timeline. Everything before this stage was infrastructure work. This stage is organisational.

Design the tenancy model first: organisation and project hierarchy, quota approach, network isolation boundaries. This is expensive to change once real tenants depend on it. Select a network connectivity model deliberately rather than inheriting whichever one a previous deployment used. Deploy NSX and establish the networking design, including whether EVPN interoperability with an existing physical fabric is in scope. Deploy VCF Automation and populate the content catalogue with net-new templates first. Pilot self-service with one real organisation, not a synthetic test tenant. Bring existing workloads into the catalogue. This is usually what determines whether adoption spreads beyond the pilot. Add VKS, Data Services Manager and the rest of the stack as the use cases justify them.

Sequence this against business demand rather than platform capability. A self-service platform nobody asked for is an expensive way to run virtual machines.

Correction, 3 November 2026

An earlier version of this article, and the diagrams above, put VKS on the full-VCF side of the line. That is not right. Broadcom’s 14 October 2026 feature comparison places VKS, VM Service, vSphere Pod Service and Harbor in the vSphere Foundation column. What VCF adds is VKS multi-cluster lifecycle management, Secret Store Service, IaaS Policy Service, the ArgoCD Operator, Regional Harbor and the GitOps integration. A VVF customer has Kubernetes. What they do not have is fleet-wide lifecycle management of it. Read Path C above as adding Kubernetes at fleet scale rather than Kubernetes itself, and check your own entitlement before you design on either reading.

The order, and where the impact lands

Two phases carry no workload impact at all. Under time pressure, front-load them.

Minimum requirements to check against the fleet

Per ESX host on 9.x:

8 GB RAM minimum, 12 GB for production workloads
64-bit x86 with hardware virtualisation enabled (Intel VT-x or AMD RVI)
Boot disk of at least 32 GB, with 128 GB recommended for new deployments
32 GB of system disk space minimum
Boot bank rises from 500 MB to 1 GB. Existing 500 MB boot banks migrate automatically during installation, to either 1 GB or 4 GB.
One or more Gigabit or faster Ethernet controllers

For ESX-OSData the guidance is a separate persistent device of at least 128 GB, supporting a minimum of 128 TBW and delivering at least 100 MB/s sequential write. SD and USB remain supported for boot bank partitions, but using them for ESX-OSData is deprecated.

The two things that become hardware projects

Boot devices

Anything under 128 GB, particularly SD or USB, needs attention before you start. If a meaningful share of the fleet boots from SD cards, that is procurement and field work with a lead time, not something you resolve in a change window.

Auto Deploy

Deprecated in vSphere 9.x and slated for removal in a future major release. Hosts with local disks must transition to Zero Touch Provisioning as part of this upgrade. Stateless hosts with no local disks can continue on Auto Deploy for now but need a ZTP plan. If the estate was built on Auto Deploy, this is the largest concealed scope item in the exercise.

The doors that only open one way

Staging only helps if the stages are reversible, and some of them are not. These are the points where you should stop and be certain, because there is no going back and the article above does not make that clear enough.

Management Services deployment

Deploying VCF Management Services decommissions the Fleet Management Appliance, and it cannot be restored. Stage 3 is the one-way door in this plan. Everything before it is reversible in the normal sense; this is not.

The FQDNs you choose

Management Services FQDNs are permanent. Renaming means redeploying. Treat the naming decision as a design decision with sign-off, not something an engineer picks on the day.

Lowercase DNS

Capital letters in DNS entries cause deployment failures. Trivial, and it has cost people a day.

The depot gate

Configuring the fleet Software Depot is mandatory before other component upgrades proceed. Download tokens are replaced by activation codes from the Business Services console, so the old credential you have in a runbook will not work.

SDDC Manager UI

Deprecated, and slated for removal. Anything in your operational documentation that says "open SDDC Manager and..." has a shelf life.

Network reservations

VCF Services Runtime needs a /27, and VCF Automation a /29 for its nodes. Small, and in a tightly managed enterprise address space, not always quick to obtain.

Where this came from

Most of the one-way-door items above are drawn from community write-ups of real 9.1 upgrades rather than from a single Broadcom page, so treat those as field experience to verify rather than as documented product behaviour. The addressing is no longer in that category. KB 440630 now states it directly: a minimum of 12 and a maximum of 30 IP addresses, all on the management network, and the ranges need not be contiguous. Use that figure rather than the per-component reservations, which were the community reading of the same requirement. The Broadcom upgrade documentation remains the authority, and if it contradicts anything here, it wins.

Operating in a partially adopted state

This is the question people forget to ask, and it matters more than the upgrade mechanics. Running between stages carries real operational cost, and knowing what it is prevents a temporary position becoming a permanent one by accident.

During the transition, while clusters are mixed

Mixed 8.x and 9.1 clusters under one vCenter. Supported during the transition, but your operational runbooks now have two versions of the truth. Anyone troubleshooting needs to know which cluster they are on before they trust a procedure.
vMotion compatibility across the estate. Check EVC configuration before you start. Moving workloads between upgraded and not-yet-upgraded clusters is exactly what you will want to do during the window, and finding a compatibility block mid-migration is a bad time to discover it.
VCF Operations at 9.1 monitoring an 8.x estate. Works, and is the intended sequence, but expect gaps in the newer metrics and dashboards until the hosts catch up. Do not treat missing data as a fault during this period.
Two patch processes running concurrently. Until every cluster is on 9.1 you are maintaining both the old and new lifecycle approach. Keep the window short for this reason alone.

Stopping at Stage 2 for an extended period

The permanent temporary problem

Stage 2 is a supported state, not a comfortable one to occupy indefinitely. The compliance pressure that drove the work disappears the moment it is done, and without a date already in the plan, Stage 3 quietly becomes next year's problem. That is how estates end up paying for VCF while operating like vSphere.

Lifecycle is per-cluster rather than fleet-wide. Without Fleet Lifecycle you are running vLCM cluster by cluster. At ten clusters that is an inconvenience. At fifty it is a headcount conversation, and it scales linearly in a way fleet management does not.
No unified log management. Log management 9.1.x depends on Management Services. Until then, metrics and logs live in different places and incident investigation costs more time than it should.
Live Patch eligibility depends on image-managed clusters. If the estate is still baseline-managed, the fast security patching path is unavailable, which matters most during a Critical advisory when you least want to discover it.
Application and management packs are edition-bound. The database packs require VCF or VCF Edge rather than vSphere Foundation. If database visibility is an operational gap, staying at Stage 2 does not close it.
Skills decay. A team that upgrades in March and resumes adoption in November has forgotten the context, and the documentation written during Stage 1 has gone stale. The gap between stages has a real relearning cost.
Paying for unused entitlement. The clearest one. VCF licences held against a vSphere Foundation operating model means funded capability sitting idle.

How to prevent the drift

Put a date against Stage 3 in the same plan that carries the Stage 1 deadline. Not a vague intention, a scheduled piece of work with an owner.
Keep the Stage 1 and 2 documentation current rather than archiving it. It is the input to Stage 3.
Track the gap explicitly. A single slide showing which VCF capabilities are entitled but not deployed keeps the conversation alive at steering committee level.
Move to image-managed clusters during Stage 2 rather than waiting. It costs little then and unlocks Live Patch immediately.

The argument to take to the customer

This is not a case for doing less. It is a case for doing the same thing in an order that works.

If the customer holds VCF licences, they are already paying for capability the staged approach defers: fleet lifecycle, automation, NSX, VKS, the self-service model. Stopping at Stage 2 and staying there means carrying the cost of the full entitlement while running on native vSphere tooling. That is a real waste, and it is the strongest argument for treating Stages 3 and 4 as scheduled work rather than optional extras.

What the staging buys is the thing full adoption actually needs and rarely gets: time to design the tenancy model properly, time to train the operations team, time to pilot self-service with a real business unit rather than a synthetic tenant. Those are the activities that determine whether the platform gets adopted or worked around, and none of them compress well.

So the conversation is not compliance instead of VCF. It is compliance first, then VCF on a timeline that lets it land. Put a date against Stage 3 in the same plan that carries the Stage 1 deadline, and the sequencing reads as project management rather than avoidance.

Once the sequencing is agreed, The Engineer's Companion covers what each stage requires in topology, network, storage, management and integration terms.

What has changed since this was first published

Revision 4, 3 November 2026. Rechecked against Broadcom’s current 9.1 documentation. One claim here was wrong and is corrected above rather than quietly removed. The open item from revision 2 about the 12 October patch set is now partly closed. Several constraints have moved from community reports into Broadcom’s own KBs, and three new ones affect what you do in Stage 0.

The 12 October patch set, now with versions

Revision 2 recorded that these components had no version numbers on the release index. They still do not appear there, but the component patch pages now carry them: vCenter, ESX, vSAN and NSX at 9.1.1.0100, vSAN File Services at 9.1.1.0200, VCF Services Runtime at 9.1.1.0100, and VCF Operations at both 9.1.1.0100 and 9.1.1.0200. Read that list again. Operations is two patches ahead of vCenter, and File Services moved independently of vSAN. There is no single number that describes the estate, which is the point made at length elsewhere.

VVF entitlement, corrected

VKS sits in the vSphere Foundation column, not the VCF-only column, per the 14 October 2026 feature comparison. Corrected in the body above.

Fleet lifecycle does not cover everything

Host Profiles, Auto Deploy, vSAN over RDMA, two-node clusters, the iSCSI target service, rack awareness and LACP are compatible with VCF but not integrated with VCF Operations fleet management. If a cluster uses one of them, Stage 3 does not fully apply to that cluster. Worth checking before anyone promises fleet lifecycle across the estate. Source: feature comparison, footnote 3.

Two address ranges that will ruin a Stage 0

VCF Services Runtime uses 198.18.0.0/15 internally and it must not overlap the management network. It can be moved to 240.0.0.0/15 or 250.0.0.0/15, but only through a JSON specification file at deployment, so this is a discovery question rather than something to fix later. Separately, on 172.17.0.0/16 networks the licence server black-screens during boot and needs version 9.1.0.0200 or later, per KB 441526. That is Docker’s default bridge range, so it appears in more estates than people expect. Both from KB 440630.

Addressing, now documented

A minimum of 12 and a maximum of 30 IP addresses, all on the management network, ranges need not be contiguous. This supersedes the per-component reservations noted earlier, which were the community reading of the same requirement.

A date inside the planning window

Legacy VCF load balancing may continue until 30 May 2027 where Avi licences are purchased. Add it to the same timeline as the end of general support dates, because it lands first.

More deprecation, more decommissioning

Configuration drift management is now marked deprecated, which belongs alongside Auto Deploy and the SDDC Manager UI. The decommissioning list is also longer than this article had it: besides the 9.0 Fleet Management Appliance, the standalone VMware Identity Broker VMs, vRealize Suite Lifecycle Manager, VMware Identity Manager and Aria Log Insight all go after migration. Aria Operations for Networks cannot be upgraded through its own interface at all, only through Fleet lifecycle workflows.

Patch order, and a button not to press

Patch the VCF management services fleet lifecycle component first. The 9.1.1 release notes say plainly not to use the Upgrade All button in the VCF Operations interface until component dependencies are met.

Known issues worth reading first

KB 440282 (9.1 binaries not visible in VCF Operations 9.0), KB 440471 (cannot license vCenter after upgrading), KB 424533 (license assignment failure), KB 440407 (ESXi sync error after upgrading Operations from 9.0.2), KB 440459 (Fleet lifecycle import fails on a certificate SAN issue) and KB 441526 (the licence server issue above).

Still not verified

The lifecycle dates were confirmed in revision 3 from Broadcom’s 13 October post and I found nothing contradicting them, but the Product Lifecycle Matrix did not return readable content on this pass, so they are unchanged rather than reconfirmed. The patch releases above still carry no dates or build numbers on any Broadcom page I could find. Whether the back-in-time restriction remains lifted is also unconfirmed since revision 3.

Revision 3, 25 October 2026. Broadcom put the lifecycle dates in writing and lifted the restriction that forced a choice between patching and upgrading. The dates and the sections above have been corrected to match. What follows that is the revision 2 record, left as it was.

Lifecycle dates confirmed

vSphere 8.0 and VCF 5.x to 11 October 2027. VCF 9.0 to 17 September 2027. VCF 9.1.1 to August 2028. Previously taken from secondary tracking, now stated by Broadcom directly, and the 9.0 date is still the earlier one.

Back-in-time restriction lifted

8.0U3j, 8.0U3k, VCF 9.0.2 EP2 and VCF 5.2.4 can now go forward to 9.1.1. Patching an 8.0U3 estate no longer costs you the upgrade path. Broadcom notes a future out-of-band patch could reintroduce the restriction.

VCF Upgrade Planner

Maps current state to 9.1.1, flags prerequisites and interoperability, and produces a sequenced roadmap with safe stopping points. Exports to Jira and ServiceNow. Covered in the new section above.

Still outstanding

The 12 October patch set for the 9.1.1 components appears on the release notes index without version numbers. Check the Patch Releases 9.1.1.x page before quoting a specific build in a change record.

Revision 2, October 2026.

VCF 9.1.1

Generally available since early September 2026. If you are planning now, 9.1.1 rather than 9.1.0 is the realistic target and the minimum source versions should be rechecked against its notes rather than the 9.1.0 ones.

9.1.1.0100 components

Fleet lifecycle, SDDC lifecycle and migration service engine components released separately in late September 2026. Relevant if Stage 3 is in your near-term plan, because these are the Stage 3 components.

Nothing has changed on the gate

Perpetual still has to convert to subscription before you can upgrade. Broadcom's FAQ remains direct about it: customers with perpetual licences need to switch to subscription prior to upgrading. Subscription licence files replace the old 25-character keys.

Updated October 2026. I no longer work for Broadcom, and this article is written from public documentation and my own experience rather than from any internal source. Verify every version, date and requirement against current Broadcom documentation before planning a change. The lifecycle dates in particular are the ones most worth rechecking, and they are the ones this article now depends on most.

Sources

Upgrade paths and deployment

Licensing and the License Server

Requirements and compatibility

ESX hardware requirements
What's new in vSphere 9.0 (core licensing, boot bank changes)
Broadcom Compatibility Guide
Broadcom Product Interoperability Matrix
Product Lifecycle Matrix

Added in revision 2

Added in revision 3

Added in revision 4

Patch releases 9.1.1.x, the component patch index, and the per-component pages beneath it for vSphere, vSAN, NSX, VCF Operations and VCF Automation
KB 440630, upgrade sequence and related issues for VCF and vSphere Foundation 9.1, for the addressing requirements, the internal range conflict and the named known issues
VCF 9.1.1 and VVF 9.1.1 feature comparison and upgrade paths, version 9.1.1 dated 14 October 2026, for the entitlement correction and the fleet lifecycle exclusions
VCF 9.1 release notes index, for the patch cadence statement that releases are not synchronised across components and do not require a new bill of materials

Release notes

Verify every version, requirement and date against current documentation before planning a change. Release notes move, and the minimum source versions in particular are worth rechecking.

Views expressed here are my own. I no longer work for Broadcom, and this article is written from public documentation and my own experience.