Alte PHP-Anwendung auf Laravel umstellen: fünf Fragen vor dem Auftrag

Viele Firmen, mit denen ich spreche, betreiben eine PHP-Anwendung, die vor zehn oder fünfzehn Jahren ohne Framework entstanden ist. Ein Kundenportal, ein Bestellsystem, eine interne Verwaltung. Sie läuft, das Geschäft hängt daran, aber jede Änderung dauert länger als die letzte, und der Entwickler, der sie gebaut hat, ist oft nicht mehr da.

Irgendwann fällt dann der Satz "Wir sollten das auf Laravel umstellen". Der Gedanke ist meistens richtig. Wie diese Umstellung abläuft, entscheidet aber darüber, ob sie in einem halben Jahr fertig ist oder nach anderthalb Jahren abgebrochen wird. Die folgenden fünf Fragen sollten Sie beantwortet haben, bevor Sie einen Auftrag vergeben.

Brauchen Sie überhaupt Laravel?

Nicht jede alte Anwendung muss auf ein Framework. Wenn Ihr eigentliches Problem ist, dass der Hoster die alte PHP-Version abschaltet, reicht oft eine Migration auf eine unterstützte Version, ohne Umbau. Was das kostet und wovon es abhängt, steht in Upgrade auf PHP 8.5.

Ein Framework lohnt sich, wenn mindestens eines davon auf Sie zutrifft:

• Die Anwendung soll noch Jahre laufen und weiter wachsen, es kommen also regelmäßig neue Funktionen dazu
• Sie finden niemanden, der sich in den Code einarbeiten will, oder neue Entwickler brauchen Monate, bis sie produktiv sind
• Login, Rechte, Formulare und Datenbankzugriffe sind selbst gebaut und damit auch die Sicherheitslücken darin
• Jedes Deployment ist Handarbeit und jeder zweite Fehler fällt erst beim Kunden auf

Warum Laravel und nicht Symfony? Beides ist eine solide Wahl. Laravel ist für viele mittelständische Anwendungen der schnellere Weg, weil es für die üblichen Aufgaben (Login, Mails, Warteschlangen, Datenbank) fertige Bausteine mitbringt und der Markt an Laravel-Entwicklern in Deutschland groß ist. Symfony spielt seine Stärken bei sehr großen, langlebigen Systemen und bei Teams aus, die schon damit arbeiten. Wie die Symfony-Variante aussieht, habe ich in Legacy-Code in eine Symfony-Anwendung integrieren beschrieben. Die Entscheidung sollte am Team und an der Anwendung hängen, nicht an der Vorliebe des Dienstleisters.

Kann das alte System weiterlaufen, während umgebaut wird?

Ja, und das sollte es auch. Die Alternative wäre, alles neu zu bauen und an einem Stichtag umzuschalten. Das klingt sauber und scheitert erstaunlich oft, die Gründe stehen in Warum Big-Bang-Neuentwicklungen so oft scheitern.

In der Praxis laufen beide Anwendungen eine Zeit lang nebeneinander auf demselben Server. Der Webserver entscheidet anhand der Adresse, wer eine Anfrage beantwortet: /konto geht schon an Laravel, alles andere noch an den alten Code. Ihre Kunden merken davon nichts. Mit jeder Etappe wandert ein weiterer Bereich zu Laravel, bis vom alten System nichts mehr übrig ist. Das Prinzip dahinter heißt Strangler Fig, ausführlich in Das Strangler-Fig-Pattern.

Zwei Stellen sind dabei schwierig, und ein Dienstleister sollte Ihnen ungefragt sagen, wie er sie löst:

• Der Login: Wer im alten Teil angemeldet ist, darf im neuen Teil nicht noch einmal nach dem Passwort gefragt werden. Dafür müssen beide Anwendungen dieselbe Sitzung kennen. Das ist lösbar, muss aber vor der ersten Etappe stehen und nicht mittendrin. Wie es um Passwörter und Anmeldung im Altsystem steht, ist oft ohnehin ein Thema, siehe Veraltete Authentifizierung sicher modernisieren.
• Die Datenbank: Beide Anwendungen arbeiten zunächst auf denselben Tabellen. Es muss für jede Tabelle feststehen, welche Seite schreibt. Zwei Systeme, die unkoordiniert dieselben Daten ändern, erzeugen Fehler, die erst Wochen später auffallen.

Wo fängt man an?

Nicht beim Herzstück. Wer mit Bestellabwicklung oder Zahlung beginnt, setzt gleich in der ersten Etappe den Umsatz aufs Spiel, und zwar zu einem Zeitpunkt, an dem das Team das System noch am wenigsten kennt.

Gute erste Kandidaten sind Bereiche mit klaren Grenzen und überschaubarem Risiko: ein internes Reporting, die Verwaltung von Stammdaten, ein Export. Dort lernt das Team die Eigenheiten der alten Anwendung kennen, und die gemeinsame Sitzung und Datenbank müssen sich bewähren, bevor es um Geld geht.

Vor jedem Umzug wird festgehalten, was der alte Code tatsächlich tut, und zwar in automatischen Tests. Das ist der wichtigste Schritt der ganzen Umstellung. In jeder gewachsenen Anwendung stecken Regeln, die nirgends dokumentiert sind: der Sonderrabatt für eine Kundengruppe, eine Rundung, die der Steuerberater so wollte, ein Feld, das bei bestimmten Bestellungen leer bleiben muss. Wer diese Regeln nicht vorher sichert, findet sie erst, wenn sie im neuen System fehlen. Wie man Tests in Code bekommt, der nie welche hatte, steht in Tests in Legacy-Code einführen, wo keine sind.

Nach jedem Umzug läuft der neue Bereich ein paar Tage unter Beobachtung, bevor der nächste drankommt. Geht etwas schief, wird die Adresse wieder auf den alten Code gelegt. Das dauert Minuten, solange der alte Code noch da ist.

Muss die Datenbank gleich mit umgebaut werden?

Nein. Das ist einer der häufigsten Fehler. Alte Datenbanken haben merkwürdige Tabellennamen, fehlende Fremdschlüssel und Datumsfelder, die als Text gespeichert sind. Der Impuls, das beim Umstieg gleich mit aufzuräumen, ist verständlich, verdoppelt aber das Risiko jeder Etappe.

Laravel kann mit den bestehenden Tabellen arbeiten, so wie sie sind. Aufgeräumt wird erst, wenn ein Bereich vollständig auf Laravel läuft und durch Tests abgesichert ist. Auch dann in kleinen Schritten: neue Spalte anlegen, Daten im Hintergrund übertragen, prüfen, alte Spalte später entfernen. Große Datenmengen in einem Rutsch umzuschreiben sperrt Tabellen und bedeutet Ausfallzeit. Mehr dazu in Datenbank-Migration ohne Datenverlust und Gewachsene Datenbank aufräumen.

Woran erkennen Sie ein belastbares Angebot?

Eine Umstellung auf Laravel ist ein Projekt über Monate, nicht über Wochen. Wer Ihnen etwas anderes verspricht, hat entweder sehr wenig Code gesehen oder plant einen Neubau mit Stichtag. Ein Angebot, das Sie ernst nehmen können, enthält:

• eine Bestandsaufnahme vor dem Angebot: welche Dateien der Webserver tatsächlich ausliefert, welche Cronjobs und Importskripte laufen, welche externen Dienste angebunden sind (Zahlung, Versand, Mail, Buchhaltung), wie die Anmeldung funktioniert
• eine Reihenfolge der Etappen mit Begründung, warum dieser Bereich zuerst kommt und jener zuletzt
• für jede Etappe ein eigenes Ergebnis, das Sie abnehmen können, und einen Preis dafür
• eine klare Aussage zu Login und Datenbank während der Übergangszeit
• Tests, die das Verhalten des alten Systems festhalten, bevor es ersetzt wird
• einen Rückweg für jede Etappe
• eine Aussage, wann das Altsystem abgeschaltet wird und wie lange der alte Code danach aufbewahrt wird (mindestens ein paar Monate, Sie werden ihn noch brauchen)

Vorsichtig wäre ich bei Angeboten, die "Neuentwicklung in Laravel" mit einem Livegang in drei Monaten versprechen, ohne dass jemand den alten Code gelesen hat. Ebenso bei Angeboten, die die gesamte Umstellung zu einem einzigen Pauschalpreis anbieten. Bei einer Anwendung, die keiner genau kennt, ist so ein Preis eine Wette, und das Risiko tragen am Ende Sie. Wie realistische Laufzeiten aussehen, steht in Wie lange dauert ein Modernisierungsprojekt?.

Was am Ende dabei herauskommt

Wenn die letzte Etappe umgezogen ist, zeigt der Webserver nur noch auf Laravel, der alte Code wird archiviert und der zweite PHP-Prozess abgeschaltet. Die Fachlogik, die über Jahre gewachsen ist, haben Sie behalten. Sie steckt jetzt in Code, den ein neuer Entwickler in Tagen versteht statt in Monaten, mit Tests, die beim nächsten Umbau Alarm schlagen.

Ob sich die Umstellung bei Ihnen lohnt und in wie vielen Etappen sie machbar ist, lässt sich nach einem Blick in Code und Datenbank ziemlich genau sagen. Vorher ist jede Zahl geschätzt.