Laravel-Upgrade planen: So bleiben Anwendungen aktuell
Ein Laravel-Upgrade mit geringem Risiko beginnt mit einer Bestandsaufnahme von PHP-Version, Paketen und Tests. Danach geht es Hauptversion für Hauptversion voran, jede Stufe getestet und einzeln ausgeliefert.
Der Zeitpunkt für die Planung ist günstig gewählt, wenn er vor einem Stichtag liegt. Für Laravel 12 enden die Fehlerbehebungen am 13.08.2026, Sicherheitsupdates gibt es noch bis 24.02.2027. Laravel 11 bekommt seit dem 12.03.2026 gar keine Updates mehr. Wer eine Anwendung auf Laravel 10 oder 11 betreibt, arbeitet also bereits ohne Sicherheitsnetz des Frameworks.
Bei einem Upgrade behält die Anwendung ihre Funktionen, ihre Daten und meist auch ihre Struktur. Was sich ändert, sind Framework, Pakete und oft die PHP-Version darunter. Je besser das vorher erfasst ist, desto kleiner wird das Risiko am Tag der Auslieferung.
Fristen
Wie lange eine Laravel-Version Updates bekommt
Laravel veröffentlicht etwa einmal im Jahr, meist im ersten Quartal, eine neue Hauptversion. Jede bekommt laut offizieller Support-Regel 18 Monate Fehlerbehebungen und zwei Jahre Sicherheitsupdates. Daraus folgt: Wer jede zweite Version überspringt, landet regelmäßig in der Zeit ohne Sicherheitsupdates.
Für die Planung zählen am 29.07.2026 diese Stände laut laravel.com: Laravel 10 und 11 bekommen keine Updates mehr, Laravel 12 erhält Fehlerbehebungen bis 13.08.2026 und Sicherheitsupdates bis 24.02.2027, Laravel 13 Sicherheitsupdates bis 17.03.2028. Welche PHP-Versionen jede Laravel-Version unterstützt, steht in der Support-Tabelle der offiziellen Release Notes.
Was in Laravel 13 neu ist und für wen sich der Umstieg sofort rechnet, fasst Laravel 13: Was die neue Version für Ihr Projekt bedeutet zusammen. Die Termine für PHP selbst behandelt PHP 8.2 Supportende.
Bestandsaufnahme
Pakete, Tests und PHP-Version prüfen
Die Bestandsaufnahme beantwortet drei Fragen: Was hängt an der Hauptversion, wie gut ist die Anwendung abgesichert, und auf welcher PHP-Version läuft sie wirklich.
Pakete. Jede Anwendung zieht über Composer Zusatzpakete nach, für Zahlungen, PDF-Erzeugung, Rechte, Admin-Oberflächen. Jedes davon muss die Zielversion unterstützen. Composer zeigt mit einem Befehl, welches Paket ein Upgrade blockiert. Pakete, die als verlassen markiert sind, brauchen einen Ersatz, bevor das Upgrade beginnt.
Tests. Automatische Tests sind das Sicherheitsnetz. Fehlen sie, entsteht vor dem Upgrade eine kleine Grundausstattung: je ein Test für Anmeldung, die wichtigsten Formulare, Zahlungen, Exporte und geplante Aufgaben. Das kostet Zeit, verkürzt aber jede Stufe danach.
PHP-Version. Maßgeblich ist die Version, mit der Webserver, Warteschlangen und Cronjobs laufen. Die Kommandozeile zeigt oft eine andere. Steht in der composer.json unter config und platform eine feste PHP-Version, löst Composer die Pakete für diese Version auf, egal was auf dem Server läuft.
Eigene Erweiterungen. Am meisten Arbeit machen Stellen, an denen die Anwendung Teile des Frameworks ersetzt oder erweitert: eigene Middleware für Anmeldung und Schutz vor gefälschten Anfragen, überschriebene Klassen, eigene Treiber für Cache oder Warteschlangen. Die Upgrade-Leitfäden nennen genau solche Stellen. Eine Liste dieser Erweiterungen spart später die Suche.
Diese Befehle liefern die Grundlage für die Bestandsaufnahme:
# Laravel- und PHP-Version, Treiber, Umgebung
php artisan about
# Direkte Abhängigkeiten mit neueren Versionen
composer outdated --direct
# Welche Pakete verhindern Laravel 13?
composer why-not laravel/framework ^13.0
# Bekannte Sicherheitslücken in den installierten Paketen
composer audit
Vorgehen
Laravel-Upgrade Schritt für Schritt statt großer Sprung
Der offizielle Upgrade-Leitfaden beschreibt jeweils den Schritt von einer Hauptversion zur nächsten. Wer von Laravel 10 auf 13 will, geht deshalb drei Stufen: 10 auf 11, 11 auf 12, 12 auf 13. Jede Stufe wird auf Staging getestet und einzeln ausgeliefert. Tritt ein Fehler auf, ist klar, aus welcher Stufe er kommt.
Ein Detail aus der Support-Tabelle macht die Reihenfolge leichter: PHP 8.3 wird von Laravel 10, 11, 12 und 13 unterstützt. Wer zuerst den Server auf PHP 8.3 hebt und das allein ausliefert, kann danach alle drei Framework-Stufen auf derselben PHP-Version gehen. So ändert sich pro Auslieferung nur eine Sache.
Die Leitfäden schätzen den reinen Umstieg auf 15 Minuten (10 auf 11) und 10 Minuten (12 auf 13). Diese Zahlen gelten für Anwendungen nahe am Standard. Die Arbeit steckt in den Stellen, an denen Ihre Anwendung vom Standard abweicht. Zwei Beispiele aus den offiziellen Leitfäden zeigen, wie leise solche Änderungen sein können:
Laravel 11 und Carbon 3: Laravel 11 erlaubt Carbon 3, die Bibliothek für Datumsrechnung. Wird sie beim Upgrade mit angehoben, liefern die Methoden diffIn... Kommazahlen und können negativ werden. Eine Fristberechnung, die bisher 3 Tage ergab, liefert dann zum Beispiel 2,75 oder minus 3. Es gibt keine Fehlermeldung, nur falsche Zahlen in Rechnungen, Mahnungen oder Berichten.
Laravel 13 und Sitzungen: Die neue Standardkonfiguration speichert Sitzungen als JSON statt als PHP-Objekt. Wer die Konfigurationsdateien an die neue Vorlage angleicht, meldet mit der Auslieferung alle angemeldeten Nutzer ab. Das ist sicherer, gehört aber in ein angekündigtes Wartungsfenster und nicht in den Vormittag.
Zu jeder Stufe gehört ein Rückweg. Vor der Auslieferung wird die Datenbank gesichert, weil Migrationen in einer neuen Version Spalten ändern können, die sich nicht ohne Weiteres zurückdrehen lassen. Der vorherige Stand des Codes bleibt auf dem Server abrufbar, damit ein Zurückschalten Minuten dauert und nicht Stunden. Nach der Auslieferung lesen Sie einige Tage lang die Fehlerprotokolle und die Warteschlange für fehlgeschlagene Aufgaben. Manche Fehler zeigen sich erst beim nächtlichen Export oder beim Monatsabschluss, nicht beim ersten Klick.
Für den Wechsel selbst genügen wenige Befehle. Die eigentliche Arbeit ist die Liste der Änderungen im Leitfaden:
git switch -c upgrade/laravel-13
# Versionen in composer.json anheben (laut Upgrade-Leitfaden)
composer require laravel/framework:^13.0 laravel/tinker:^3.0 --no-update
composer require --dev phpunit/phpunit:^12.0 --no-update
# Nur wenn im Projekt vorhanden, der Leitfaden nennt auch diese:
# composer require --dev pestphp/pest:^4.0 laravel/boost:^2.0 --no-update
composer update
php artisan test
Vorlage
Der Upgrade-Plan auf einer Seite
Bevor die erste Zeile Code geändert wird, passt der Plan auf eine Seite. Diese Vorlage können Sie kopieren und für Ihre Anwendung ausfüllen:
Anwendung: ...
Laravel heute / Ziel: 10 -> 13
PHP heute / Ziel: 8.1 -> 8.3 (später 8.4 oder 8.5)
Umgebungen: Produktion, Staging, Cron-Server, CI, lokal
Blockierende Pakete: (Ausgabe von composer why-not)
Verlassene Pakete: ... Ersatz: ...
Eigene Erweiterungen: ... (z. B. eigene Middleware, überschriebene Klassen)
Tests vorhanden für: Anmeldung [ ] Formulare [ ] Zahlungen [ ]
Exporte [ ] geplante Aufgaben [ ]
Stufe 1: PHP 8.3 Termin: ... Rückweg: ...
Stufe 2: Laravel 11 Termin: ... Rückweg: ...
Stufe 3: Laravel 12 Termin: ... Rückweg: ...
Stufe 4: Laravel 13 Termin: ... Rückweg: ...
Wartungsfenster: nötig / nicht nötig (z. B. Sitzungen, Migrationen)
Beobachtung danach: Fehlerprotokoll, fehlgeschlagene Jobs, Tage: ...
Aufwand
Womit Sie rechnen sollten
Der Aufwand hängt weniger von der Zahl der Versionen ab als von Tests, Paketen und eigenen Erweiterungen. Für eine typische Geschäftsanwendung rechnen wir so, weil der Zeitaufwand vor allem im Staging-Test und in der Prüfung der eigenen Erweiterungen steckt:
Eine Stufe mit guten Tests und gepflegten Paketen: ein halber bis zwei Personentage, einschließlich Staging-Test und Auslieferung.
Mehrere Stufen mit Tests: pro Stufe dasselbe, dazu ein Tag für den PHP-Wechsel.
Ohne Tests oder mit verlassenen Paketen: erst Tests und Ersatzpakete, das kann mehr Zeit kosten als das Upgrade selbst.
Ein kostenpflichtiger Community-Dienst wie Laravel Shift bereitet Upgrades automatisch als Pull Request vor. Das spart Tipparbeit, ersetzt aber weder Tests noch die Prüfung der Stellen, an denen Ihre Anwendung vom Standard abweicht.
Läuft eine Anwendung ohne Framework oder auf einer sehr alten Basis, ist ein Upgrade der falsche Begriff. Dann geht es um eine schrittweise Modernisierung, Modul für Modul neben dem laufenden System.
Danach
Ein fester Takt für die Zukunft
Je mehr Versionen aufzuholen sind, desto mehr Leitfäden stapeln sich in einem Projekt. Ein fester Jahrestakt hält jede Stufe klein:
Wöchentlich bis monatlich: kleinere Versionen und Sicherheitskorrekturen einspielen. Sie enthalten laut Laravel keine Breaking Changes.
Bei jeder Auslieferung: composer audit in der automatischen Prüfung, damit bekannte Lücken auffallen.
Einmal im Jahr: die neue Hauptversion einplanen, sobald die wichtigsten Pakete sie unterstützen, spätestens vor dem Ende der Fehlerbehebungen der laufenden Version.
Alle ein bis zwei Jahre: PHP-Version anheben, im Rhythmus der Termine auf php.net.
Den umgekehrten Weg zeigt PROCITO, eine Tools-Plattform, die wir seit April 2026 neu aufbauen: Laravel, Livewire und Tailwind stehen dort von Anfang an in der jeweils aktuellen Hauptversion. Laut Projektseite ist das Absicht, damit in den nächsten Jahren keine mehrfachen Versionssprünge nachzuholen sind, nur die ohnehin geplanten jährlichen Stufen.
Warum kleine, regelmäßige Updates günstiger sind als seltene große, begründet Patch-Disziplin. Wie die automatische Prüfung bei jeder Änderung aussieht, zeigt GitHub Actions für Laravel und Statamic. Wie wir Laravel-Anwendungen bauen und dauerhaft betreuen, steht auf der Seite unserer Laravel-Agentur.
Aus der Praxis
Häufige Fragen
-
Technisch lässt sich die Zielversion direkt eintragen, die Upgrade-Leitfäden beschreiben aber jeweils nur den Schritt von einer Hauptversion zur nächsten. Wer springt, muss alle Leitfäden dazwischen trotzdem abarbeiten und findet Fehler schwerer, weil viele Änderungen gleichzeitig wirken. Stufen einzeln auszuliefern ist sicherer und selten langsamer.
-
Das hängt von Tests, Paketen und eigenen Erweiterungen ab, nicht von der Größe der Anwendung allein. Mit guter Testabdeckung rechnen wir pro Stufe mit einem halben bis zwei Personentagen. Eine Bestandsaufnahme mit den Composer-Befehlen oben macht die Zahl für Ihr Projekt belastbar.
-
Die Anwendung läuft weiter, bekommt aber nach dem Ende der Sicherheitsupdates keine Korrekturen mehr für neu entdeckte Lücken im Framework. Gleichzeitig verlangen neue Versionen von Paketen neuere Laravel- und PHP-Versionen, sodass auch deren Sicherheitsupdates ausbleiben. Jedes Jahr Abstand macht das spätere Upgrade größer.
Upgrade-Weg klären
Mit den Composer-Befehlen und der Vorlage oben erstellen wir die Bestandsaufnahme Ihrer Laravel-Anwendung, nennen Stufen und Aufwand und führen das Upgrade auf Wunsch durch.
Nachweise
Quellen und Stand
Stand: 29.07.2026. Support-Zeiträume und PHP-Versionen laut laravel.com, Upgrade-Schritte und Zeitschätzungen laut den offiziellen Leitfäden für Laravel 11 und 13, Composer-Befehle laut getcomposer.org. Die Aufwände sind unsere Schätzungen, die Angaben zu PROCITO stammen von der Projektseite.
Artikel teilen