PHP-Altprojekt — modernisieren, ohne den Betrieb zu stoppen.

Die typische Situation.

• Läuft auf alter PHP-Version — der Wechsel wurde immer verschoben (PHP-Versionen).
• Der ursprüngliche Entwickler ist nicht mehr erreichbar.
• Keine Tests, wenig Dokumentation.
• Code direkt auf dem Server bearbeitet, ohne Versionsverwaltung.
• HTML, Datenbankabfragen und Logik in denselben Dateien.
• Jede Änderung hat unerwartete Nebenwirkungen.

Das ist kein Vorwurf an den ursprünglichen Entwickler. So sah PHP-Entwicklung lange aus, und die Anwendung hat jahrelang ihren Zweck erfüllt. Die Frage ist nur, wie es weitergeht.

Die Falle Neubau.

Ein Neubau klingt verlockend: sauberer Code, moderne Technik, keine Altlasten. In der Praxis unterschätzt er fast immer eines: das Wissen, das in der alten Anwendung steckt.

Jede merkwürdige Bedingung im alten Code hat einmal einen Grund gehabt — ein Sonderfall bei einem Kunden, eine Steuerregel, ein Fehler, der behoben werden musste. Beim Neubau gehen diese Fälle verloren, und sie tauchen erst im Betrieb wieder auf.

Dazu kommt: Während des Neubaus muss die alte Anwendung weiterlaufen und gepflegt werden. Neubauprojekte dauern meist länger als geplant, und solange laufen zwei Systeme.

Bestandsaufnahme.

1. Was tut die Anwendung? Funktionen und Abläufe aus Sicht der Nutzer.
2. Wie ist sie gebaut? Struktur, Framework, Abhängigkeiten.
3. Wo liegen die Risiken? Sicherheitslücken, veraltete Teile (Sicherheit).
4. Was wird wirklich genutzt? Oft ist ein Teil der Funktionen tot.
5. Was soll sich ändern? Neue Anforderungen, die anstehen.

Punkt vier ist ein unterschätzter Hebel: Funktionen, die niemand nutzt, müssen nicht modernisiert werden. Sie werden entfernt.

Das Sicherheitsnetz.

Bevor irgendetwas umgebaut wird, braucht es drei Dinge:

• Versionsverwaltung: Jede Änderung nachvollziehbar und umkehrbar.
• Testumgebung: Eine Kopie der Anwendung, in der man gefahrlos arbeiten kann.
• Erste Tests: Für die wichtigsten Abläufe, die das heutige Verhalten festhalten.

Die Tests sind dabei keine Prüfung, ob der Code richtig ist — sondern ob er sich nach dem Umbau genauso verhält wie vorher. Auch Fehler im alten Verhalten werden zunächst festgehalten; ob sie behoben werden, ist eine bewusste Entscheidung.

Ordnung schaffen.

Die ersten Schritte sind unspektakulär und bringen viel: Abhängigkeitsverwaltung einführen, Zugangsdaten aus dem Code in eine Konfigurationsdatei verschieben, einheitliche Formatierung, offensichtlich toten Code entfernen.

Danach die PHP-Version anheben — mit dem Sicherheitsnetz ist das deutlich weniger riskant (PHP 7 auf 8).

Schrittweiser Umbau.

Der eigentliche Umbau passiert Teil für Teil: Datenbankabfragen in eigene Klassen auslagern, Logik von Darstellung trennen, wiederholten Code zusammenfassen, Eingaben konsequent prüfen.

Ein bewährtes Muster: Neue Funktionen werden gleich sauber gebaut. Alte Teile werden umgebaut, wenn sie ohnehin angefasst werden müssen. So wächst der moderne Teil, und der alte schrumpft — ohne großes Umbauprojekt.

Wichtig ist, dass die Anwendung nach jedem Schritt lauffähig ist und live gehen kann. Keine monatelangen Umbauzweige, die am Ende niemand mehr zusammenführen kann.

Ein Framework einführen.

Viele alte Anwendungen haben kein Framework. Eine Möglichkeit ist, eines schrittweise einzuführen: Neue Teile laufen im Framework, alte Teile werden über eine Brücke weiter ausgeliefert, bis sie umgezogen sind.

Laravel eignet sich dafür gut, weil es sich auch neben bestehendem Code betreiben lässt und viele Aufgaben — Anmeldung, Datenbank, Formulare, Warteschlangen — sauber gelöst mitbringt (Laravel).

Das ist ein größerer Schritt und lohnt sich, wenn die Anwendung weiter wachsen soll. Für eine Anwendung, die nur noch stabil laufen muss, reicht oft die Modernisierung ohne Framework.

Die Datenbank.

Alte Anwendungen haben oft eine Datenbank, die über Jahre gewachsen ist: uneinheitliche Namen, fehlende Schlüssel, Daten in Textfeldern, die eigentlich eigene Tabellen bräuchten.

Die Datenbank umzubauen ist riskanter als den Code, weil Daten betroffen sind. Hier gilt erst recht: schrittweise, mit Sicherung, mit Migrationsskripten, die sich wiederholen lassen. Und erst, wenn der Code darauf vorbereitet ist.

Wann neu bauen besser ist.

• Die Anwendung ist klein und ihr Verhalten gut beschrieben.
• Der Zweck hat sich grundlegend geändert.
• Ein Standardprodukt erfüllt die Anforderungen inzwischen (Individuell oder Standard).
• Die Grundlage ist nicht tragfähig — etwa eine Technik, für die es keine Entwickler mehr gibt.

Auch dann gilt: Die alte Anwendung ist die beste Anforderungsbeschreibung, die es gibt. Vor dem Neubau gehört sie gründlich gelesen.

Kosten und Planung.

Modernisierung lässt sich gut in Abschnitte teilen: Bestandsaufnahme, Sicherheitsnetz, PHP-Version, Umbau. Jeder Abschnitt hat einen eigenen Nutzen, und man kann nach jedem entscheiden, ob es weitergeht.

Ich nenne hier keine Pauschalbeträge, weil der Aufwand vollständig vom Zustand der Anwendung abhängt. Nach der Bestandsaufnahme lässt er sich realistisch schätzen.

Wenn du nicht weiterkommst.

Wenn bei dir eine gewachsene PHP-Anwendung läuft, die niemand mehr anfassen will. Ich sehe mir den Code an, sage dir, wo die Risiken liegen, und setze um, was nötig ist. Die Übersicht findest du unter PHP und Laravel; wenn es eilt, hilft der Notfall-Support.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. PHP ist die Sprache, in der ich seit Jahren am meisten Code schreibe — in WordPress-Plugins, Shop-Erweiterungen, Schnittstellen und eigenständigen Anwendungen mit Laravel. Ich unterrichte Webentwicklung als Dozent und kenne PHP vom alten prozeduralen Skript bis zur modernen, typisierten Anwendung mit Tests.

Gerade bei bestehenden Anwendungen zählt das: Ich lese fremden Code schnell, erkenne, wo er gegen die Sprache arbeitet, und sehe, was sich mit vertretbarem Aufwand retten lässt. Viele PHP-Projekte, die als hoffnungslos gelten, sind es nicht — sie wurden nur lange nicht gepflegt.

Was du bekommst: eine ehrliche Einschätzung, ob sich modernisieren oder neu bauen lohnt, sauberen Code, den auch andere Entwickler verstehen, und eine Dokumentation — auch wenn die Antwort lautet, dass die Anwendung so bleiben kann.