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, and the distinction that decides your scope.

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.

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.

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.

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.

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.

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

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.