Laravel-Versionen und der richtige Zeitpunkt fürs Upgrade

Die Frage kommt meistens so: „Wir sind noch auf einer älteren Laravel-Version. Ist das schlimm?“ Die ehrliche Antwort ist ein Es-kommt-darauf-an. Nur eben nicht auf die Zahl.

Das Support-Fenster ist der Maßstab

Laravel erscheint in Hauptversionen nach einem festen Rhythmus. Für jede ist dokumentiert, wie lange sie Fehlerbehebungen bekommt und wie lange darüber hinaus noch Sicherheitskorrekturen. Solange eine Version im Sicherheitsfenster liegt, ist eine ältere Nummer kein Problem. Dann ist sie eine Entscheidung.

Interessant wird es am Ende dieses Fensters. Ab da werden gemeldete Schwachstellen für Ihre Version nicht mehr geschlossen. Öffentlich bleiben sie trotzdem, die Meldung verschwindet ja nicht. Ab hier wird aus einer planbaren Aufgabe eine dringende.

Dasselbe gilt eine Ebene tiefer für PHP. In der Praxis ist die PHP-Version sogar häufiger der Auslöser, weil Hoster alte Versionen abschalten und Sie dann einen Termin bekommen, den Sie nicht gesetzt haben.

Wo die Versionen gerade stehen

Laravel erscheint einmal im Jahr in einer neuen Hauptversion, üblicherweise im ersten Quartal. Jede bekommt achtzehn Monate lang Fehlerbehebungen und zwei Jahre lang Sicherheitskorrekturen. Eine LTS-Version im früheren Sinn führen die Release Notes nicht mehr; für alle Hauptversionen gilt dasselbe Fenster.

Daraus lässt sich die eigene Lage in einem Satz ablesen. Wer auf Laravel 11 oder älter läuft, bekommt gar keine Sicherheitskorrekturen mehr; bei Version 11 ist das Fenster im März 2026 zugegangen. Laravel 12 wird seit August 2026 nur noch abgesichert und erhält keine Fehlerbehebungen mehr. Aktuell ist Laravel 13.

Die Tabelle steht hier zum Nachschlagen, sie ist aber kein Ersatz für den Blick in die offiziellen Release Notes. Stand dieser Angaben: 28. August 2026.

Die drei Signale, auf die es ankommt

Erstens: Läuft das Sicherheitsfenster aus? Wenn ja, gehört das Upgrade in die Planung des laufenden Jahres, nicht in eine Ideensammlung.

Zweitens: Lassen sich Abhängigkeiten noch aktualisieren? Ein Paket, das eine neuere PHP-Version verlangt, blockiert alle anderen. Wenn composer update beginnt, an mehreren Stellen gleichzeitig zu widersprechen, ist der Rückstand schon groß.

Drittens: Traut sich noch jemand an das Deployment? Das ist kein technisches Signal, aber ein verlässliches. Wenn im Team niemand mehr freiwillig etwas an der Anwendung ändert, ist die Substanz das Problem, nicht die Versionsnummer.

Warum kleine Schritte günstiger sind

Ein Upgrade über eine Hauptversion ist meistens überschaubar. Ein paar geänderte Methodennamen, ein anderes Standardverhalten, eine angepasste Konfiguration. Über vier Hauptversionen hinweg wird daraus ein Projekt, weil sich die Änderungen überlagern und irgendwann niemand mehr weiß, welche Anpassung welchen Fehler ausgelöst hat.

Deshalb ist die günstigste Strategie, gar nicht erst in Rückstand zu geraten. Ein fester Termin im Jahr, an dem die Anwendung auf den aktuellen Stand gehoben wird, kostet verlässlich wenig. Der Nachholtermin nach fünf Jahren kostet unverlässlich viel.

Wie so ein Sprung abläuft

Wir arbeiten in einer Kopie und heben sie dort Etappe für Etappe. Nach jeder Etappe läuft die Testsuite. Wo es keine gibt, bauen wir vorher eine für die Stellen, an denen ein Fehler wirklich wehtut. Erst wenn alle Etappen durch sind, geht der fertige Stand in einem kurzen Fenster live. Der Rückweg ist bis dahin geprobt, für den Fall dass wir etwas übersehen haben.

Wie wir dabei im Detail vorgehen, steht unter Migration und Upgrade. Wenn zuerst geklärt werden soll, in welchem Zustand die Anwendung überhaupt ist, ist ein Code-Audit der richtige Anfang.