architecture

You are estimating from the wrong number

Host count used to predict upgrade effort and no longer does. A VCF 9.x upgrade scales with component count, which barely changes with estate size, so the smallest estates carry the worst ratio.

Somebody in a planning meeting says: we did two hundred hosts last time and it took eleven weeks, this one is a hundred and eighty, call it ten. Everybody nods and it goes in the plan.

That is a sensible way to estimate. It has worked reliably for a long time, it is based on real experience rather than a spreadsheet, and the person saying it is usually the most credible one in the room.

It has also stopped working, and not because VCF 9 is harder. It stopped working because the thing being counted is no longer the thing that drives the effort.

What the old number was actually measuring

A vSphere upgrade had a shape. Upgrade vCenter, then move hosts through in waves, with a soak period and a rollback position at each one. The effort genuinely tracked host count, because hosts were what you had a lot of and everything else was a single appliance you did once.

So estimating by feel worked, because the relationship underneath it was real. More hosts meant more waves, more windows, more evacuations, more things to verify. Double the hosts and you were not far off doubling the elapsed time.

What you are upgrading now

A VCF 9.x upgrade is not that shape at all. Before you touch a single host there is a management plane, VCF Operations, automation, an identity broker, a licence server, a software depot, SDDC Manager, and NSX. Then vCenter. Then ESX.

Each of those carries its own version, its own ordering constraint, its own prerequisites, its own verification step and its own way of failing. They no longer even move together, because component patches are not synchronised, so there are a dozen versions to track rather than one.

Now look at that list again and ask which part of it changes when the estate gets smaller.

The answer is almost none of it

A forty-host estate and a four-hundred-host estate run the same component set, in the same order, with the same constraints. The host count only enters at the end, inside one stage. Everything before it is fixed cost.

Which puts the difficulty somewhere nobody expects

If most of the work is fixed and only part of it scales, then the ratio of effort to hosts gets worse as the estate gets smaller. The four-hundred-host estate spreads the platform work across four hundred hosts. The forty-host estate pays almost the same platform cost and has forty hosts to justify it against.

That is the opposite of how these conversations usually run. The large estate is assumed to be the hard one, it gets the programme manager and the dedicated team, and the small one gets handled by two people alongside their day jobs.

In practice the small estate often has the worse arithmetic and the thinner bench. It is also, in my experience, far more likely to be the one that discovers in month seven that it cannot finish in time.

What to count instead

Stop counting hosts first. Count these, in roughly this order of usefulness:

Stoppable stages

States you can pause at and still be supported. This is the real unit of a VCF upgrade. If you cannot stop at it, it is not a stage, it is a step inside one.

Components with an ordering constraint

Anything that must go before or after something else. Each one removes flexibility from the plan, which is what actually costs you when a window moves.

Change windows available before the deadline

Not windows in a year. Windows between now and your end of general support date, minus freezes. This is usually a much smaller number than people expect.

Approval lead time per change class

A two-week approval cycle on an eight-stage sequence is four months of calendar before anybody has done anything.

People who can actually execute

Not people on the team. People who can run the sequence at two in the morning and make a judgement call if it goes wrong.

Hosts

Still matters, but only inside the ESX stage, and by then it is the most predictable part of the whole exercise.

A rough method

Count the stages. Multiply by your honest elapsed time per stage, including the soak period and including the day somebody is on leave. Add the blackout weeks that fall inside that span. Then compare the result against the latest date you could start and still finish inside support.

Host count re-enters once, in the ESX stage, where it behaves exactly as it always did.

If that arithmetic produces a start date that has already passed, you have learned the most useful thing available to you, and you have learned it while there is still something to be done about it. The sequencing workbook walks through it properly, including the constraint capture, which is the part that changes the answer.

The sentence worth taking into your next planning meeting

Our last upgrade is not a useful comparison, because we were counting hosts and the effort is now in the components. Here is the stage count instead.

Where this came from

This framing came out of a reply from Justin Kaplan on the last edition. He made the point that having got his head around the actual size of a modern VCF 9.x deployment, his previous large-scale migrations now look small by comparison, and he had thought those were large at the time.

That is the thing exactly, and it is worth separating from a complaint about complexity. The deployment is not bigger in the sense of having more servers in it. It is bigger in the sense of having more independent things that have to be sequenced, and the old intuition did not have a slot for that.

If your last estimate was built from a host count, it is probably not wrong by a little.

Related: your estate no longer has a version number, the staged path from vSphere 8 to VCF 9.1 and the management plane post, and will the hardware come with you, which is the other half of the same estimate.