Laravel-Upgrade
Laravel gibt 18 Monate Fehlerkorrekturen und zwei Jahre Sicherheitsfixes. Laravel 11 ist damit seit dem 12. März 2026 ohne jede Wartung, Laravel 12 bekommt seit dem 13. August 2026 keine Fehlerkorrekturen mehr und bis Februar 2027 nur noch Sicherheitsfixes. Der Sprung auf 13 ist im Framework klein – das Projekt selbst nennt einen Tag. Was Zeit kostet, sind die Pakete darum herum, die PHP-Untergrenze von 8.3 und die Stellen, an denen Ihr Code auf Verhalten baut statt auf Signaturen.
Einstieg als erster Upgrade-Schritt zum Festpreis, Umsetzung nach Umfang. Auch für Anwendungen ohne Tests und ohne die Leute, die sie gebaut haben.
Remote aus Deutschland. Direkt mit mir, ohne Agentur dazwischen.
Die Ausgangslage
Laravel erscheint jährlich im ersten Quartal und hält die Hauptversionen bewusst schmal. Für 13 schreibt das Projekt selbst, die meisten Anwendungen ließen sich ohne größere Änderungen am eigenen Code anheben. Das ist keine Werbung, sondern nachprüfbar: Die Migrationsanleitung je Hauptversion ist kurz, und für den mechanischen Teil gibt es Werkzeuge. Wer nur das Framework anhebt, ist tatsächlich schnell fertig.
Der Satz, an dem Vorhaben scheitern, steht im Kleingedruckten derselben Seite: Bei allen Zusatzbibliotheken bekommt nur die jeweils neueste Hauptversion Fehlerkorrekturen. Eine Anwendung mit Horizon, Passport, Cashier, Scout, Telescope und einem Dutzend Paketen aus der Gemeinschaft hat also so viele Zeitpläne wie Abhängigkeiten – und wenn eines davon seit drei Jahren keinen Commit gesehen hat, hält es den ganzen Sprung fest. Das ist der Punkt, an dem die Kostenschätzungen auseinandergehen.
Darunter liegt die Sprachversion: Laravel 13 verlangt mindestens PHP 8.3, Laravel 12 lief noch ab 8.2. Wer auf PHP 8.0 oder darunter steht, hat zwei Vorhaben vor sich, nicht eines. Und es gibt eine Eigenheit, die Laravel von Symfony unterscheidet: Weil viel über Fassaden, Eloquent und Container-Bindungen läuft, zeigt sich eine Änderung oft nicht beim Start, sondern im Verhalten – in einer Abfrage, die anders sortiert, oder einer Ausnahme, die jetzt woanders landet. Das findet kein Compiler, sondern nur ein Test.
Kommt Ihnen etwas davon bekannt vor?Was ich mache
Zielzweig ist in der Regel 13, weil er bis 2028 Sicherheitsfixes bekommt. Wer heute auf 10 steht, geht über 11 und 12 dorthin – nicht weil die Zwischenschritte Selbstzweck sind, sondern weil jede Hauptversion ihre eigene Migrationsanleitung hat und ein Fehler sonst keiner Stufe mehr zuzuordnen ist. Ergebnis ist eine Kette mit einer PHP-Voraussetzung je Stufe.
Je Abhängigkeit dieselben drei Fragen: Gibt es sie für den Zielzweig, wird sie noch gepflegt, und was tritt an ihre Stelle, wenn nicht. Erstanbieter-Pakete wie Horizon, Passport oder Cashier haben eigene Hauptversionen, die zur Laravel-Version passen müssen. Aufgegebene Pakete bekommen eine gepflegte Alternative, eine schmale eigene Umsetzung dessen, was tatsächlich benutzt wird, oder eine Grenze, hinter der sie eingekapselt weiterlaufen.
Bei Laravel ist das keine Vorsichtsmaßnahme, sondern der Kern: Weil ein Sprung selten den Start bricht, sondern das Verhalten verschiebt, braucht es vorher Tests um die Wege, an denen Geld hängt. Wo keine existieren, entstehen Characterization Tests – sie halten fest, was die Anwendung heute tut, unabhängig davon, ob es richtig ist.
Umbenannte Methoden, geänderte Signaturen, verschobene Konfigurationsschlüssel: Dieser Teil wird automatisiert, mit Rector-Regelsätzen und wo es passt mit Laravel Shift. Was danach übrig bleibt, ist gemessen statt geschätzt – und genau darüber gehen Angebote sonst auseinander.
Jede Stufe ist ein eigener Schritt mit eigenem Rückweg, und jede geht einzeln in Produktion. Zwei Hauptversionen in einem Zug zu nehmen spart auf dem Papier Zeit und kostet sie beim ersten Fehler zurück. Zur Umgebung gehört dazu, was oft vergessen wird: die Build-Kette. Wer noch Laravel Mix fährt, wechselt dabei auf Vite.
Zum Abschluss die Dinge, die den Abstand künftig klein halten: Tests und statische Analyse in der Pipeline, automatische Abhängigkeitsprüfung, und eine Notiz im Kalender, wann der jetzt gewählte Zweig aus der Wartung fällt. Bei einem Jahrestakt ist das kein Projekt mehr, sondern ein Termin.
Läuft Ihr Laravel auf einem Zweig ohne Wartung?
Schicken Sie mir die Eckdaten. Sie bekommen die Kette der Zwischenschritte und den Aufwand, bevor Sie etwas beauftragen.
Ablauf
Vier Schritte, und nach dem ersten kennen Sie den Weg samt Zwischenstationen. Kein Schritt setzt voraus, dass Sie den nächsten beauftragen.
Laravel-Version, PHP-Version, ungefähre Größe, Testabdeckung, die composer.json. Ein Lesezugriff auf das Repository genügt für den Befund.
Zielzweig, Zwischenschritte, Pakete nach Ersetzbarkeit, die Stellen mit Verhaltensrisiko. Damit können Sie entscheiden, auch gegen mich.
Testnetz um die Wege, an denen Geld hängt, dann der mechanische Teil automatisiert. Beides passiert, bevor die erste Versionsnummer steigt.
Ein Sprung, ein Rollout, ein Rückweg. Zum Schluss Prüfungen in der Pipeline und die Übergabe.
Einstieg
Startpreis. Die weiteren Zwischenschritte werden nach Umfang angeboten, verbindlich bevor sie beginnen.
Kein Gutachten, sondern ein Anfang: Der erste Sprung Ihrer Upgrade-Kette wird in einem eigenen Zweig ausgeführt. Was die Werkzeuge dabei nicht erledigen, steht danach als gemessene Liste da, nicht als Schätzung.
Was Sie bekommen
Was Sie nicht bekommen
Das Ergebnis
Fehlerkorrekturen und Sicherheitsfixes kommen wieder, und die Frage im nächsten Audit ist beantwortet.
Ein neues Paket lässt sich installieren, ohne dass drei andere blockieren. Das war vorher der eigentliche Stillstand.
Laravel erscheint jährlich. Mit Tests und Prüfungen in der Pipeline ist der nächste Sprung eine Woche im Kalender statt ein Vorhaben mit Budgetantrag.
Die Tests, die für das Upgrade entstanden sind, gehören danach Ihnen und sichern jede weitere Änderung ab.
Eingesetzte Technologien
Nachweis
Die meisten Anbieter kennen das Ziel. Bei einem alten System entscheidet aber, ob jemand auch die Ausgangslage kennt: warum eine Stelle so geschrieben ist, wie sie geschrieben ist, und was ihre Ablösung anrichtet. Zend Technologies gibt es unter dem Namen nicht mehr, die Prüfungen von damals also auch nicht. Für die Datenbankseite kommt eine Oracle-Zertifizierung auf MySQL 5 dazu, denn dort liegen die stilleren Fallen: Zeichensätze, Sortierregeln und ein Strict Mode, der bisher Geduldetes ablehnt.
Aus der Praxis
Ein anstehendes PHP-8-Update war der Auslöser, Laravel wurde als Framework-Basis modernisiert. Dazu eine neue Sucharchitektur und der Umzug nach Kubernetes – bei laufendem Redaktionsbetrieb, ohne einen Tag Ausfall.
Case Study lesenEbenfalls aus echten Projekten
Warum die Werkzeuge aus einem Symfony-Upgrade hier nicht greifen, und die vier Stellen, die wirklich Zeit kosten: Eloquent, das Paket-Ökosystem, die Oberflächenkette und der Projektrahmen, der über Jahre auseinanderläuft.
Artikel lesen
Mit wem Sie es zu tun haben
Ich bin Tim Rutte. Über 20 Jahre Softwareentwicklung, und Laravel gehört zu den Frameworks, aus denen ich Bestand übernommen und modernisiert habe. Sie sprechen mit der Person, die Ihren Code anfasst, vom ersten Gespräch bis zur Übergabe.
Häufige Fragen
Laravel gibt 18 Monate Fehlerkorrekturen und zwei Jahre Sicherheitsfixes. Stand August 2026 heißt das: Laravel 13 (seit März 2026) ist der aktuelle Zweig mit Sicherheitsfixes bis März 2028. Laravel 12 bekommt seit dem 13. August 2026 keine Fehlerkorrekturen mehr, Sicherheitsfixes noch bis Februar 2027. Laravel 11 ist seit dem 12. März 2026 ganz ohne Wartung, Laravel 10 seit Februar 2025. Alles unter 12 ist damit ein Sicherheitsthema, nicht nur ein Komfortthema.
Weil der Satz stimmt und trotzdem in die Irre führt. Er gilt für das Framework, und das ist der berechenbare Teil. Ihre Rechnung wird von zwei anderen Dingen geschrieben: von den Paketen, bei denen jeweils nur die neueste Hauptversion Fehlerkorrekturen bekommt, und von der PHP-Untergrenze. Wenn beides passt, ist ein Upgrade wirklich klein – dann sagt Ihnen der erste Schritt genau das, und Sie haben 950 Euro für eine belastbare Antwort ausgegeben statt drei Wochen für eine Überraschung.
Der erste Upgrade-Schritt kostet ab 950 Euro netto und sagt Ihnen, was die Umsetzung kostet. Die Spanne danach hängt nicht an der Codegröße, sondern an zwei anderen Zahlen: wie viele Pakete aufgegeben sind, und ob es Tests gibt. Die Umsetzung wird danach nach Umfang angeboten, je nach Projektbedarf und Ihrem bevorzugten Modell zum Festpreis oder nach Aufwand, verbindlich bevor sie beginnt.
Wo es passt, ja. Shift erledigt den mechanischen Teil eines Hauptversionssprungs zuverlässig und günstig, und es wäre unredlich, dafür Tagessätze zu nehmen. Was Shift nicht kann, ist entscheiden: ob ein aufgegebenes Paket ersetzt oder eingekapselt wird, ob zuerst PHP oder zuerst Laravel steigt, und welche Wege vor dem Sprung ein Testnetz brauchen. Genau dieser Teil ist die Arbeit.
Technisch oft ja, praktisch selten sinnvoll. Jede Hauptversion hat ihre eigene Migrationsanleitung, und wer zwei Stufen in einem Zug nimmt, kann einen Fehler danach keiner Stufe mehr zuordnen. Bei Laravel kommt hinzu, dass sich Änderungen häufig im Verhalten zeigen statt beim Start – das ist genau die Fehlerart, die man einzeln einkreisen will.
Das ist der häufigste harte Fall. Drei Antworten kommen infrage: eine gepflegte Alternative mit derselben Aufgabe, eine eigene schmale Umsetzung genau dessen, was Sie tatsächlich benutzen, oder eine Grenze, hinter der das alte Paket eingekapselt weiterläuft, bis es abgelöst ist. Welche trägt, steht im Befund samt Aufwand.
Wenn Sie unter PHP 8.3 stehen, ja – das ist die Untergrenze für Laravel 13. Beides gleichzeitig zu wechseln ist der zuverlässigste Weg, einen Fehler nicht mehr zuordnen zu können. Welcher Schritt zuerst kommt, hängt am Ausgangsstand und steht im Befund; das PHP-Upgrade hat eine eigene Seite und einen eigenen Zuschnitt.
Nein. Testnetz und automatisierte Läufe passieren neben dem laufenden Betrieb, in einem eigenen Zweig. Jeder Versionssprung danach ist ein eigener Rollout mit eigenem Rückweg, wie jede andere Änderung auch.
Ja, und es ist der Regelfall. Es verschiebt nur die Reihenfolge: Erst entsteht ein Netz um die Wege, an denen Geld hängt, dann wird angehoben. Bei Laravel ist das keine Vorsicht, sondern notwendig, weil ein Sprung eher das Verhalten verschiebt als den Start zu brechen. Die Tests gehören danach Ihnen.
Weitere Leistungen
Gewachsene Systeme schrittweise modernisieren: Strangler-Fig statt Rewrite, laufender Betrieb unangetastet, jeder Schritt umkehrbar.
Mehr erfahrenVon PHP 5.6, 7 oder frühem 8 auf eine unterstützte Version, im laufenden Betrieb: Kompatibilitätsanalyse, Testnetz, automatisierte Umschreibung, schrittweiser Rollout.
Mehr erfahrenVon einer alten Symfony-Fassung auf einen gewarteten Zweig: Deprecations abbauen, Bundles ersetzen, Version für Version, im laufenden Betrieb.
Mehr erfahren