Legacy-PHP-Modernisierung zu Laravel ohne Big-Bang-Relaunch

Ein altes PHP-System lässt sich zu Laravel modernisieren, ohne das Unternehmen für einen großen Relaunch anzuhalten: Man stellt Laravel neben die bestehende Anwendung, leitet Anfragen über eine gemeinsame Routing-Schicht und ersetzt Modul für Modul, während beide Systeme auf dieselben Daten zugreifen. Dieses Vorgehen ist als Strangler-Fig-Muster bekannt. Es dauert insgesamt nicht unbedingt kürzer als eine Neuentwicklung, aber jeder Schritt ist klein, messbar und rückgängig zu machen – und das Tagesgeschäft läuft weiter.

Warum der Big-Bang-Relaunch so oft scheitert

Die Idee ist verlockend: ein neues System auf der grünen Wiese, in anderthalb Jahren umschalten, fertig. In der Praxis stößt dieser Ansatz auf drei Probleme.

• Verborgene Geschäftslogik. In gewachsenen PHP-Anwendungen stecken Sonderregeln für einzelne Kunden, Rundungen, Statusübergänge und Workarounds, die niemand dokumentiert hat. Sie tauchen erst auf, wenn das neue System sie nicht kennt.
• Doppelte Weiterentwicklung. Während das neue System entsteht, muss das alte weiter angepasst werden. Jede Änderung muss zweimal gebaut werden, oder die Fachabteilung wartet.
• Riskanter Stichtag. Beim Umschalten ändert sich alles gleichzeitig: Code, Datenbankstruktur, Oberfläche, Schnittstellen. Tritt ein Fehler auf, ist die Ursache schwer einzugrenzen und ein Zurück kaum möglich.

Gerade im Mittelstand, wo ein ERP-nahes Eigenentwicklungssystem Aufträge, Lieferscheine oder Kundenportale trägt, ist ein solcher Stichtag ein Geschäftsrisiko.

Wann Modernisierung dringend wird

Typische Auslöser, die wir in Projekten sehen:

• Die Anwendung läuft auf PHP 7.x oder 8.0/8.1 und erhält damit keine Sicherheitsupdates mehr.
• Hosting-Anbieter kündigen die Unterstützung alter PHP-Versionen oder Betriebssysteme.
• Neue Anforderungen lassen sich kaum umsetzen, zum Beispiel eine API für Partner oder die Anbindung an Prozesse rund um die E-Rechnung, deren Empfang in Deutschland seit 2025 für Unternehmen verpflichtend ist.
• Das Wissen über das System liegt bei einer einzigen Person.
• Es gibt keine automatisierten Tests, jede Änderung wird manuell auf dem Produktivsystem geprüft.

Der schrittweise Weg zu Laravel

Schritt 1: Bestandsaufnahme

Bevor Code geschrieben wird, braucht es ein klares Bild: Welche Module gibt es, welche werden täglich genutzt, welche sind tot? Welche Tabellen gehören zu welchem Bereich? Welche Cronjobs, Importe und Schnittstellen laufen im Hintergrund? Hilfreich sind Zugriffslogs des Webservers, um echte Nutzung von vermuteter Nutzung zu unterscheiden, und eine Liste aller externen Abhängigkeiten.

Schritt 2: Sicherheitsnetz aufbauen

Für ein System ohne Tests schreibt man zuerst sogenannte Charakterisierungstests: Sie halten fest, wie sich die Anwendung heute verhält, auch wenn dieses Verhalten nicht ideal ist. Beispiele sind die Preisberechnung für bestimmte Kundengruppen, der Export einer Rechnung oder die Statuswechsel eines Auftrags. Ergänzend lohnt sich statische Analyse mit PHPStan, beginnend mit einer niedrigen Stufe und einer Baseline für bekannte Probleme.

Schritt 3: PHP-Version anheben

Oft ist es sinnvoll, zuerst die bestehende Anwendung auf eine unterstützte PHP-Version zu bringen. Werkzeuge wie Rector automatisieren einen großen Teil der nötigen Codeänderungen. Das senkt das Sicherheitsrisiko sofort und schafft die Voraussetzung, alten und neuen Code auf demselben Server zu betreiben.

Schritt 4: Laravel daneben stellen

Laravel wird als eigene Anwendung installiert, idealerweise in der aktuellen Version 12 oder 13. Eine Routing-Schicht – der Webserver oder ein vorgeschalteter Proxy – entscheidet pro Pfad, ob die Anfrage an Laravel oder an den Altcode geht. Anfangs übernimmt Laravel nichts; alle Anfragen laufen weiter an das alte System.

Damit Nutzer den Übergang nicht bemerken, müssen einige Dinge geteilt werden:

• Anmeldung: entweder eine gemeinsame Session oder ein Single Sign-on, damit niemand sich doppelt einloggt.
• Datenbank: in der Übergangszeit greifen beide Systeme auf dieselbe Datenbank zu. Laravel-Modelle werden auf die bestehenden Tabellen gemappt, Strukturänderungen erfolgen nur mit Rücksicht auf den Altcode.
• Layout: Navigation und Grunddesign sollten konsistent sein, auch wenn einzelne Seiten neu gebaut werden.

Schritt 5: Modul für Modul umziehen

Man beginnt mit einem Bereich, der klar abgegrenzt ist und spürbaren Nutzen bringt, etwa einer neuen API für Partner, einem Reporting oder einem Teil des Kundenportals. Nach dem Umzug wird der Pfad auf Laravel umgestellt. Funktioniert etwas nicht, lässt sich die Weiterleitung sofort zurückdrehen. Erst wenn ein Modul stabil läuft, wird der alte Code entfernt.

Schritt 6: Daten und Hintergrundprozesse

Cronjobs werden in den Laravel Scheduler überführt, lange laufende Aufgaben in Queues. Importe und Exporte erhalten Protokolle und Wiederholungslogik. Die Datenbankstruktur wird erst dann bereinigt, wenn kein Altcode mehr auf die betroffenen Tabellen zugreift.

Beispiel: der erste umgezogene Bereich

Angenommen, Ihre Außendienstmitarbeiter und Händler fragen Lagerbestände heute telefonisch ab, weil das alte System keine Schnittstelle hat. Ein naheliegender erster Schritt ist eine kleine Laravel-API:

1. Der Proxy leitet alle Anfragen unter `/api/` an Laravel, alles andere weiter an den Altcode.
2. Laravel liest Artikel und Bestände aus den bestehenden Tabellen, nur lesend.
3. Partner erhalten Tokens über Sanctum, jede Anfrage wird protokolliert.
4. Ein Cache verhindert, dass häufige Abfragen die alte Datenbank belasten.

Das Altsystem bleibt unverändert, der Nutzen ist sofort sichtbar, und das Team sammelt Erfahrung mit dem parallelen Betrieb, bevor schreibende Prozesse wie Aufträge migriert werden.

Typische Fehler bei der Migration

• Alles gleichzeitig umbauen wollen. Wer Code, Datenmodell und Oberfläche in einem Schritt ändert, verliert den Vorteil des schrittweisen Vorgehens.
• Das neue System als Kopie des alten bauen. Nicht jede historische Sonderlösung muss übernommen werden. Jedes Modul ist eine Gelegenheit, mit der Fachabteilung zu klären, was tatsächlich gebraucht wird.
• Ohne Monitoring umschalten. Fehlerprotokolle, Laufzeiten und Queue-Status sollten sichtbar sein, bevor der erste Pfad umgestellt wird.
• Die Übergangsphase unterschätzen. Einige Monate lang laufen zwei Systeme parallel. Das muss im Betrieb, in der Dokumentation und im Deployment berücksichtigt werden.

Entscheidungshilfe: Umbau oder Neuentwicklung?

Der schrittweise Umbau passt, wenn das bestehende System fachlich im Wesentlichen richtig ist, das Datenmodell brauchbar ist und das Unternehmen keinen Stillstand verkraftet. Eine Neuentwicklung kann sinnvoll sein, wenn sich das Geschäftsmodell grundlegend geändert hat, die Datenstruktur nicht mehr zu den Prozessen passt oder das System nur einen kleinen, gut abgrenzbaren Umfang hat. Häufig ist die ehrliche Antwort eine Mischung: Der Kern wird schrittweise migriert, einzelne Bereiche werden neu gedacht.

Wenn Sie parallel Schnittstellen zu ERP oder Shop neu aufbauen, lesen Sie auch unseren Beitrag über API-Integrationen für ERP, CRM und E-Commerce. Worauf Sie bei der Wahl eines externen Teams achten sollten, beschreiben wir im Artikel Laravel Software House Polen für B2B-Systeme.

Checkliste für den Start

• Liste aller Module mit Nutzungshäufigkeit
• Liste aller Schnittstellen, Cronjobs und Importe
• Aktuelle PHP-Version, Server und Hosting-Situation
• Vorhandene Tests und Dokumentation
• Ein Modul, das sich als erster Umzugskandidat eignet
• Eine verantwortliche Person auf Fachseite

Nächster Schritt

Am Anfang steht keine Entwicklung, sondern eine kurze technische Analyse: Codebasis, Datenbank, Server und Schnittstellen werden gesichtet, und daraus entsteht ein Migrationsplan mit Reihenfolge der Module und klaren Risiken. Wie wir das angehen, beschreiben wir auf der Seite PHP- und Laravel-Modernisierung. Wenn Sie Ihr System einschätzen lassen möchten, schreiben Sie uns – ein Zugang zum Repository und eine Übersicht der Schnittstellen reichen für den ersten Blick.