Der Upgrade-Pfad: warum du bei FortiOS, GitLab und Proxmox keine Version überspringen darfst

Von FortiOS 6.4.9 auf 7.6.4 sind es sechs Installationen, nicht eine. Das ist keine Meinung, sondern das, was Fortinets eigenes Upgrade Path Tool für eine FortiGate-60F ausrechnet: 6.4.9 → 6.4.11 → 7.0.12 → 7.0.14 → 7.2.10 → 7.4.7 → 7.6.4 (Abruf 19.08.2026). Zwei dieser Sprünge verlassen den Zweig nicht einmal, in dem sie beginnen. Wer stattdessen die Zieldatei direkt einspielt, hat kein Wartungsfenster gespart — er hat es gegen einen Vorfall ohne Termin getauscht.

Ein Upgrade-Pfad ist die geordnete Liste der Versionen, die du installieren musst, um von deinem Stand zum Zielstand zu kommen. Er ist nicht dasselbe wie „alle Versionen dazwischen“: Hersteller prüfen bestimmte Punkt-zu-Punkt-Übergänge, und der Pfad ist der kürzeste Weg durch diesen getesteten Graphen. Fortinet benennt den Handel offen — „Other paths may work, but only the shortest validated path is shown.“ Alles außerhalb des Graphen ist nicht verboten, es ist ungetestet, was im Produktivbetrieb auf dasselbe hinausläuft.

Bruchbild 1: die Konfiguration wird nicht übersetzt

Bei einer Firewall ist die Konfiguration kein Zubehör, sie ist das Produkt. Jede FortiOS-Version bringt Änderungen am Konfigurationsschema mit und übersetzt beim ersten Start die Konfiguration der Vorgängerversion. Fortinets Vor-Upgrade-Checkliste im Firmware Upgrade Guide verwendet darauf genau einen Satz: „Skipping intermediate versions may cause configuration issues.“ Das Unangenehme daran ist, dass das Gerät trotzdem hochkommt. Es bootet, es routet, die Oberfläche ist grün. Was fehlt, fehlt still — und es finden es nicht die Admins im Wartungsfenster, sondern die Nutzer am Montagmorgen.

Bruchbild 2: die Migration ist nicht mehr im Paket

GitLab schiebt große Datenumbauten als Hintergrundmigrationen in den laufenden Betrieb. Das funktioniert nur, wenn jede Migration fertig werden darf, bevor der Code ankommt, der auf ihr aufbaut. Daraus folgen die Pflichtstopps — seit GitLab 17.5 liegen sie berechenbar auf x.2, x.5, x.8 und x.11.

Was danach passiert, steht in GitLabs Entwicklerdokumentation: Eine Hintergrundmigration wird erst nach dem nächsten Pflichtstopp abgeschlossen, ihr Code danach entfernt. Wer den Stopp überspringt, installiert eine Version, die einen Datenzustand voraussetzt, den nur der entfernte Code herstellen konnte. Die dokumentierte Folge: „Dependent migrations may fail, or the application may not function, because a required migration was removed.“

Bruchbild 3: das Betriebssystem springt mit

Proxmox VE ist Debian. Proxmox VE 8 sitzt auf Debian 12 (Bookworm), Proxmox VE 9 auf Debian 13 (Trixie). Der Sprung von 8 auf 9 ist damit zugleich ein Debian-Distributionswechsel — und Debians Release Notes zu Trixie lassen keinen Spielraum: „Only upgrades from Debian 12 (bookworm) are supported.“

Proxmox formuliert die passende Voraussetzung im Upgrade-Leitfaden: „Upgraded to the latest version of Proxmox VE 8.4 on all nodes.“ Wer noch auf Proxmox VE 7 steht, hat nicht ein Upgrade vor sich, sondern zwei Distributionswechsel: erst auf 7.4, dann auf 8.4, dann auf 9. Bei hyperkonvergentem Ceph kommt davor ein eigener Pfad — Proxmox verlangt Ceph 19.2 Squid, bevor das Plattform-Upgrade auf 9.0 überhaupt beginnt.

Drei durchgerechnete Beispiele

Die GitLab-Zeile listet die Pflichtstopps, die die Dokumentation zwischen diesen beiden Ständen nennt; jeder davon ist eine eigene Installation mit anschließender Wartezeit. Die FortiOS-Zeile ist die Antwort für ein Modell an einem Tag. Der Preis des Wartens lässt sich am selben Werkzeug ablesen: Dieselbe FortiGate-60F braucht von 7.4.12 auf 8.0.0 noch zwei Installationen (7.6.7, dann 8.0.0), von 7.2.11 aus drei (7.4.11 → 7.6.7 → 8.0.0) und von 6.4.9 aus sieben — eine mehr als bis zum älteren Ziel 7.6.4. Der Pfad wächst nicht linear mit der Zeit, aber er wächst.

Downgrade ist keine Rückfallebene

Der Reflex — „wenn es schiefgeht, spiele ich eben die alte Version zurück“ — trägt bei keinem der drei Produkte.

• FortiOS. Das Administrationshandbuch beginnt mit „Downgrading the firmware is not recommended“ und liefert dann den Satz, der die Sache entscheidet: „After downgrading, you may be unable to restore the backup configuration.“ Die alte Firmware bekommst du womöglich zurück. Ob die alte Konfiguration wieder hineingeht, ist eine andere Frage.
• GitLab. Ein Rollback verlangt „at least a database backup created under the exact same version and edition you are rolling back to“, und der Restore „overwrites all newer GitLab database content with the older state“. Im Klartext: Jeder Merge Request, jeder Kommentar, jeder Pipeline-Lauf seit dem Upgrade ist weg.
• Proxmox VE. Einen dokumentierten Rückweg gibt es nicht. Das Wiki hält lediglich fest, dass die Migration eines Gastes von einer neueren auf eine ältere Proxmox-VE-Version „may work, but is generally not supported“.

Die Rückfallebene ist also nicht die alte Version, sondern der Zustand vor dem ersten Sprung: Konfigurationssicherung, Datenbanksicherung, Snapshot. Bei einem sechsstufigen Pfad brauchst du diesen Zustand vor jeder Stufe — sonst wirft dich ein Fehler in Stufe fünf an den Anfang zurück statt auf Stufe vier.

Den Pfad ohne Herstellerkonto rekonstruieren

Zum Planen braucht keines der drei Produkte ein Kundenkonto. Nur für das Herunterladen der Fortinet-Images gilt etwas anderes.

• FortiOS. Das Upgrade Path Tool ist frei erreichbar: Modell, Ist-Version, Zielversion — heraus kommen die Zwischenstände samt Build-Nummern und ein Export als CSV, TSV oder JSON. Den Ist-Stand liefert get system status. Für die Firmware selbst verlangt Fortinets Checkliste dagegen „an active Firmware & General Updates (FMWR) license to access firmware downloads“ — planen geht also ohne Vertrag, installieren nicht.
• GitLab. Die Pflichtstopps stehen vollständig in der öffentlichen Dokumentation, zusätzlich pflegt das Support-Team einen Pfad-Rechner. Den Ist-Stand liefert sudo gitlab-rake gitlab:env:info. Die jeweils letzte Patch-Version eines Zweigs findest du im öffentlichen Paket-Repository — und genau die ist gemeint: „upgrade GitLab to the latest available patch release of the major.minor release rather than the first patch release.“
• Proxmox VE. pveversion zeigt den Ist-Stand, pve8to9 --full prüft die Voraussetzungen, und die Wiki-Seiten zu 7 auf 8 und 8 auf 9 sind der Pfad. Alles frei zugänglich, kein Abonnement nötig.

Die Regel dahinter ist bei allen dreien dieselbe und kommt ohne Werkzeug aus: Bevor du einen Zweig verlässt, zieh ihn auf seine letzte Patch-Version hoch. Das ist der Stand, gegen den der Hersteller den Übergang getestet hat.

Was zwischen den Sprüngen passieren muss

Ein Pfad mit sechs Stationen ist nicht ein Wartungsfenster mit sechs Schritten. Zwischen den Stationen muss etwas fertig werden. Fortinet: „Wait for services to stabilize between hops; do not skip ahead.“ GitLab: Die Hintergrundmigrationen müssen durchlaufen, ablesbar an sudo gitlab-rake gitlab:background_migrations:list (ab 18.9, davor :status) — die dokumentierte Regel lautet „All migrations must finish running before each upgrade.“ Proxmox: nach jedem Schritt der Neustart in den neuen Kernel, im Cluster Knoten für Knoten. Deshalb gehört ein Upgrade-Pfad in ein Quartal und nicht in eine Nacht.

Warum sich das andere Ende der Strecke bewegt

Ein Pfad hängt an zwei Zahlen: wo du stehst und wo du hinwillst. Die erste ändert sich nur, wenn du etwas tust. Die zweite ändert sich von allein — oft schneller, als die Planung eines mehrstufigen Upgrades dauert. Drei Werte aus unserem Bestand, Stand 19.08.2026: Bei FortiOS ist inzwischen 8.0 erfasst (Herstellerdatum 08.07.2026), während der 7.2-Zweig am 30.09.2026 aus dem Support fällt. Bei GitLab ist 19.2.4 vom 14.08.2026 der jüngste erfasste Stand, und der 19.0-Zweig läuft am 20.08.2026 aus. Bei Proxmox VE steht 9.2 seit dem 21.05.2026, der 8er-Zweig endet am 31.08.2026. Wer im Frühjahr ein Ziel festgelegt hat, plant im Spätsommer auf ein Ziel, das nicht mehr das aktuelle ist.

Genau da setzt patchletter an — und nur da. Für die Produkte, die du anhakst, kommt eine Mail, sobald eine neue Version erscheint; die Support-Zyklen stehen auf der jeweiligen Produktseite: FortiOS, GitLab und Proxmox VE, den größeren Überblick gibt die End-of-Life-Übersicht. Was patchletter ausdrücklich nicht tut: Zwischenstände ausrechnen. Welche Versionen zwischen deinem Stand und deinem Ziel liegen, beantworten Fortinets Upgrade Path Tool, GitLabs Pflichtstopp-Liste und das Proxmox-Wiki — nicht wir. Wir sagen dir nur, wenn am Zielende eine neue Version steht.

Die ehrliche Einschränkung

Die drei Pfade oben sind Momentaufnahmen vom 19.08.2026, und die FortiOS-Ketten sind modellabhängig — abgefragt wurde eine FortiGate-60F. Frag das Werkzeug mit deinem Modell und deiner Version, nicht mit unserer. Fortinet zeigt außerdem nur den kürzesten getesteten Weg, bewusst nicht jeden möglichen. Bei GitLab gilt nicht jeder Pflichtstopp für jede Instanz: 17.1.8 etwa nur bei großen ci_pipeline_messages-Tabellen. Und ein Pfad, der auf dem Papier stimmt, ersetzt weder das Lesen der Release Notes je Station noch einen Test außerhalb der Produktion.

Herstellerangaben abgerufen am 19.08.2026: Fortinet Upgrade Path Tool und Firmware Upgrade Guide, FortiOS-Administrationshandbuch (Downgrading individual device firmware), GitLab-Dokumentation zu Upgrade-Pfaden, Pflichtstopps, Rollback und Hintergrundmigrationen, Proxmox-VE-Wiki zu den Upgrades 7 auf 8 und 8 auf 9, Debian-13-Release-Notes. Versionen, Herstellerdaten und Support-Zyklen von FortiOS, GitLab und Proxmox VE aus dem eigenen Bestand, Stand 19.08.2026; diese Zahlen bleiben als Momentaufnahme stehen — die laufend gerechneten Werte stehen auf den Produktseiten.