Legacy-PHP-Projekt übernehmen lassen: Der Risiko-Check vor der Beauftragung

Ein Projektwechsel, der selten an der Technik scheitert

Wenn ein bestehendes PHP-System den Dienstleister wechselt, ist die erste Frage meist die falsche: "Ist der Code gut oder schlecht?" Die Frage, die tatsächlich über den weiteren Projektverlauf entscheidet, lautet anders: Was wissen Sie über den Zustand, bevor Sie unterschreiben, und was nicht?

Aus eigener Erfahrung mit Projektübernahmen zeigt sich ein wiederkehrendes Muster. Die technischen Probleme selbst sind fast immer lösbar. Was ein Projekt teuer macht, ist die Lücke zwischen dem, was der bisherige Betreiber über das System zu wissen glaubt, und dem, was tatsächlich zutrifft. Dieser Artikel zeigt, wie sich dieses Risiko vor der Beauftragung einschätzen lässt.

Die Ausgangslage: Welche Entscheidung ansteht

Vor der Übernahme eines fremden PHP-Systems steht meist eine von zwei Situationen. Entweder der bisherige Dienstleister ist nicht mehr verfügbar, etwa durch Geschäftsaufgabe oder Kündigung des Vertragsverhältnisses. Oder die Zusammenarbeit soll aus fachlichen Gründen wechseln, weil das System an seine Grenzen stößt oder die bisherige Betreuung nicht mehr passt.

In beiden Fällen ist die Ausgangslage ähnlich unklar. Die Dokumentation ist selten vollständig, und selbst wo sie existiert, weicht sie in der Praxis regelmäßig vom tatsächlichen Systemverhalten ab. Wer an dieser Stelle direkt in die Umsetzung startet, ohne den Zustand vorher strukturiert zu erfassen, verlagert das Risiko lediglich auf den Projektverlauf, statt es vorab zu klären.

Optionen mit Vor- und Nachteilen

Grundsätzlich gibt es drei Wege, wie eine Übernahme starten kann.

Direkter Start ohne vorgelagerte Prüfung. Der neue Dienstleister beginnt sofort mit den ersten Aufgaben, die Systemkenntnis entsteht nebenbei. Das spart Zeit zu Beginn, verlagert die Risikoerkennung aber in die laufende Arbeit. Probleme wie fehlende Tests oder verwobene Business-Logik zeigen sich dann erst, wenn sie bereits Zeit kosten.

Vollständige Neuentwicklung statt Übernahme. Statt das bestehende System zu übernehmen, wird es ersetzt. Das eliminiert das Legacy-Risiko vollständig, bringt aber ein neues Risiko mit: den Verlust von Business-Logik, die nirgendwo dokumentiert ist, sondern nur im laufenden System steckt. Für kleinere Systeme mit überschaubarem Funktionsumfang kann das dennoch die wirtschaftlichere Option sein.

Strukturiertes Code-Audit vor Vertragsabschluss. Der Zustand des Systems wird vor der eigentlichen Beauftragung erfasst: Testabdeckung, PHP-Version, Architektur, kritische Abhängigkeiten. Das kostet Zeit vorab, macht das anschließende Risiko aber kalkulierbar, weil Entscheidungen auf Basis des tatsächlichen Zustands getroffen werden statt auf Basis der vorhandenen Dokumentation.

Entscheidungskriterien: Woran Sie die richtige Option erkennen

Vier Kriterien geben eine erste Orientierung, welche Option zur eigenen Situation passt.

Testabdeckung. Existieren automatisierte Tests, die Änderungen absichern? Ohne sie wird jede Anpassung zum Risiko, weil sich Nebenwirkungen erst im Betrieb zeigen. Ein Audit sollte diese Frage vor Vertragsabschluss beantworten, nicht erst danach.

PHP-Version und Architektur. Läuft das System auf einer Version unter 8.2, ist bereits absehbar, dass ein Upgrade ansteht, unabhängig davon, welcher Dienstleister übernimmt. Ein Monolith mit stark verwobenen Modulen macht punktuelle Änderungen riskanter als eine sauber getrennte Architektur.

Verfügbares Wissen. Gibt es eine Person, die das System versteht und für Rückfragen erreichbar ist, oder ist dieses Wissen bereits verloren? Letzteres verlängert die Einarbeitungszeit erheblich, weil Business-Logik dann nur noch aus dem Code selbst rekonstruierbar ist.

Zeithorizont. Soll das System die nächsten Monate überbrücken oder mehrere Jahre tragen? Bei kurzem Zeithorizont kann ein pragmatischerer Ansatz wirtschaftlicher sein als ein vollständiges Audit.

Aus der Praxis

Was mir bei Übernahmen wiederholt begegnet:

Bei Legacy-Übernahmen zeigt sich regelmäßig, dass die eigentliche Arbeit weniger im Schreiben neuen Codes liegt als im Lesen und Verstehen des bestehenden. Das deckt sich mit einer verbreiteten Faustregel unter Entwicklern, die in Altsystemen arbeiten: Ein deutlich größerer Anteil der Zeit fließt in Code-Recherche und Nachvollziehen bestehender Logik als in neue Implementierung. Eine belastbare Prozentzahl dafür gibt es nicht, die Beobachtung selbst deckt sich aber mit dem, was ich in eigenen Projekten wiederholt sehe.

Erste sichtbare Ergebnisse eines Code-Audits, etwa Quick Wins oder erste Sicherheitsverbesserungen, zeigen sich in der Praxis oft innerhalb weniger Wochen. Eine vollständige Modernisierung des Systems ist damit nicht erledigt, dafür braucht es je nach Umfang deutlich längere Zeiträume.

Genau dieses Verhältnis zwischen schnellem ersten Befund und langfristiger Modernisierung ist der Grund, warum sich ein Audit vor der Beauftragung lohnt: Es trennt beides sauber voneinander, statt beides in einer Erwartung zu vermischen.

Dennis Schwenker-Sanders ist PHP- und Symfony-Entwickler mit Fokus auf die Übernahme und Modernisierung von Legacy-Systemen für Agenturen und KMU im DACH-Raum. Für die Kapazitätsfrage bei Übernahmeprojekten siehe auch php-freelancer/.