Laravel-Wartung & Upgrades: So bleibt deine Anwendung sicher und aktuell

Die unangenehme Wahrheit über Laravel-Anwendungen: Sie funktionieren auch dann noch tadellos, wenn sie längst keine Sicherheitsupdates mehr bekommen. Nichts geht kaputt, nichts blinkt rot, niemand beschwert sich. Genau deshalb landen bei uns regelmäßig Projekte auf Laravel 8 oder 9 – vier, fünf Jahre alt, im täglichen Einsatz, ohne einen einzigen Patch seit dem Go-live.

Kurz gesagt: Laravel veröffentlicht jedes Jahr ein Major-Release. Für jede Version gibt es 18 Monate lang Bugfixes und zwei Jahre lang Sicherheitsupdates. Danach bist du auf dich gestellt. Wer regelmäßig in kleinen Schritten aktualisiert, zahlt dafür überschaubare Beträge im laufenden Betrieb. Wer wartet, zahlt irgendwann ein Upgrade-Projekt.

Laravels Release-Zyklus – was „unterstützt" wirklich bedeutet

Laravel hat einen erfreulich planbaren Rhythmus: ein Major-Release pro Jahr, meist im ersten Quartal. Die offizielle Support-Regel ist für alle Versionen gleich – 18 Monate Bugfixes, 24 Monate Sicherheitsupdates ab Erscheinen.

Zwei Dinge springen daraus ins Auge, wenn du das im Sommer 2026 liest:

Laravel 11 ist seit März 2026 komplett aus dem Support. Wenn morgen eine Sicherheitslücke im Framework gefunden wird, bekommst du dafür keinen offiziellen Patch mehr. Alles darunter – Laravel 10, 9, 8 – erst recht nicht.

Laravel 12 verliert Mitte August 2026 seine Bugfixes. Sicherheitsupdates laufen zwar noch bis Februar 2027, aber ab dann gilt: Fehler im Framework werden für diese Version nicht mehr behoben.

Dazu kommt die zweite Uhr, die viele übersehen: PHP selbst. Jede PHP-Version bekommt zwei Jahre aktive Unterstützung und danach zwei Jahre nur noch kritische Sicherheitsfixes. PHP 8.1 ist Ende 2025 endgültig ausgelaufen, PHP 8.2 folgt zum 31. Dezember 2026. Wenn dein Laravel zu alt für ein modernes PHP ist, kann dein Hoster dich irgendwann nicht mehr auf einer unterstützten PHP-Version betreiben – und dann wird das Upgrade nicht mehr freiwillig, sondern dringend.

Was passiert, wenn du Upgrades schleifen lässt

„Läuft doch" ist ein trügerischer Zustand. Was sich im Hintergrund aufbaut, sehen wir bei Projektübernahmen fast immer in derselben Reihenfolge.

1. Ungepatchte Sicherheitslücken. Laravel-Lücken sind selten, aber sie existieren – und sie werden öffentlich dokumentiert, sobald sie behoben sind. Ab dem Moment ist die Schwachstelle für jeden nachlesbar, und alle Installationen unterhalb des Patch-Stands sind ein bekanntes Ziel. Kritischer sind in der Praxis ohnehin die Abhängigkeiten: Ein durchschnittliches Laravel-Projekt bringt 60 bis 100 Pakete mit. Auch die bekommen Sicherheitsupdates, und auch die veralten.

2. Der Hoster zieht dir den Boden weg. Managed-Hoster stellen alte PHP-Versionen irgendwann ab – aus gutem Grund. Wenn deine Anwendung nur auf PHP 8.1 läuft und der Server auf 8.3 wechselt, steht sie still. Das ist der Anruf, der dich mit Sicherheit an einem Freitagnachmittag erreicht.

3. Ökosystem-Stillstand. Neue Versionen von Paketen, die du brauchst – Zahlungsanbieter, PDF-Generatoren, Excel-Export, Monitoring – setzen aktuelle Laravel-Versionen voraus. Irgendwann kannst du ein Paket nicht mehr aktualisieren, ohne das Framework zu aktualisieren. Ab da bist du blockiert, und zwar bei genau der Anpassung, die du dringend brauchst.

4. Aus vier kleinen Schritten wird ein Big Bang. Das ist der teuerste Punkt. Ein Upgrade von Laravel 12 auf 13 ist für eine gepflegte Anwendung meist eine Sache von wenigen Stunden bis anderthalb Tagen. Ein Sprung von Laravel 8 auf 13 überspringt fünf Major-Versionen, jede mit eigenen Breaking Changes, dazu zwei PHP-Sprünge. Das ist kein Update mehr, das ist ein Projekt mit Test-, Abnahme- und Risikophase – und es kostet leicht das Zehnfache der Summe aller einzelnen Schritte.

Diese Rechnung ist der eigentliche Grund, warum wir so hartnäckig für laufende Wartung argumentieren – die allgemeine Fassung dieses Arguments steht in Software-Wartung: warum sie so wichtig ist.

Was gute Laravel-Wartung umfasst

„Wartung" ist ein schwammiges Wort, das in Angeboten alles Mögliche bedeuten kann. Bei uns steckt konkret das drin:

• Dependency-Updates. Regelmäßig, nicht einmal im Jahr. Patch- und Minor-Updates der Pakete werden eingespielt und mit der Testsuite abgesichert. Sicherheitsrelevante Updates ziehen wir vor.
• Framework-Updates. Innerhalb einer Major-Version sind Laravel-Updates unkritisch – die kommen einfach mit. Major-Upgrades planen wir gemeinsam und sagen dir rechtzeitig Bescheid, wenn eins ansteht.
• Monitoring. Fehler in Produktion sollten nicht von deinen Nutzern gemeldet werden. Wir schauen auf Fehlerraten, Antwortzeiten, fehlgeschlagene Hintergrundjobs und Queue-Stau – bevor jemand anruft.
• Backups, die nachweislich funktionieren. Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung, kein Backup. Wir testen die Wiederherstellung.
• Sicherheits-Patches mit Vorrang. Wenn eine relevante Lücke bekannt wird, warten wir nicht auf den nächsten Wartungstermin.
• Kleine Weiterentwicklung inklusive. Ein zusätzliches Feld, ein angepasster Text, ein neuer Export – die Dinge, für die sich ein Ticket nicht lohnt. Genau daran hängt, ob eine Anwendung gepflegt wirkt oder nach zwei Jahren an der Realität vorbeiläuft.

Nicht enthalten sind größere Umbauten und neue Module. Die rechnen wir transparent nach Aufwand ab – so weiß jeder, woran er ist.

Der Upgrade-Pfad in der Praxis

Laravel-Upgrades macht man nicht in einem Sprung. Der Weg von einer alten Version zur aktuellen führt Version für Version – 10 → 11 → 12 → 13 – und das aus einem guten Grund: Jeder Schritt hat einen eigenen, offiziell dokumentierten Upgrade-Guide mit einer Liste der Breaking Changes. Springst du direkt, kombinierst du die Fehlerquellen aller Zwischenschritte und weißt am Ende nicht, welche Änderung dir das Problem eingebrockt hat.

So gehen wir vor:

1. Bestandsaufnahme. Welche Laravel- und PHP-Version läuft, welche Pakete sind installiert, wie viele davon sind selbst veraltet oder gar nicht mehr gepflegt? Gibt es Tests? Wie viel Geschäftslogik hängt an Stellen, die sich zwischen den Versionen geändert haben?
2. Sicherheitsnetz aufspannen. Wenn keine Tests existieren – und das ist bei alten Projekten der Normalfall –, schreiben wir zuerst Tests für die kritischen Abläufe: Login, Bestellung, Rechnungslauf, was auch immer bei euch weh tut, wenn es ausfällt. Das ist Aufwand, aber es ist der Unterschied zwischen „Upgrade abgeschlossen" und „Upgrade abgeschlossen, und wir wissen, dass es funktioniert".
3. PHP zuerst, wo es geht. Häufig lässt sich die PHP-Version anheben, bevor Laravel dran ist. Das entzerrt die Fehlersuche.
4. Version für Version. Jeder Schritt einzeln, jeweils mit Testlauf und eigenem Commit. Läuft etwas schief, ist sofort klar, welcher Schritt schuld war.
5. Abhängigkeiten mitziehen. Pakete, die nicht mehr gepflegt werden, werden ersetzt – oft ist das der arbeitsintensivste Teil, nicht das Framework selbst.
6. Staging, Abnahme, Go-live. Mit Rückfallplan und dem Wissen, dass die Datenmigrationen sauber durchgelaufen sind.

Die gute Nachricht: Laravel hat sich in den letzten Jahren als bemerkenswert upgrade-freundlich erwiesen. Die Breaking Changes zwischen Major-Versionen sind meist überschaubar und gut dokumentiert. Das eigentliche Risiko sitzt fast nie im Framework, sondern in eurem eigenen Code – dort, wo jemand vor Jahren an den Konventionen vorbei gearbeitet hat.

Was Wartung und Upgrades kosten

Klare Zahlen statt Andeutungen:

• Laufende Wartung: ab 119 €/Monat. Darin stecken Updates, Monitoring, Sicherheits-Patches und kleine Anpassungen. Monatlich kündbar, mit einem festen Ansprechpartner – nicht mit einer Ticket-Hotline.
• Alles darüber hinaus: 79 €/h. Größere Umbauten, neue Module, aufwändige Upgrade-Projekte. Transparent abgerechnet, monatlich nachvollziehbar.
• Ein einzelner Major-Sprung in einer gepflegten Anwendung mit Tests: erfahrungsgemäß ein halber bis zwei Tage.
• Ein Aufholprojekt über drei bis fünf Major-Versionen ohne vorhandene Tests: je nach Größe eher 30 bis 120 Stunden, ein erheblicher Teil davon für das Sicherheitsnetz.

Genau das ist der Rechenweg hinter unserem Wartungsargument: Zwölf Monate Wartung kosten dich weniger als ein einziger Nachmittag Krisenmanagement plus das Aufholprojekt, das danach ohnehin kommt. Wie sich diese Beträge in eine Gesamtkalkulation einordnen, haben wir in Was kostet Laravel-Entwicklung? im Detail vorgerechnet.

Upgrade oder Neubau – wann lohnt sich was?

Nicht jedes alte Projekt ist es wert, gerettet zu werden. Ehrliche Entscheidungshilfe:

Für ein Upgrade spricht, wenn die fachliche Logik stimmt und das Datenmodell tragfähig ist, wenn der Code den Laravel-Konventionen halbwegs folgt, wenn die Anwendung im Alltag gut funktioniert und nur technisch hinterherhinkt. Dann ist ein Upgrade in aller Regel deutlich günstiger als ein Neubau – oft ein Fünftel bis ein Drittel der Kosten.

Für einen Neubau spricht, wenn Geschäftslogik quer über Controller und Views verstreut ist, wenn zentrale Pakete seit Jahren tot sind und keine Nachfolger haben, wenn niemand mehr sagen kann, was ein Codeabschnitt tun soll, oder wenn die Anwendung fachlich ohnehin an ihre Grenzen gestoßen ist. Dann investierst du in ein Upgrade Geld, um ein Problem zu konservieren.

Der schwierigste Fall liegt dazwischen: fachlich gut, technisch grenzwertig. Dafür machen wir eine kurze Bestandsaufnahme mit klarer Empfehlung und Zahlen für beide Wege – bevor du dich festlegst. Wenn dein bisheriger Dienstleister für solche Fragen nicht mehr erreichbar ist, ist unser Beitrag zum Wechsel der Laravel-Agentur der passende Einstieg; geht es um die Ablösung eines wirklich alten Systems, findest du das Vorgehen in Legacy-Software ablösen.

Fazit: Wartung ist kein Kostenpunkt, sondern eine Versicherung

Laravel macht es dir leicht, aktuell zu bleiben – jährliche Releases, klare Support-Fenster, gute Upgrade-Guides. Die Voraussetzung ist nur, dass jemand hinschaut. 18 Monate Bugfixes und zwei Jahre Sicherheitsupdates sind ein ehrliches Angebot, aber eben auch eine Frist. Wer sie im Blick behält, zahlt kleine Beträge im laufenden Betrieb. Wer sie verstreichen lässt, zahlt später ein Projekt – und dazwischen liegt vielleicht ein Vorfall, den niemand gebrauchen kann.

Du weißt gar nicht, auf welcher Laravel-Version deine Anwendung läuft? Das ist keine peinliche Frage, das ist der Normalfall. Wir schauen als Laravel-Agentur im kostenlosen Erstgespräch gemeinsam drauf: Version, Paketstand, Sicherheitslage, PHP-Version – und du bekommst danach eine ehrliche Einschätzung, ob das dringend ist oder entspannt bis nächstes Jahr Zeit hat. Ohne Panikmache, ohne Verkaufsdruck. Falls alles in Ordnung ist, sagen wir dir das genauso deutlich.

Häufige Fragen