> ## Content Index
> Fetch the complete content index at: https://www.mohammadsiddiqui.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# The First Ninety Days on 9.1
- URL: https://www.mohammadsiddiqui.com/the-first-ninety-days-on-9-1/
- Published: 2026-09-29T00:34:43.000Z
- Updated: 2026-10-04T00:10:16.000Z
- Description: You upgraded and nothing changed. Most estates land on the platform and keep operating exactly as before. Here's the sequence I'd work through instead.
- Author: Mohammad Siddiqui
- Tags: operations, lifecycle, architecture

Most of what I've written this year has been about getting to the platform. Upgrade paths, patch ordering, what breaks on the way. Useful, but it stops at exactly the wrong moment.

Because here's the thing I keep seeing. An organisation completes the upgrade, everyone breathes out, and then operations carry on exactly as they did before. Same runbooks, same per-cluster patching, same monitoring gaps. Six months later someone asks what the upgrade actually bought, and the honest answer is a supported version number.

The capability is sitting there. Nobody turned it on.

So this is the other half. A sequence for the first ninety days after you land on 9.1, in the order I'd do it, with the reasoning rather than just the list.

None of it is exotic. That's rather the point.

One assumption before we start

This assumes you've landed on 9.1 or 9.1.1 and the estate is stable. If you're still mid-upgrade, finish that first. Trying to enable new capability while clusters are on mixed versions is how you end up not being sure which thing broke.

## Weeks one and two: find out what you've actually got

Resist the urge to switch things on. Two weeks of looking costs almost nothing and changes what you do for the following ten.

Inventory your entitlement, not your assumption 

Pull what your licensing actually covers and compare it against what's deployed. The gap is usually larger than people expect, particularly around management packs and application monitoring. The [feature comparison document](https://www.vmware.com/docs/vmware-cloud-foundation-9-1-feature-comparison-and-upgrade-paths?ref=mohammadsiddiqui.com) is the reference for what sits in vSphere Foundation versus VCF Edge versus VCF. I have watched teams build a monitoring business case for something they were already entitled to.

Check which clusters are baseline-managed and which are image-managed 

This determines Live Patch eligibility, and it's the single most common thing left half-done after an upgrade. If you've got a mix, that's your first piece of real work. It's also cheap to do now and annoying to do later once change control has settled back into a rhythm.

Establish your current patch lag 

Pick the last three security advisories that applied to you. Measure the time from publication to remediation across the estate. That number is your actual risk position, and almost nobody has it written down. You'll want it as a baseline, because it's the metric that improves most visibly over the next quarter.

Audit certificates and their expiry dates 

Auto-renewal in 9.x fires 60 days before expiry, and it cannot be enabled for a certificate already inside that window without a manual renewal first. So anything expiring in the next two months needs handling by hand before automation can take over. See the [certificate management documentation](https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/certificate-management-9-0/?ref=mohammadsiddiqui.com) for the mechanics. Worth doing early because it's the kind of thing that turns into an outage on a Sunday.

## Weeks three to six: the things that reduce work

Now start enabling, beginning with whatever takes effort off the team. Momentum matters here, and people support a platform that makes their week easier.

Finish the move to image-managed clusters 

If week one found baseline-managed clusters, convert them. It unlocks Live Patch, which is the fast path for security patching, and you will want that available before the next Critical advisory rather than during it.

Turn on certificate auto-renewal 

Once the near-expiry certificates from week two are dealt with, enable automation. Note that management and instance certificates are configured separately, and NSX root CA rotation is disruptive, so plan that one into a window rather than assuming it is quiet.

Deploy the management packs you already have 

Start with the infrastructure ones since those are available across all editions. If you're on VCF or VCF Edge, the database packs are the ones that close the biggest operational gap, because the database layer is where infrastructure monitoring usually stops and somebody else's console starts. Eleven packs went GA at 9.1.1, each rebuilt to carry log content as well as metrics now that log management is converged into VCF Operations. Details in the [Operations for Integrations release notes](https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/release-notes/async-releases/vcf-operations-for-integrations-91-release-notes.html?ref=mohammadsiddiqui.com), and the packs themselves are on the [marketplace](https://vcf.broadcom.com/vsc/?ref=mohammadsiddiqui.com).

Point your ITSM integration at it 

If you run ServiceNow, this is the pack I'd install first. An alert on a dashboard is information. An alert that files a correctly categorised incident with the right assignment group is a process, and it changes whether anyone acts on what the platform detects.

## Weeks seven to ten: operations that hold up

Convert legacy log content 

If you built Log Insight content packs over the years, they can be converted now that logs and metrics live together. Unconverted custom content is institutional knowledge slowly going stale, and the person who wrote it has usually moved on.

Re-baseline your monitoring thresholds 

Metrics shift after a major upgrade. Thresholds that were tuned for 8.x will generate noise on 9.1, and noise trains people to ignore alerts. Give it a fortnight of data, then adjust. Tedious, worth it.

Set up drift detection 

Configuration drift is what turns a compliant estate into a non-compliant one without anyone doing anything wrong. Salt handles continuous compliance monitoring and drift remediation. Start with detection only, get comfortable with what it finds, then decide what to auto-remediate.

Write down the patch cadence 

Not an intention, a policy. Which layer gets patched on what rhythm, what the change category is for each, and who signs it off. Blanket approval weights are why security patches queue behind firmware updates. Different layers, different risk, different process.

## Weeks eleven to thirteen: prove it worked

This is the part people skip, and it's why phase two doesn't get funded.

Re-measure the patch lag 

Same three-advisory measurement from week one. If image-managed clusters and Live Patch are in place, this number should have moved. It's the clearest evidence you have that the upgrade bought something.

Count what you enabled against what you're entitled to 

One slide. Capabilities entitled, capabilities deployed, capabilities not yet enabled. Keep it current and put it in front of whoever approves budget. It's the artefact that turns 'we upgraded' into 'here's what we did with it'.

Check your compliance evidence is continuous 

Not whether the control exists, whether you can produce evidence it operated continuously. Point-in-time compliance and continuous compliance are different things and auditors have noticed. The [Security Configuration Guide](https://brcm.tech/vcf-scg?ref=mohammadsiddiqui.com) and the [STIG readiness guides](https://github.com/vmware/dod-compliance-and-automation/tree/master/vcf/9.x?ref=mohammadsiddiqui.com) are the references.

Decide what happens next 

Either you've got a case for the next phase, which might be VCF Automation and self-service, or you've found that the platform does what you need and nothing more is required. If you want a structured way to work out which, the [maturity assessment](https://www.mohammadsiddiqui.com/how-much-of-your-platform-are-you-actually-using/) is built for exactly this point. Both are legitimate outcomes. What isn't legitimate is drifting into month eight without anyone deciding.

## The short version

If you only take one thing: measure your patch lag in week one and again in week thirteen. It costs almost nothing, it's the metric that improves most visibly, and it's the number that makes the case for whatever you want to do next.

Entitlement audit done and the gap written down All clusters image-managed Certificates audited, near-expiry ones renewed by hand, auto-renewal on Management packs deployed, starting with infrastructure ITSM integration live if you have one Legacy log content converted Thresholds re-baselined after a fortnight of data Drift detection running in detect-only mode Patch cadence written into change policy Patch lag measured at week one and week thirteen One slide showing entitled versus deployed capability

Want a score rather than a reading list?

I built a [short self-assessment](https://www.mohammadsiddiqui.com/how-much-of-your-platform-are-you-actually-using/) covering the same ground. Fifteen questions, about four minutes, and it scores your estate across five areas with what I would do next in each. Nothing is sent anywhere, it all runs in your browser.

## Sources

- [VCF 9.1 and VVF 9.1 feature comparison and upgrade paths](https://www.vmware.com/docs/vmware-cloud-foundation-9-1-feature-comparison-and-upgrade-paths?ref=mohammadsiddiqui.com): what each edition actually includes.
- [VCF 9.1.1.0 release notes](https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/release-notes/vmware-cloud-foundation-9-1-1-0-release-notes.html?ref=mohammadsiddiqui.com): Bill of Materials and patch ordering.
- [VCF Operations for Integrations 9.1 release notes](https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/release-notes/async-releases/vcf-operations-for-integrations-91-release-notes.html?ref=mohammadsiddiqui.com): log convergence and the management pack changes.
- [New AI and Kubernetes operations capabilities in 9.1.1](https://blogs.vmware.com/cloud-foundation/2026/09/03/new-ai-and-kubernetes-private-cloud-operations-capabilities-in-vmware-cloud-foundation-9-1-1/?ref=mohammadsiddiqui.com).
- [Certificate management documentation](https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/certificate-management-9-0/?ref=mohammadsiddiqui.com): the 60-day auto-renewal behaviour.
- [VCF Security Configuration Guide](https://brcm.tech/vcf-scg?ref=mohammadsiddiqui.com) and [VCF 9.x STIG readiness guides](https://github.com/vmware/dod-compliance-and-automation/tree/master/vcf/9.x?ref=mohammadsiddiqui.com).
- [VCF Marketplace](https://vcf.broadcom.com/vsc/?ref=mohammadsiddiqui.com): management packs.

*Verify versions and behaviour against current documentation before you plan a change. Release notes move.*

*Views expressed here are my own.*