Der Laravel-Upgrade-Guide aus der Praxis

Die meisten Laravel-Anwendungen, die mir auf den Tisch kommen, laufen. Sie verdienen Geld, sie bilden Geschäftsprozesse ab, sie funktionieren seit Jahren. Das Problem ist fast nie die Fachlogik. Das Problem ist der Rahmen drumherum: eine Framework-Version, die keine Security-Fixes mehr bekommt, PHP 7.4 auf dem Server, ein Composer-Lock, das niemand mehr anzufassen wagt. Ein Laravel Upgrade ist deshalb selten ein Rewrite. Es ist eine kontrollierte Kette kleiner, überprüfbarer Schritte. Genau darum geht es in diesem Guide.

Warum ein Laravel Upgrade fast immer günstiger ist als eine Neuentwicklung

Ein System, das seit Jahren stabil läuft, ist kein Müll. Es ist der Beweis, dass die Logik trägt. In diesem Code stecken Hunderte Edge Cases, die irgendwann von echten Nutzern gemeldet und stillschweigend gefixt wurden. Bei einer Neuentwicklung werfen Sie dieses Wissen weg und entdecken dieselben Fehler in den nächsten zwei Jahren noch einmal neu.

Ein Upgrade behält die bewährte Fachlogik und tauscht nur das aus, was tatsächlich veraltet ist: das Framework, die PHP-Version, ein paar Abhängigkeiten. Das ist in der Regel deutlich billiger, schneller und risikoärmer als der Griff zum leeren Editor. Neuentwicklung ist die teuerste und riskanteste Option, die es gibt. Sie ist manchmal richtig, aber fast nie der erste Schritt.

Wie bereite ich ein Laravel Upgrade richtig vor?

Bevor Sie eine einzige Zeile in der composer.json ändern, brauchen Sie ein Sicherheitsnetz. Ohne dieses Netz upgraden Sie blind, und blindes Upgraden endet in einer Produktion, die niemand mehr reproduzieren kann.

• Version festnageln. Prüfen Sie mit php artisan --version und composer show laravel/framework, wo Sie wirklich stehen. Nicht raten.
• PHP-Version klären. Jede Laravel-Version hat eine harte PHP-Untergrenze. Laravel 10 verlangt PHP 8.1, Laravel 11 verlangt PHP 8.2. Oft ist das PHP-Upgrade der eigentliche Aufwand, nicht das Framework.
• Charakterisierungstests schreiben. Wenn keine Tests existieren, schreiben Sie zumindest grobe Integrationstests für die wichtigsten Flows: Login, Bestellung, Rechnung, Export. Diese Tests beweisen nicht, dass der Code gut ist. Sie beweisen, dass sich das Verhalten nach dem Upgrade nicht ändert. Das ist genau das, was Sie brauchen.
• Abhängigkeiten inventarisieren. Ein composer outdated --direct zeigt Ihnen, welche Pakete mitziehen müssen. Verlassene Pakete ohne Support für die neue Version sind Ihre größten Risiken. Finden Sie sie jetzt, nicht mitten im Upgrade.

Legen Sie außerdem einen eigenen Branch an und stellen Sie sicher, dass Sie die Anwendung lokal in einer Umgebung starten können, die der Produktion ähnelt. Ein Upgrade, das Sie nicht lokal testen können, ist kein Upgrade, sondern ein Glücksspiel.

Sollte ich mehrere Laravel-Versionen auf einmal überspringen?

Nein. Gehen Sie Major-Version für Major-Version vor, niemals mehrere auf einmal. Der Sprung von Laravel 8 auf 11 in einem Rutsch mischt die Breaking Changes aus vier Releases zu einem unauflösbaren Knäuel. Wenn dann etwas bricht, wissen Sie nicht, welche Version schuld ist.

Der saubere Weg ist die Treppe: 8 auf 9, dann 9 auf 10, dann 10 auf 11. Nach jeder Stufe läuft die Test-Suite, nach jeder Stufe committen Sie. So bleibt jeder Schritt klein genug, um im Zweifel zurückgerollt zu werden. Der offizielle Upgrade Guide von Laravel ist dabei Ihre Pflichtlektüre. Er listet für jede Version die Breaking Changes und die geschätzte Auswirkung ("High", "Medium", "Low"). Arbeiten Sie ihn Punkt für Punkt ab.

Welche Werkzeuge helfen beim Laravel Upgrade?

Vieles an einem Upgrade ist mechanische Anpassung an neue Signaturen und umbenannte Methoden. Diese Arbeit müssen Sie nicht von Hand machen.

• Laravel Shift ist ein kostenpflichtiger, automatisierter Dienst, der die stumpfen Änderungen zwischen zwei Versionen als Pull Request vorbereitet. Er nimmt Ihnen die repetitive Arbeit ab, ersetzt aber nicht Ihr Urteil bei fachlichen Änderungen.
• Rector ist ein quelloffenes Tool für automatisierte Refactorings. Mit dem Set LaravelSetList und den PHP-Sets bringen Sie sowohl Framework-Aufrufe als auch veraltete PHP-Syntax auf den aktuellen Stand.
• PHPStan oder Larastan zeigen Ihnen nach jedem Schritt statisch, wo Typen nicht mehr passen oder Methoden verschwunden sind. Lassen Sie die Analyse vor und nach jeder Stufe laufen und vergleichen Sie die Fehlerliste.

Automatik ist ein Beschleuniger, kein Ersatz für Verständnis. Jeden generierten Diff sollten Sie lesen, bevor Sie ihn übernehmen.

Worauf muss ich bei Security und Datenbank besonders achten?

Der wichtigste Grund für ein Upgrade ist meist nicht ein schickes neues Feature, sondern Sicherheit. Eine Laravel-Version außerhalb des Support-Fensters bekommt keine Security-Patches mehr. Das gilt genauso für PHP selbst: Eine Anwendung auf PHP 7.4 hängt an einem Interpreter, der seit Ende 2022 keine Sicherheitsupdates mehr erhält.

Prüfen Sie beim Upgrade konkret diese Punkte:

• Passwort-Hashing: Neuere Laravel-Versionen setzen teils auf andere Bcrypt-Kostenfaktoren oder Argon2. Bestehende Hashes bleiben gültig, aber prüfen Sie die config/hashing.php.
• Datenbank-Migrationen: Änderungen an Spaltentypen oder Default-Werten zwischen Versionen können auf großen Tabellen lange Locks auslösen. Testen Sie Migrationen gegen eine Kopie der echten Datenmenge, nicht gegen zehn Testzeilen.
• Serialisierung von Sessions und Queues: Wenn sich Klassen ändern, können in der Queue liegende, serialisierte Jobs nach dem Deploy nicht mehr deserialisiert werden. Leeren Sie kritische Queues vor dem Deploy oder planen Sie eine Übergangsphase ein.

Wie deploye ich das Upgrade ohne böse Überraschung?

Deployen Sie zuerst in eine Staging-Umgebung, die die Produktion so genau wie möglich nachbildet: gleiche PHP-Version, gleiche Datenbank-Engine, wenn möglich eine anonymisierte Kopie der Produktionsdaten. Viele Fehler zeigen sich erst an echten Datenmengen und echten Sonderfällen.

In Produktion selbst gilt: Cache leeren mit php artisan config:clear, route:clear und view:clear, danach die Caches neu aufbauen. Vergessen Sie das nicht, denn ein alter gecachter Config- oder Route-Zustand ist eine klassische Quelle für Fehler, die "nur in Produktion" auftreten. Halten Sie den vorherigen Release deploybereit, damit ein Rollback eine Sache von Minuten ist.

Ein ehrlicher Praxis-Tipp zum Schluss

Der häufigste Fehler ist nicht ein technischer, sondern ein zeitlicher: zu lange warten. Ein Upgrade von Version 10 auf 11 ist überschaubar. Ein Upgrade von Version 5 auf 11 über ein totes PHP hinweg ist ein Projekt. Wer regelmäßig in kleinen Schritten aktualisiert, hat nie den großen, teuren Sprung vor sich. Fangen Sie klein an, mit dem Sicherheitsnetz aus Tests, und gehen Sie eine Stufe nach der anderen.

Wenn ein Upgrade festhängt, das Framework zu alt für die Werkzeuge ist oder niemand mehr weiß, was die Anwendung eigentlich tut, unterstützt LegacyWerk genau bei dieser Art von Rettung und Modernisierung.