Irgendwann kommt bei jeder gewachsenen Laravel-Anwendung der Moment, in dem jemand im Meeting sagt: "Lass uns das einfach neu bauen." Die App ist auf Laravel 6 oder 7 stehengeblieben, das Deployment ist eine Zitterpartie, und niemand traut sich mehr, den Bestellprozess anzufassen. Der Neubau klingt nach einem sauberen Neuanfang. In der Praxis ist er fast immer die teuerste und riskanteste Option, die auf dem Tisch liegt.
Ich rette seit Jahren Legacy-PHP-Anwendungen, und die Ausgangslage ist erstaunlich oft dieselbe. Deshalb lohnt es sich, die Frage "Laravel modernisieren oder neu bauen" nüchtern zu zerlegen, bevor Budget freigegeben wird.
Warum ein laufendes System kein Müll ist
Ein System, das seit Jahren im Produktivbetrieb läuft, hat eine Eigenschaft, die kein Prototyp und kein Greenfield-Projekt am ersten Tag hat: Es funktioniert. Jede Sonderregel bei der Rabattberechnung, jeder Umgang mit dem einen kaputten Datensatz aus 2019, jede stille Absprache mit der Buchhaltung steckt in diesem Code. Das ist keine technische Schuld, das ist verdientes Wissen.
Genau dieses Wissen verlieren Sie beim Neubau als Erstes. Die Fachlogik in Laravel ist selten das Problem. Das Problem ist fast immer der Code drumherum: fette Controller mit 800 Zeilen, Business-Logik in Blade-Templates, direkte SQL-Strings statt Eloquent, keine Tests, ein `composer.json`, das seit drei Jahren nicht aktualisiert wurde. Das lässt sich reparieren, ohne die funktionierende Logik wegzuwerfen.
Woran Sie erkennen, dass modernisieren reicht
Modernisieren ist in der Regel die richtige Wahl, wenn die Fachlogik korrekt ist und nur die technische Umgebung veraltet. Das ist der häufigste Fall. Konkrete Anzeichen dafür:
- Die App erfüllt fachlich, was sie soll. Nutzer beschweren sich über Tempo oder Fehler, nicht über fehlende Kernfunktionen.
- Sie steckt auf einer alten Laravel- und PHP-Version fest (etwa PHP 7.4, Laravel 6), aber die Architektur ist noch als MVC erkennbar.
- Es gibt kein oder kaum ein Testnetz, weshalb sich niemand traut, etwas zu ändern.
- Die Datenbank ist sauber genug, dass man mit Migrationen und Eloquent-Modellen arbeiten kann.
In diesem Zustand ist Modernisierung schrittweise und risikoarm möglich. Sie aktualisieren PHP und Laravel Version für Version, ziehen mit Tools wie Rector automatisierte Code-Upgrades, führen Feature-Tests für die kritischen Pfade ein und schnüren Business-Logik nach und nach aus den Controllern in Services oder Actions. Der Betrieb läuft die ganze Zeit weiter.
Wann ein Neubau wirklich gerechtfertigt ist
Ein kompletter Neubau lohnt sich nur, wenn das fachliche Modell selbst falsch ist oder das Geschäft etwas grundlegend anderes braucht. Das kommt vor, ist aber die Ausnahme. Ehrliche Gründe für einen Neubau:
- Das Datenmodell bildet die Realität nicht mehr ab, und keine Migration kann das heilen, weil die Grundannahmen falsch waren.
- Das Produkt soll etwas fundamental anderes werden, nicht das Bestehende besser.
- Der Kern hängt an einer Technologie ohne Zukunft, für die es keinen sinnvollen Upgrade-Pfad gibt.
Was dagegen kein ausreichender Grund für einen Neubau ist: hässlicher Code, eine veraltete Version oder die Tatsache, dass niemand im Team die App mehr versteht. Alle drei lassen sich beheben, ohne bei null anzufangen und ohne das über Jahre erprobte Verhalten neu zu erfinden.
Die versteckten Kosten des Neubaus
Der Neubau wird selten so kalkuliert, wie er tatsächlich abläuft. Man plant die Neuentwicklung der bekannten Features und vergisst, dass die alte App parallel weiterläuft, weiter gepflegt werden muss und weiter Bugfixes braucht. Sie zahlen also für zwei Systeme gleichzeitig, oft über ein Jahr oder länger.
Dazu kommt die Migration der Bestandsdaten, die praktisch immer aufwendiger ist als gedacht, und die stille Sammlung von Sonderfällen, die im alten Code steckt und im neuen erst schmerzhaft wiederentdeckt wird. Bis der Neubau produktiv das kann, was das alte System längst konnte, ist häufig mehr Zeit und Geld geflossen als eine gründliche Modernisierung gekostet hätte.
Ein realistischer Mittelweg: der Strangler-Fig-Ansatz
Zwischen "alles behalten" und "alles neu" liegt der Weg, der in der Praxis am besten funktioniert. Beim Strangler-Fig-Muster ersetzen Sie das Alte Stück für Stück, während es weiterläuft. Ein typischer Ablauf:
- Zuerst kommt ein Sicherheitsnetz aus Feature-Tests um die geschäftskritischen Abläufe, damit Änderungen messbar werden.
- Dann werden PHP und Laravel auf aktuelle, unterstützte Versionen gehoben, damit Sie wieder Sicherheitsupdates bekommen.
- Anschließend lösen Sie einzelne, klar abgegrenzte Bereiche heraus und bauen sie sauber neu, während der Rest unverändert bleibt.
Der entscheidende Vorteil: Jeder Schritt liefert für sich schon Wert, und Sie können jederzeit anhalten, ohne mit einem halbfertigen Neubau dazustehen. Genau diese Rückfalloption fehlt beim klassischen Big-Bang-Rewrite komplett.
Ein Wort zur Sicherheit
Ein oft übersehener Punkt in der Abwägung: Eine alte Laravel-Version bekommt keine Sicherheitsupdates mehr. Bekannte Lücken in Framework, PHP-Runtime oder Abhängigkeiten bleiben offen. Das ist kein ästhetisches, sondern ein handfestes Risiko. Und es ist ein Argument für die Modernisierung, denn ein Versionssprung schließt diese Lücken in Wochen, während ein Neubau die alte, verwundbare App noch monatelang online lässt.
Der ehrliche Praxis-Tipp
Bevor Sie über den Neubau entscheiden, beantworten Sie eine einzige Frage ehrlich: Ist die Fachlogik falsch, oder ist nur der Code darum herum alt? Fast immer ist es das Zweite. Dann ist Modernisieren schneller, billiger und sicherer als jeder Neuanfang. Beginnen Sie mit Tests für Ihre wichtigsten drei Prozesse, nicht mit einem Rewrite.
Wenn Sie bei genau dieser Einschätzung eine zweite, unabhängige Meinung wollen, ist das der Punkt, an dem ich mit LegacyWerk unterstütze.
