Manchmal merkt man beim Arbeiten an einem neuen Projekt was einem an einem älteren fehlt. Genau das ist passiert: Bei neueren Laravel-Projekten haben wir direkt mit Version 13 gestartet und dabei Features entdeckt, die wir rückwirkend auch in unserem eigenen Produkt haben wollten.
Allen voran: native Suche in verschlüsselten Datenbankspalten. Ein Feature das für datenschutzsensible Anwendungen konkret relevant ist — und das in Laravel 13 sauber im Standard mitkommt, ohne eigene Konstrukte drumherum.
Dazu kam eine pragmatische Entscheidung: Lieber jetzt migrieren, bevor weitere Features dazukommen. Je mehr ein System wächst, desto mehr gibt es beim nächsten Mal zu testen und anzupassen. Wer das kennt, kennt auch den Moment wo man sich denkt: hätte ich das früher gemacht.
Das Projekt hatte über die Zeit einige eigene Klassenkonstrukte und Besonderheiten im Front- und Backend angesammelt. Dinge, für die Laravel zwar die Basis gelegt hatte, die wir aber selbständig weiterentwickelt hatten. Entsprechend stand zu Beginn gefühlt eine sehr lange Checkliste im Raum.
Am Ende zeigte sich: Es ging schneller als erwartet. Der Grund dafür hat weniger mit der Laravel-Version zu tun als mit dem Zustand des Projekts davor.
Der entscheidende Faktor: Wie nah ist das Projekt am Standard?
Laravel bietet ein starkes Fundament. Wer dieses Fundament nutzt statt es zu umgehen, profitiert bei jeder neuen Version. In diesem Fall war das Projekt zu etwa 80% standard-nah aufgebaut — und genau das hat die Migration zur überschaubaren Aufgabe gemacht.
Wichtig: 80% Standard bedeutet nicht, dass keine eigenen Konstrukte vorhanden waren. Es bedeutet, dass diese Konstrukte an den richtigen Stellen saßen — dort wo Laravel Erweiterung ausdrücklich vorsieht, nicht dort wo man das Framework gegen seinen eigenen Willen biegt. Das ist ein entscheidender Unterschied.
Das ist keine Selbstverständlichkeit. Viele Projekte wachsen über Jahre und sammeln Anpassungen an, die eigentlich Symptome eines Problems sind: ein Framework-Feature das nicht funktioniert hat, eine temporäre Lösung die dauerhaft geblieben ist, ein Workaround der nie dokumentiert wurde. Wer das irgendwann migrieren muss, merkt es spätestens dann.
Wo es trotzdem knifflig wurde
Zwei Stellen haben Aufmerksamkeit gebraucht:
Fortify-Anpassungen
Für einen spezifischen Login-Flow hatten wir Fortify in der Vergangenheit an einigen Stellen erweitert. Laravel 13 bringt hier eine sauberere Standardlösung mit — was bedeutet, dass unsere Anpassungen zurückgebaut und neu aufgesetzt werden mussten. Kein Drama, aber es braucht Sorgfalt: wer hier schludert, baut sich stille Sicherheitsprobleme ein.
Tailwind CSS
Die Art wie eigene CSS-Definitionen neben dem Tailwind-Standard eingebunden werden, hat sich geändert. Was vorher funktioniert hat, führt jetzt zu unerwartetem Verhalten — oder gar keinem. Wer das nicht auf dem Radar hat, sucht unter Umständen lange an der falschen Stelle.
Was das für dein Projekt bedeutet
Eine Laravel-Migration ist kein Hexenwerk — wenn man weiß was man tut und das Projekt nicht jahrelang gegen den Standard entwickelt wurde.
Die ehrliche Frage vor jeder Migration lautet: Wie viel davon ist Framework, wie viel ist eigenes Konstrukt? Je klarer die Antwort, desto realistischer die Einschätzung was die Migration kostet.
Wer das nicht beurteilen kann oder möchte, ist gut beraten das einmal mit jemandem durchzugehen der den Aufwand sauber einschätzen kann — bevor es teuer wird.
FAQ
Sollte man mehrere Laravel-Versionen überspringen?
Nicht empfehlenswert. Wer beispielsweise von Laravel 8 direkt auf 13 möchte, sollte entweder das Projekt komplett neu aufbauen oder mehrere Migrationen nacheinander durchführen — also erst von 8 auf 10, dann weiter. Über mehrere Versionen hinweg ändert sich so viel, dass ein direkter Sprung sich am Ende wie „Projekt neu schreiben, aber mit altem Chaos“ anfühlt.
Kann es sinnvoll sein, eigene Funktionen auf den Standard zurückzubauen?
Sehr definitiv. Es reduziert Komplexität, baut technische Schuld ab und macht zukünftige Weiterentwicklung und spätere Migrationen deutlich einfacher. Was heute ein bisschen Aufwand ist, spart beim nächsten Mal erheblich mehr.
Woran erkenne ich ob mein Projekt migrationsbereit ist?
„Bereit“ gibt es nicht wirklich — aber es gibt gute Anzeichen: wenn die neue Framework-Version Dinge verbessert hat die man selbst intensiv nutzt, wenn neue Features den zukünftigen Entwicklungsweg vereinfachen, oder wenn man schlicht schon sehr lange nicht mehr modernisiert hat. Neue Framework-Versionen sind nicht nur neue Features — sie bringen immer auch Verbesserungen in Sicherheit und Stabilität mit. Das allein ist oft Grund genug.
Kommentar verfassen