Broadcoms Anleitung für den Weg von VCF 5.2.x zu 9.1 macht das Hauptrisiko vor der Installation sichtbar: Das Ziel verändert mehr als Versionsnummern. Managementkomponenten wandern in das VCF-Operations-Modell, Voraussetzungen werden strenger und alte Annahmen zu Namen, Credentials und Integrationen können den Ablauf blockieren. Readiness ist daher eine eigene Projektphase.
Bedeutung für den Betrieb
Kleine Voraussetzungen verdienen frühe Aufmerksamkeit, weil sie automatisierte Workflows hart stoppen. Der Leitfaden nennt unter anderem kleingeschriebene FQDNs, funktionierendes Forward- und Reverse-DNS sowie Längenvorgaben für das vCenter-root-Kennwort. In gewachsenen Umgebungen hängen daran Zertifikate, Skripte, Monitoringreferenzen und Tresorrichtlinien.

Der Wechsel der Managementebene benötigt außerdem eine Verantwortungsmatrix. Welche Abhängigkeiten bestehen zu Aria-Komponenten? Wohin wandern Dashboards und Alarme? Welche APIs und Credentials verwenden Integrationen? Wie verändert sich die Kapazität während der Koexistenz? Backup, Logging, Authentifizierung, Depotzugriff und Lifecycle erhalten jeweils Validierung und Rückwegbeleg.
Ein kontrollierter Ansatz führt Planungs- und Precheck-Werkzeuge früh aus, behebt DNS- und Zertifikatsprobleme außerhalb des Fensters, testet Credentials, bestätigt freie Kapazität und erfasst den Ausgangszustand. Die Reihenfolge wird nach Möglichkeit in einer repräsentativen Umgebung geprobt. Go oder No-Go richtet sich nach offenen Befunden und Recovery-Pfaden.

Praktische Konsequenz
Die praktische Konsequenz: Ein VCF-9.1-Upgrade ist eine Migration des Betriebsmodells. Wer Naming, Identität, Observability, Kapazität und Wiederherstellung als echte Voraussetzungen behandelt, nutzt das Fenster zur Ausführung. Wer sie aufschiebt, entdeckt die Architektur während des Fensters unter Zeitdruck neu.