Wer Webanwendungen mit PHP entwickelt oder verantwortet, kommt an Laravel kaum vorbei. Das PHP-Framework betreibt heute mehr als 960.000 Websites, hält über 50 Prozent des PHP-Framework-Markts und belegt im Stack Overflow Developer Survey zum fünften Mal in Folge den ersten Platz. Zahlen, die für sich sprechen – und die erklären, warum Laravel nicht nur bei grünen Wiesen-Projekten zum Einsatz kommt, sondern auch tief in gewachsenen Systemen steckt, die schon seit Jahren im Betrieb sind.
Genau dort begegnen wir bei mindtwo immer wieder einem bekannten Muster: Entwicklungsteams und IT-Verantwortliche halten an einer bestimmten Laravel-Version fest, weil sie "stabil läuft" – oder weil sie ursprünglich als LTS-Version positioniert war. Was nach einem vernünftigen Konservativismus klingt, wird mit der Zeit zur strategischen Bremse. Denn das Framework hat sich weiterentwickelt, das LTS-Konzept hat sich grundlegend geändert – und die Kosten des Stillstands werden häufig unterschätzt.
Dieser Artikel zeigt, was sich beim Laravel-Versionsmodell konkret verändert hat, welche Risiken mit dem Festhalten an alten Versionen verbunden sind und wie ein strukturierter Upgrade-Ansatz aussieht, der weder Entwickler noch Entscheider überfordert.
Was LTS bei Laravel bedeutete – und warum das Modell nicht mehr existiert
Die ursprüngliche Idee hinter Long-Term Support
Laravel 5.1, veröffentlicht im Juni 2015, war die erste Version von Laravel, die Long-Term Support erhielt. Neue LTS-Versionen waren im Zwei-Jahres-Rhythmus geplant. Das Konzept dahinter war verständlich: Größere Projekte und Unternehmensanwendungen sollten eine stabile, langfristig gepflegte Basis erhalten, ohne in kurzen Abständen aufwändige Migrationen durchführen zu müssen.
Von Laravel 5 bis Laravel 8 wurden Versionen, die als LTS designiert waren, mit Bugfixes für zwei Jahre und Sicherheitskorrekturen für drei Jahre unterstützt. Andere Releases erhielten Bugfixes für sechs Monate und Sicherheitskorrekturen für ein Jahr.
Das klingt nach einem klaren Vorteil für LTS-Versionen. Doch das Modell hat einen strukturellen Nachteil: Wer auf LTS setzt, kauft sich Zeit – zahlt aber einen Preis in Form entgangener Innovationen, die sich über Monate und Jahre aufstauen.
Das Ende des klassischen LTS-Modells
Was viele Entscheider nicht auf dem Schirm haben: Die letzte LTS-Version war Laravel 6, veröffentlicht am 3. September 2019. Seitdem gibt es dieses spezielle Konzept nicht mehr. Laravel hat sein Versionsmodell grundlegend modernisiert.
Laravel und seine First-Party-Pakete folgen Semantic Versioning. Größere Framework-Releases erscheinen jährlich, etwa im ersten Quartal, während Minor- und Patch-Releases so häufig wie jede Woche veröffentlicht werden können. Minor- und Patch-Releases enthalten keine Breaking Changes. Für alle Laravel-Releases werden Bugfixes für 18 Monate und Sicherheitsfixes für 2 Jahre bereitgestellt.
Das Ergebnis: Es gibt keinen aktiven LTS-Zweig mehr, auf den man warten könnte. Die sicherste langfristige Gewohnheit ist es, Upgrades zur Routine zu machen. Wer heute auf eine "LTS-Version" wartet, wartet auf etwas, das es nicht mehr gibt.
Laravel-LTS-Versionen wie 6 und 9 boten zwar erweiterten Sicherheitssupport, liefen aber nach einem festen Zeitfenster aus. Viele Teams glauben fälschlicherweise, dass LTS "unbegrenzte Abdeckung" bedeutet – das ist nicht der Fall.
Der aktuelle Stand: Laravel 13 und das neue Releasemodell
Laravel 13 – veröffentlicht, stabil, produktionsbereit
Laravel 13 wurde am 17. März 2026 mit dem Fokus auf moderne PHP-Features, sauberere Syntax und eine bessere Developer Experience veröffentlicht. Diese Version erfordert PHP 8.3 als Mindestanforderung. Taylor Otwell kündigte es live auf der Laracon EU 2026 an – mit dem klaren Versprechen: null Breaking Changes, stabiles Laravel AI SDK und eine Reihe sorgfältig gewählter Verbesserungen.
Laravel 13 folgt dem Standard-Supportzyklus mit Bugfixes bis Q3 2027 und Sicherheitsupdates bis Q1 2028.
Was das für bestehende Projekte bedeutet: Das Laravel-13-Release ist ein vergleichsweise geringfügiges Upgrade hinsichtlich des Aufwands – liefert dabei aber substanzielle neue Möglichkeiten. Die meisten Laravel-Anwendungen können auf Laravel 13 migrieren, ohne viel am bestehenden Code zu ändern.
Was Laravel 13 konkret bringt
Die wichtigsten Neuerungen im Überblick:
Native PHP Attributes: Laravel 13 führt native PHP-Attribute-Syntax als optionale Alternative zu Klassen-Property-Deklarationen an mehr als 15 Stellen im Framework ein. Das ist eine nicht-breaking-Änderung – bestehende Property-basierte Konfiguration funktioniert weiterhin.
Laravel AI SDK stabil: Laravel 13 führt das First-Party Laravel AI SDK ein, das eine einheitliche API für Textgenerierung, Tool-Calling-Agents, Embeddings, Audio, Bilder und Vector-Store-Integrationen bereitstellt. Mit dem AI SDK lassen sich providerunabhängige KI-Features entwickeln, während eine konsistente, Laravel-native Developer Experience erhalten bleibt.
Vector Search: Laravel 13 vertieft semantische Suche mit nativem Vector-Query-Support, Embedding-Workflows und zugehörigen APIs. Diese Features machen es einfach, KI-gestützte Sucherlebnisse mit PostgreSQL und pgvector aufzubauen.
Cache::touch(): Laravel 13 fügt eine Cache::touch()-Methode hinzu, die die TTL eines gecachten Elements verlängert, ohne den Wert zu laden oder neu zu speichern. Bisher erforderte die Verlängerung der Cache-Lebensdauer ein get() gefolgt von einem put(), was unnötig Daten übertrug. Cache::touch() eliminiert das.
Passkey-Authentifizierung: Passkeys werden in den Starter Kits und im zugrundeliegenden Laravel Fortify integriert – ein lang gewünschtes Feature.
Verbesserte CSRF-Sicherheit: Laravels Request-Forgery-Schutz-Middleware wurde erweitert und als PreventRequestForgery formalisiert, das Origin-aware Request Verification hinzufügt und dabei die Kompatibilität mit Token-basiertem CSRF-Schutz beibehält.
Das strategische Signal hinter dem Release
Wenn Sie Laravel-Framework oder seine Komponenten in Ihrer Anwendung referenzieren, sollten Sie stets eine Versionseinschränkung wie ^13.0 verwenden, da Major-Releases Breaking Changes enthalten können. Laravel strebt jedoch stets an, dass ein Update auf eine neue Hauptversion in einem Tag oder weniger abgeschlossen werden kann.
Das ist kein Marketingversprechen, sondern eine Design-Entscheidung. Ein Großteil des Fokus beim Release-Zyklus von Laravel 13 lag auf der Minimierung von Breaking Changes. Stattdessen wurden kontinuierliche Quality-of-Life-Verbesserungen geliefert, die bestehende Anwendungen nicht brechen.
Die echten Kosten des Versionsstillstands
Wenn "läuft noch" zur Risikoposition wird
Eine Webanwendung auf einer nicht mehr gepflegten Laravel-Version zu betreiben ist keine Frage des Komforts, sondern des unternehmerischen Risikos. Wer 2026 noch auf Laravel 8, 9 oder 10 läuft, ist nicht "etwas hinter der Zeit". Man befindet sich außerhalb der Sicherheitssupport-Fenster – Laravel 10 Security Support endete am 4. Februar 2025. In 2026 bedeutet "läuft noch" nicht dasselbe wie sicher, schnell, wartbar und zukunftsfähig.
Laravel 11 hat den letzten Tag seines Sicherheitssupports am 12. März 2026 erreicht, während Laravel 12 bis zum 24. Februar 2027 unterstützt wird.
Wer als Entscheider eine geschäftskritische Webanwendung auf einer Version ohne aktive Sicherheitsupdates verantwortet, trägt das volle Risiko möglicher Konsequenzen – von Datenschutzverletzungen über Compliance-Verstöße bis hin zu Reputationsschäden. Laravels offizielle Support-Policy ist strikt: Major-Releases erhalten 18 Monate Bugfixes und 2 Jahre Sicherheitsfixes. Sobald eine Version aus dem Sicherheitssupport fällt, hören Framework-seitige Sicherheitspatches auf – was das Risikoprofil des gesamten Produkts verändert.
Technische Schulden: Der stille Kostentreiber
Wenn eine Organisation Sicherheitspatches oder Upgrades ignoriert, akkumuliert sie massive technische Schulden. Studien zeigen, dass technische Schulden die Entwicklungszeit um 20 bis 40 Prozent erhöhen und damit Gesamtprojektkosten und -zeiten in die Höhe treiben.
Das ist der eigentliche Preis des Wartens: nicht das Upgrade selbst, sondern die Summe aller aufgeschobenen Upgrades. Wer von Laravel 11 oder älter springt, sollte immer eine Version nach der anderen upgraden. Laravel 13 ist von Laravel 12 aus einfach. Bei übersprungenen Versionen liegt der meiste Schmerz verborgen.
Das Muster sehen wir in Projekten, die wir bei mindtwo übernehmen, regelmäßig: Was als "einmaliges Upgrade" geplant war, entpuppt sich als monatelanges Migrationsprojekt, weil zu viele Versionen übersprungen wurden und Abhängigkeiten sich verkettet haben. Wer kontinuierlich aktualisiert, vermeidet genau das.
Innovationsverlust: Wenn das Framework mehr kann als die Anwendung
Ältere Laravel-Versionen ohne PHP-8.2+-Kompatibilität sind anfällig für Schwachstellen und blockieren den Zugang zu modernen Tools wie Vite, Octane und Typed Routes.
Jede Version, die nicht mitgegangen wird, ist ein verpasstes Zeitfenster: neue Performance-Features, verbesserte Queue-Architektur, modernere Authentifizierungskonzepte. Das betrifft nicht nur die Entwickler, sondern direkt die Wettbewerbsfähigkeit der darauf aufbauenden Produkte.
Daten aus Q1 2025 zeigen, dass Unternehmen im Durchschnitt 1.925 Cyberangriffe pro Woche verzeichnen – ein Anstieg von 47 Prozent im Jahresvergleich. In diesem Kontext ist ein veraltetes, nicht gepatchtes Framework keine theoretische Bedrohung, sondern eine aktiv ausgenutzte Schwachstelle.
Warum das neue Releasemodell die bessere Strategie ist
Jährliche Releases als planbare Wartungsroutine
Der entscheidende Perspektivwechsel: Laravel folgt einem vorhersehbaren jährlichen Release-Zeitplan und veröffentlicht Major-Versionen typischerweise im ersten Quartal des Jahres. Dieser Zeitplan entspricht Laravels Bekenntnis zu Semantic Versioning – eine Major-Version pro Jahr, jedes Jahr im Q1.
Wer diesen Rhythmus mitgeht, hat keine aufwändigen Migrationsprojekte – sondern planbare, kleinteilige Upgrade-Schritte. Das Aktuell-Bleiben mit Laravel ist heute vor allem eine Wartungsgewohnheit, kein einmaliges Migrations-Event alle paar Jahre.
Das ist der Kern des neuen Denkens: Ein Upgrade von Laravel 12 auf Laravel 13 ist kein Projekt, das man budgetieren und als Sonderprogramm behandeln muss. Laravel 13 wurde am 17. März 2026 mit null Breaking Changes veröffentlicht – und einem Upgrade-Pfad von Laravel 12, der in zehn Minuten abgeschlossen ist.
Welche Pakete mitziehen
Ein häufiges Gegenargument bei Upgrades ist die Frage nach der Paket-Kompatibilität. Die meisten großen Pakete – Livewire, Inertia, Filament, Spatie – haben Laravel-13-Support zum oder kurz nach dem Launch bereitgestellt. Das Ökosystem hat den Rhythmus des Frameworks internalisiert.
Der strukturierte Upgrade-Prozess: Was wirklich zählt
Aus unserer Praxis bei mindtwo als Laravel-Agentur wissen wir: Die meisten Upgrade-Probleme entstehen nicht durch das Framework selbst, sondern durch fehlende Vorbereitung. Ein strukturiertes Vorgehen macht den Unterschied zwischen einem reibungslosen Update und einem Produktionsausfall.
Phase 1: Bestandsaufnahme
Bevor irgendeine Zeile Code geändert wird, steht die ehrliche Analyse des Status quo:
- Welche Laravel-Version läuft aktuell, und wie lange ist sie noch mit Sicherheitsupdates versorgt?
- Welche PHP-Version ist im Einsatz? Laravel 13 erfordert mindestens PHP 8.3.
- Welche Pakete und Abhängigkeiten sind im Einsatz, und sind sie mit der Zielversion kompatibel?
- Wie hoch ist die bestehende Testabdeckung?
Phase 2: Abhängigkeiten und Breaking Changes prüfen
Nicht jedes Paket folgt dem Laravel-Release-Zyklus in gleicher Geschwindigkeit. Ein Dependency-Audit vor dem Upgrade deckt Konflikte auf, bevor sie in der Produktion auftreten. Gerade bei älteren Projekten finden sich hier oft custom Pakete oder gepinnte Versionen, die besondere Aufmerksamkeit brauchen.
Ein direktes Versions-Sprung-Upgrade kann Authentication, Factories, Routing und mehr brechen. Schrittweise Upgrades – Version für Version – vermeiden kritische Kompatibilitätsprobleme.
Phase 3: Staging-Umgebung und Testlauf
Kein Upgrade geht direkt in die Produktion. Eine isolierte Staging-Umgebung, auf der das Upgrade vollständig durchgespielt wird, ist keine Vorsichtsmaßnahme – sie ist Standard. Automatisierte Tests geben dabei die Sicherheit, dass bestehende Funktionalität nach dem Upgrade intakt ist.
Phase 4: Deployment mit Rollback-Strategie
Sichere Migrations-Patterns, Blue/Green- oder Canary-Deployments, Queue-Draining bei geänderten Payloads und ein eingeübter Rollback-Plan gehören zu einem professionellen Upgrade-Deployment dazu. Wer das vordenkt, hat im Ernstfall die Kontrolle.
Wann Zurückhaltung beim Upgrade legitim ist
Nicht jede Zurückhaltung beim Upgraden ist Nachlässigkeit. Es gibt Szenarien, in denen eine bedächtigere Strategie vertretbar ist: hochregulierte Systeme mit aufwändigen Zertifizierungsprozessen, Legacy-Projekte in der finalen Phase ihres Lebenszyklus oder Projekte, bei denen ein laufendes Hauptfeature-Deployment gerade höhere Priorität hat.
Solche Überlegungen entstammen der ursprünglichen LTS-Logik: Systeme, die sich häufige Upgrades oder Breaking Changes nicht leisten können – etwa Enterprise-Plattformen, SaaS-Tools oder Behördensysteme.
Aber auch hier gilt: Wer das Upgrade nur aufschiebt, nicht grundsätzlich ausschließt, sollte den späteren Aufwand von Anfang an einkalkulieren. Der Unterschied zwischen einem geplanten Upgrade-Fenster in sechs Monaten und einem reaktiven Notfall-Upgrade nach einem Sicherheitsvorfall ist erheblich – in Zeit, Kosten und Nerven.
Strategische Implikationen für Unternehmen
Die Wahl der Laravel-Version ist keine rein technische Entscheidung. Sie hat direkte Auswirkungen auf Sicherheitslage, Wartungsaufwand, Entwicklerproduktivität und die Fähigkeit, neue Produktfeatures zeitnah umzusetzen.
Unternehmen, die auf skalierbare Softwarelösungen setzen, sollten das Framework-Versionsmanagement als Teil ihrer IT-Strategie verstehen – nicht als nachgelagerte Entwickler-Aufgabe. Wenn eine Version außerhalb des Sicherheitssupports läuft, ist ein Upgrade keine optionale Maßnahme. Es ist Teil eines verantwortungsvollen operativen Risikomanagements – genauso wie das Patchen von Servern.
Wer das früh verinnerlicht, schützt nicht nur die Infrastruktur, sondern auch die eigene Handlungsfähigkeit: Budgets für Upgrades lassen sich planen, wenn sie als Routineaufgabe behandelt werden – nicht als Krisenreaktion.
Bei mindtwo begleiten wir Unternehmen nicht nur bei der Entwicklung neuer Web-Applikationen, sondern auch bei der Projektübernahme und dem strukturierten Upgrade bestehender Laravel-Systeme. Wir kennen die Stolperstellen bei Versionsmigration aus der Praxis – und wissen, wie man sie identifiziert, bevor sie zum Problem werden.
Fazit: Aktualität als Betriebsstandard, nicht als Aufwand
Das LTS-Konzept hatte seinen Platz in einer Ära, in der Major-Releases weniger planbar und Upgrades riskanter waren. Laravel hat sein Release-Modell weiterentwickelt – bewusst und konsequent. Laravel 13 ist das aktuellste Release, Laravel 12 ist weiterhin vollständig unterstützt, und Laravel 11 ist nicht mehr im Sicherheitssupport. Es gibt keinen aktiven LTS-Zweig mehr – die sicherste langfristige Gewohnheit ist es, Upgrades zur Routine zu machen.
Der Maßstab für professionelle Webentwicklung mit Laravel ist nicht mehr "so selten updaten wie möglich", sondern "so kontinuierlich updaten wie nötig". Wer das als festen Bestandteil seines Entwicklungsprozesses verankert, arbeitet mit dem Framework – nicht gegen es. Und wer dabei einen erfahrenen Partner an der Seite hat, der den Lifecycle einer Laravel-Anwendung von Anfang an mitdenkt, stellt fest: Aktuell zu bleiben ist kein Mehraufwand. Es ist der Standard.
