"Laravel Wartung" klingt nach einem Zusatzprodukt, ist aber die Voraussetzung dafür, dass eine Anwendung morgen noch läuft. Die ehrliche Antwort: Wartung ist kein monatliches Ritual, sondern eine Kette aus Versionsfristen, Abhängigkeits-Updates, Backups und Tests. Wird sie unterbrochen, zahlt man das später – als Sicherheitslücke, als Ausfall oder als teuren Rewrite.
Warum "Wartung" kein Versicherungsprodukt ist
Der Begriff wird im Markt gern verwendet, um einen Retainer zu verkaufen. Technisch ist er präziser: Wartung ist die Summe der Arbeiten, die verhindern, dass eine Laravel-Anwendung in einen Zustand gerät, in dem niemand mehr sicher deployen kann.
Die Konsequenz ist nüchtern. Wenn ein Team drei Monate kein Update einspielt, sammeln sich Sicherheitslücken in Abhängigkeiten an, das Testsystem veraltet gegenüber der Produktion und der nächste Release wird zum Risiko. Wartung ist damit kein Komfort, sondern die Voraussetzung dafür, dass Änderungen überhaupt noch auslieferbar sind.
Die zwei Fristen, die über Ihre Version entscheiden
Laravel veröffentlicht eine feste Support-Policy. Jede Version erhält 18 Monate lang Bugfixes und zwei Jahre lang Security-Fixes. Nach Ablauf der Security-Frist werden für diese Version keine Sicherheitsupdates mehr veröffentlicht.
Die beiden Fristen im Überblick
- Bugfix-Frist (18 Monate): Regelmäßige Fehlerbehebungen im Framework selbst.
- Security-Frist (2 Jahre): Sicherheitsupdates für gemeldete Schwachstellen.
- Danach: Keine weiteren Sicherheitsupdates für diese Version – ein Wechsel ist dann keine Optimierung mehr, sondern die Voraussetzung für einen sicheren Betrieb.
Wichtig ist die Einordnung: Bugfix- und Security-Frist sind nicht dasselbe. Eine Version kann längst keine Bugfixes mehr bekommen, aber noch Security-Fixes – oder umgekehrt, je nachdem, wie lange sie bereits im Markt ist. Der genaue Status Ihrer Version zeigt meine Übersicht der Laravel-Versionen.
| Version | Veröffentlicht | PHP | Bugfixes bis | Security-Fixes bis | Status (Stand 12.11.2026) |
|---|---|---|---|---|---|
| Laravel 10 | 14.02.2023 | 8.1 – 8.3 | 06.08.2024 | 04.02.2025 | abgelaufen – kein Security-Support mehr |
| Laravel 11 | 12.03.2024 | 8.2 – 8.4 | 03.09.2025 | 12.03.2026 | abgelaufen – kein Security-Support mehr |
| Laravel 12 | 24.02.2025 | 8.2 – 8.5 | 13.08.2026 | 24.02.2027 | nur noch Security-Fixes |
| Laravel 13 | 17.03.2026 | 8.3 – 8.5 | Q3 2027 | 17.03.2028 | Bugfixes und Security-Fixes |
Stand: 12.11.2026. Angaben aus der offiziellen Support-Policy von Laravel; die exakten Termine bitte vor einer Planung gegen die aktuelle Dokumentation prüfen. Zum Stand dieses Artikels sind die Security-Fristen von Laravel 10 (04.02.2025) und Laravel 11 (12.03.2026) bereits abgelaufen – für beide Versionen gibt es keine Sicherheitsupdates mehr.
Der zweite Support-Takt: PHP
Laravel steht und fällt mit der PHP-Version darunter. Eine Laravel-Version läuft nur auf den PHP-Versionen, die sie unterstützt – und PHP selbst hat eine eigene Support-Frist: zwei Jahre aktive Unterstützung (Fehler und Sicherheitslücken werden laufend behoben), danach zwei weitere Jahre, in denen nur noch kritische Sicherheitslücken behoben werden, anschließend End of Life. Insgesamt sind das vier Jahre je PHP-Version.
Praktisch bedeutet das: Der Unterstützungszeitraum von Laravel und der von PHP überlappen nur teilweise. Ein Projekt, das auf PHP 8.1 läuft, hat die PHP-Unterstützung bereits vollständig verloren – PHP 8.1 ist seit dem 31.12.2025 End of Life und erhält keine Patches mehr, weder für Fehler noch für Sicherheitslücken. Prüfen Sie deshalb beide Achsen – den Laravel-Versionsstatus und die PHP-Supportfristen – und nicht nur die Framework-Version.
Der häufigste teure Fehler
Ein Laravel-Upgrade auf die neueste Version ist kein automatisches PHP-Upgrade. Wer die Framework-Version aktualisiert, aber PHP auf einer alten 8.x-Line belässt, verschiebt das Problem nur – und bindet das Team an eine PHP-Version, die selbst kurz vor dem Support-Ende steht. Beide Achsen gehören in dieselbe Planung.
Was in eine Wartungsrunde gehört
"Wartung" ist nur dann ein Begriff, wenn man sie aufzählen kann. Diese Bausteine gehören zu jedem Durchlauf:
1. Framework-Version und PHP-Version aktuell halten
Der Einstieg ist der Vergleich: Welche Laravel-Version läuft, welche PHP-Version läuft, und wo liegen die Supportfristen? Das Ergebnis ist die Upgrade-Distanz – also die Anzahl der Major-Versionen, die zwischen dem aktuellen Stand und dem Ziel liegen. Je größer der Abstand, desto mehr Aufwand, und desto eher lohnt sich ein gezielter Blick auf einen Rewrite (siehe unten).
2. Composer-Abhängigkeiten auf Sicherheitslücken prüfen
Der eigene Anwendungscode ist selten das Problem – die Pakete im vendor-Verzeichnis sind es. Composer liefert dafür zwei eingebaute Werkzeuge:
composer auditprüft die installierten Pakete auf bekannte Sicherheitslücken.composer outdatedzeigt, welche Pakete neuere Versionen haben.
Wichtig: Beide Befunde sind Handlungsbedarf, kein Automatismus. Ein major-Update eines Pakets kann eine breaking change enthalten und den Testlauf brechen – genau deshalb ist der nächste Punkt nicht optional.
3. Backups wiederherstellbar halten
Ein Backup, das nie getestet wurde, ist eine Behauptung, keine Absicherung. Wartung umfasst deshalb den Wiederherstellungstest: eine Umgebung aufsetzen, den letzten Datensatz zurückspielen und prüfen, ob die Anwendung damit wirklich startet. Ein Backup, das nur aus einer Datei auf einer Festplatte besteht, ist bei einem Ausfall derselben Festplatte kein Backup.
4. Monitoring und Alarmierung prüfen
Wer erst nach dem Ausfall erfährt, dass das Monitoring nichts meldet, hat kein Monitoring. Wartung prüft, ob die Alarmierung auslöst – testweise ein Fehler auslösen, prüfen, ob die Meldung ankommt und ob die richtige Person sie bekommt. Fehlermeldungen, die im Log landen und niemanden erreichen, sind ein Zustand, den man bemerkt, aber nicht behebt.
5. Tests als Upgrade-Absicherung
Der eigentliche Grund, warum Wartung sich rechnet: Eine gute Testabdeckung macht ein Upgrade berechenbar. Ohne Tests ist jedes Update eine Lotterie, und die Kosten des Updates steigen mit jedem Monat ohne Abdeckung. Die Tests sind damit kein Qualitätsmerkmal, sondern das Werkzeug, das den Wartungsaufwand begrenzt.
Upgrade oder Neubau: die Entscheidung, die vor der Arbeit steht
Nicht jede Laravel-Anwendung wartet man zwangsläufig weiter. Wenn die Distanz zwischen Ist- und Zielversion groß ist, das Team die Anwendung nicht mehr kennt oder das Test-Netz zu dünn für einen sicheren Sprung ist, kann ein Neubau günstiger sein als die schrittweise Reparatur. Diese Entscheidung fällt vor der Arbeit, nicht danach – und sie ist eine der wichtigsten Entscheidungen bei Bestandssoftware.
| Kriterium | Upgrade sinnvoll, wenn … | Neubau sinnvoller, wenn … |
|---|---|---|
| Distanz zur Zielversion | nur ein bis zwei Major-Versionen | mehrere Versionen, jeweils mit Breaking Changes |
| Testabdeckung | relevante Pfade sind automatisiert getestet | kaum Tests, Verhalten nur manuell nachvollziehbar |
| Codequalität | Struktur trägt, Refactoring klein machbar | technische Schulden dominieren den Aufwand |
| Datenmodell und Schnittstellen | passen weiterhin zum Geschäftsmodell | müssen ohnehin neu geschnitten werden |
| Wirtschaftlichkeit | Upgrade kostet deutlich weniger als ein Neubau | das Produkt ohnehin neu positioniert wird |
Wenn Sie unsicher sind, welche Seite überwiegt, ist ein Architektur-Audit der saubere Einstieg: Sie bekommen eine belastbare Entscheidungsgrundlage statt einer Schätzung. Die Checkliste für Legacy-Systeme hilft beim ersten groben Sortieren.
Was Wartung kostet – und warum sich das rechnet
Die Kosten eines Wartungsvertrags sind planbar. Die Kosten eines nicht gewarteten Systems sind es nicht: Ein Sicherheitsvorfall, ein ungeplanter Ausfall oder ein Major-Upgrade unter Druck, bei dem niemand mehr den Zustand des Codes kennt. Der Vergleich dieser beiden Größen ist keine Marketingfrage, sondern die einfachste Rechnung in der Softwarewartung.
Mein Angebot für Support & Wartung deckt die oben genannten Bausteine ab – von der Versionsplanung über Sicherheits-Updates bis zur Wiederherstellungsprobe. Sie finden die passenden Pakete in der Übersicht der Lösungen, die laufenden Kosten im TCO-Rechner.
Häufige Fragen zu Laravel Wartung
Was kostet Laravel Wartung?
Für eine reine Wartungsbetreuung gibt es keinen Pauschalpreis, weil der Aufwand vom Zustand der Anwendung abhängt: Wie viele Major-Versionen fehlen, wie gut ist das Test-Netz, wie viele Abhängigkeiten sind veraltet. Belastbar sind daher die Pauschalen für klar umrissene Arbeiten, die Sie auf der Leistungsseite finden: das Audit-Paket für einen Code-Review, Performance-Check oder eine Architektur-Analyse (1.800 bis 2.500 EUR), das Architektur-Audit mit schriftlichem Report zum Festpreis von 2.500 EUR (zzgl. MwSt.) und Surgical Strike für ein einzelnes schweres Problem ab 150 EUR pro Stunde (zzgl. MwSt.). Für laufende Betreuung nennen Sie mir den Umfang, dann bekommen Sie ein Angebot statt einer Schätzung nach Faustregeln.
Für wen lohnt sich Laravel Wartung?
Für jede Laravel-Anwendung, die produktiv genutzt wird und weiterentwickelt werden soll – der Unterschied ist nur, wie dringend es ist. Dringend wird es, wenn Ihre Laravel-Version keine Security-Fixes mehr bekommt, wenn die PHP-Version kein Sicherheitsupdate mehr erhält oder wenn das letzte Update länger als ein Jahr zurückliegt. Das trifft im Jahr 2026 auf jede Anwendung auf Laravel 10 oder 11 zu; Laravel 12 bekommt nur noch bis zum 24.02.2027 Sicherheitsupdates, Laravel 13 bis zum 17.03.2028.
Lohnt sich Wartung gegenüber einem Neubau vor allem dann, wenn Ihr Datenmodell, Ihre Schnittstellen und Ihre fachlichen Regeln weiterhin passen und das Test-Netz trägt. Wenn dagegen die technische Schulden den Aufwand bestimmen und Sie das Produkt ohnehin neu positionieren wollen, ist der Neubau die ehrlichere Rechnung. Beide Wege gegeneinander abzuwägen ist genau der Job eines Architektur-Audits; die Checkliste für Legacy-Systeme hilft beim ersten groben Sortieren.
Ihr nächster Schritt: der Zustand Ihrer Anwendung
Sie müssen nicht raten, ob Ihre Anwendung wartungsbedürftig ist. Drei Angaben genügen für eine erste Einschätzung:
- Welche Laravel-Version läuft aktuell?
- Welche PHP-Version läuft?
- Wann wurde das letzte Update eingespielt?
Mit diesen drei Werten lässt sich Ihr Fenster bis zum nächsten Support-Ende bestimmen. Ist das Fenster kleiner als die Zeit, die ein Upgrade realistisch braucht, ist der Handlungsbedarf klar – und Sie wissen auch, wie viel Puffer Sie haben.
Wartungsbedürftige Laravel-Anwendung?
Schildern Sie mir Ihre aktuelle Version und das Problem. Ich prüfe die Versionsfristen, den PHP-Stand und den sinnvollsten Weg – Upgrade, Wartungspaket oder Neubau.
Quellen
- Laravel, „Releases“ – Support Policy und Versionstabelle (Laravel 10 bis 13, PHP-Kompatibilität, Bugfix- und Security-Fristen), abgerufen am 12.11.2026. https://laravel.com/docs/13.x/releases#support-policy
- PHP.net, „Supported Versions“ – aktive Unterstützung (2 Jahre) und Security-Support (2 weitere Jahre) je PHP-Version, abgerufen am 12.11.2026. https://www.php.net/supported-versions.php
- PHP.net, „Unsupported Branches“ – End-of-Life-Datum je PHP-Version (PHP 8.1 seit 31.12.2025 ohne Support), abgerufen am 12.11.2026. https://www.php.net/eol.php
- Laravel, „Upgrade Guide“ – Vorgehen und begleitende Änderungen bei Versionswechseln, abgerufen am 12.11.2026. https://laravel.com/docs/13.x/upgrade
- Composer, „CLI – Audit“ und „Outdated“ – Prüfung installierter Pakete auf bekannte Sicherheitslücken und verfügbare Updates, abgerufen am 12.11.2026. https://getcomposer.org/doc/03-cli.md
Stand: 12.11.2026. Support-Fristen und Versionsdaten sind der offiziellen Dokumentation von Laravel und PHP entnommen und können sich mit neuen Releases ändern. Konkrete Termine und Aufwände für Ihr Projekt bitte mit mir abstimmen.