Legacy-PHP-Projekt übernehmen: Was Agenturen und Freelancer wissen müssen
Die Anfrage klingt harmlos. Ein Kunde hat eine PHP-Anwendung, die seit Jahren läuft. Der bisherige Entwickler ist nicht mehr erreichbar. Ein paar Kleinigkeiten sollen angepasst werden, mehr nicht.
Wer schon einmal ein Legacy-PHP-Projekt übernehmen musste, kennt den zweiten Teil der Geschichte. Aus „ein paar Kleinigkeiten" werden drei Wochen Fehlersuche. Aus einem Festpreis wird ein Verlustgeschäft.
Das liegt selten am Kunden. Es liegt am Einstieg. Wer ohne Prüfung zusagt, kalkuliert gegen Unbekanntes.
Dieser Artikel zeigt, wie Agenturen und Freelancer ein fremdes PHP-System strukturiert übernehmen. Ohne Drama, ohne blinde Flecken.
Warum die Übernahme anders läuft als ein Neubau
Bei einem Neubau kennen Sie jede Entscheidung. Sie haben die Struktur gewählt. Sie wissen, warum eine Datei so heißt, wie sie heißt.
Bei einer Übernahme ist das umgekehrt. Sie erben Entscheidungen aus zehn oder fünfzehn Jahren. Manche davon waren damals richtig. Andere waren ein Kompromiss unter Zeitdruck.
Genau diese Kompromisse nennt man technische Schulden. Sie sind nicht sichtbar, solange die Anwendung läuft. Sie werden sichtbar, sobald Sie etwas ändern.
Wichtig dabei: Alter Code ist kein Beweis für schlechte Arbeit. Eine Anwendung, die seit 2011 Umsatz erwirtschaftet, hat ihren Zweck erfüllt. Respekt vor dieser Leistung gehört zum Handwerk.
Was passiert, wenn Sie ungeprüft zusagen
Der Schaden entsteht nicht am ersten Tag. Er entsteht in Woche drei.
Sie kalkulieren gegen eine Blackbox
Ohne Analyse schätzen Sie den Aufwand nach Gefühl. Bei Legacy Software liegt dieses Gefühl fast immer zu niedrig.
Ein Beispiel aus der Praxis: Eine Änderung am Bestellformular betrifft vier Dateien. In einem gewachsenen System betrifft sie zwölf. Drei davon finden Sie erst, wenn etwas kaputtgeht.
Sie erben offene Sicherheitslücken
Läuft das System auf PHP 5.6 oder 7.2, gibt es keine Sicherheits-Updates mehr. Die Version hat ihr End of Life erreicht.
Ab dem Moment Ihrer Übernahme erwartet der Kunde, dass Sie sich darum kümmern. Auch wenn niemand darüber gesprochen hat.
Sie gelten als verantwortlich für alte Fehler
Fällt zwei Monate nach der Übernahme ein Zahlungsmodul aus, zeigt niemand auf den Entwickler von 2014. Alle schauen auf Sie.
Deshalb ist die schriftliche Bestandsaufnahme kein Papierkram. Sie ist Ihr Schutz.
Der Einstieg in fünf Schritten
Diese Reihenfolge hat sich bewährt. Sie kostet zwei bis fünf Tage. Sie spart oft Wochen.
Schritt 1: Zugänge vollständig klären
Bevor Sie eine Zeile Code lesen, klären Sie den Zugriff. Server, Datenbank, Domain-Verwaltung, E-Mail-Versand, Zahlungsdienstleister, Repository.
Fehlt ein Zugang, notieren Sie das sofort. Ein fehlendes Server-Passwort ist im Notfall ein Totalausfall.
Fragen Sie außerdem: Wer gibt Änderungen frei? Wer wird bei einer Störung informiert?
Schritt 2: Code-Analyse statt Bauchgefühl
Verschaffen Sie sich einen messbaren Überblick. Wie viele Zeilen? Welche PHP-Version? Gibt es Composer, den Verwalter für externe Programmbibliotheken?
Nützlich sind statische Analysewerkzeuge. PHPStan oder Psalm zeigen problematische Stellen, ohne den Code auszuführen. Rector zeigt, welche Stellen ein Versionssprung betrifft.
Suchen Sie gezielt nach den üblichen Risikostellen. Datenbankabfragen ohne Absicherung. Passwörter im Quelltext. Eigene Verschlüsselung statt geprüfter Standards.
Schritt 3: Testabdeckung ehrlich bewerten
Prüfen Sie, ob automatisierte Tests existieren. Solche Tests kontrollieren selbstständig, ob Funktionen nach einer Änderung noch arbeiten.
In vielen Altprojekten finden Sie keine. Das ist normal und kein Ausschlusskriterium.
Es ändert aber Ihre Arbeitsweise. Ohne Tests brauchen Sie mehr manuelle Prüfung. Sie brauchen außerdem eine Testumgebung, die der Produktion ähnelt. Kalkulieren Sie diesen Aufwand ein.
Schritt 4: Infrastruktur verstehen
Der Code ist nur die Hälfte. Die andere Hälfte ist der Server.
Klären Sie: Welche PHP-Version läuft wirklich? Welche Erweiterungen sind aktiv? Wie laufen zeitgesteuerte Aufgaben? Wohin gehen die Logdateien?
Und die wichtigste Frage: Gibt es ein funktionierendes Backup? Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung.
Wie eine solche Bestandsaufnahme im Detail abläuft, zeigt unser Artikel zum Software-Audit vor der Übernahme.
Schritt 5: Risiken schriftlich kommunizieren
Fassen Sie Ihre Funde auf zwei Seiten zusammen. Nicht technisch, sondern verständlich.
Drei Kategorien reichen: sofort kritisch, mittelfristig zu lösen, langfristig sinnvoll. Zu jedem Punkt eine Aufwandsschätzung.
Der Kunde entscheidet dann selbst. Sie haben Ihre Einschätzung dokumentiert. Das schafft Vertrauen und schützt beide Seiten.
Die ersten 30 Tage in der Praxis
Woche 1 gehört der Analyse und den Zugängen. Sie ändern noch nichts.
Woche 2 gehört der Absicherung. Backup einrichten und einmal zurückspielen. Versionskontrolle einführen, falls sie fehlt. Eine einfache Überwachung aufsetzen, die meldet, wenn die Seite ausfällt.
Woche 3 gehört einem kleinen, sichtbaren Erfolg. Nehmen Sie einen echten Fehler, den der Kunde kennt. Damit zeigen Sie, dass Sie das System beherrschen.
Woche 4 gehört der Dokumentation und dem Plan. Halten Sie fest, was Sie gelernt haben. Hinweise dazu gibt unser Beitrag zur Dokumentation für Legacy-Software.
Wie das an einem echten System aussieht, beschreibt unsere Case Study zu einem PHP-System aus 2008.
Welches Preismodell zur Übernahme passt
Ein Festpreis setzt voraus, dass beide Seiten den Umfang kennen. Bei einem Altsystem kennt ihn am Anfang niemand.
Bewährt hat sich ein zweistufiges Vorgehen. Stufe eins ist die Analyse zum Festpreis. Der Umfang ist klar begrenzt, das Ergebnis ist ein schriftlicher Bericht.
Stufe zwei ist die eigentliche Arbeit. Erst hier lässt sich seriös schätzen, weil Sie das System kennen.
Für die laufende Betreuung eignet sich ein monatliches Kontingent. Es deckt Updates, Überwachung und kleine Anpassungen ab. Der Kunde bekommt Planbarkeit, Sie bekommen Kontinuität.
Halten Sie außerdem fest, was nicht enthalten ist. Neue Funktionen, Datenmigrationen und Notfälle außerhalb der Geschäftszeiten gehören separat geregelt.
Wer diese Punkte vor dem ersten Arbeitstag klärt, diskutiert später nicht über Rechnungen. Er diskutiert über Lösungen.
Wann Sie ein Projekt besser ablehnen
Nicht jede Übernahme ist sinnvoll. Drei Warnsignale sprechen dagegen.
Der Kunde verweigert die Analysephase und will sofort einen Festpreis. Dann tragen Sie das gesamte Risiko allein.
Es gibt keinen Zugriff auf Server und Datenbank, sondern nur einen Ordner per FTP. Dann können Sie im Ernstfall nicht helfen.
Der Kunde erwartet, dass Sie zehn Jahre Rückstand in vier Wochen aufholen. Diese Erwartung korrigiert nur ein ehrliches Gespräch.
Umgekehrt gilt: Wenn Sie selbst jemanden suchen, helfen die Auswahlkriterien für PHP-Freelancer bei Legacy-Projekten.
Fazit: Prüfen kommt vor Programmieren
Ein Legacy-PHP-Projekt übernehmen ist Handwerk, kein Glücksspiel. Der Unterschied liegt im Einstieg.
Wer Zugänge klärt, den Code analysiert, die Infrastruktur versteht und Risiken schriftlich festhält, arbeitet planbar. Wer sofort loslegt, arbeitet auf Verdacht.
Ein sauberer Start dauert wenige Tage. Ein schlechter Start kostet Monate.
Sie stehen vor einer Übernahme und wollen vorher wissen, was auf Sie zukommt? Wir übernehmen die Bestandsaufnahme oder begleiten Sie dabei. Mehr dazu auf unserer Seite zur System-Analyse und zur laufenden Software-Wartung.
Sprechen Sie uns an. Das Erstgespräch ist kostenlos.
