Es gibt einen Moment, den fast jedes Legacy-Projekt kennt: Eine Fachabteilung fragt, warum eine Rechnung anders berechnet wird als erwartet. Man schaut in den Code. Dort steht eine Bedingung wie if ($kunde->typ === 3 && $datum < '2019-04-01') — ohne Kommentar, ohne Ticket, ohne Erklärung. Niemand weiß mehr, warum. Der Kollege, der es wusste, ist seit zwei Jahren in Rente. Und trotzdem läuft genau diese Zeile jeden Tag korrekt durch, weil sie eine reale Anforderung abbildet, die irgendwann einmal wichtig war.
Genau hier liegt der eigentliche Wert eines alten Systems. Der Code ist ersetzbar. Das Wissen darüber, was das System tut und warum, ist es nicht. Wer Legacy Wissen sichern will, muss zuerst verstehen, dass das teure Gut nicht die 200.000 Zeilen PHP sind, sondern die tausenden fachlichen Entscheidungen, die darin eingefroren wurden.
Warum ein laufendes System Ihr bestes Dokument ist
Ein System, das seit acht oder zehn Jahren im Produktivbetrieb läuft, ist kein Beweis für Nachlässigkeit. Es ist der Beweis, dass die Fachlogik funktioniert. Jeder Sonderfall, der jemals aufgetreten ist, wurde irgendwann eingebaut. Jede Ausnahme, die ein Kunde gemeldet hat, hat eine Codezeile hinterlassen. Das ist gelebte Anforderungsanalyse — nur eben nicht in einem Lastenheft, sondern im Quelltext.
Deshalb ist die Neuentwicklung auf der grünen Wiese fast immer die teuerste und riskanteste Option. Sie werfen nicht schlechten Code weg, sondern Jahre validierter Fachlogik. Und Sie werden alle Sonderfälle erneut entdecken — diesmal aber im Produktivbetrieb, mit echten Kunden, die sich beschweren. Das Problem am Legacy-System ist selten die Fachlogik. Es ist der Code drumherum: die Kopplung, die fehlenden Tests, das veraltete Framework. Diese Hülle lässt sich austauschen. Das Wissen im Kern müssen Sie retten.
Legacy Wissen sichern beginnt mit den richtigen Fragen
Bevor Sie eine einzige Zeile anfassen, sollten Sie das System systematisch befragen — die Menschen und den Code. Setzen Sie sich mit den Fachanwendern zusammen, nicht mit einer Wunschliste, sondern mit konkreten Bildschirmmasken. Fragen Sie: Was passiert, wenn Sie hier klicken? Was darf hier nie passieren? Welchen Fall behandeln Sie manuell, weil das System ihn nicht kann?
Parallel dazu lassen Sie den Code sprechen. Interessant sind vor allem die unscheinbaren Stellen:
- Magische Zahlen und Statuscodes wie
status = 7— hinter jeder steckt eine fachliche Bedeutung, die dokumentiert werden muss. - Auskommentierte Blöcke mit Datumsangaben — sie erzählen oft, wann sich eine Regel geändert hat und warum.
- Cron-Jobs und geplante Skripte — hier stecken Prozesse, die niemand mehr im Blick hat, die aber Geschäftskritisches tun.
- SQL-Abfragen mit seltsamen Filtern — sie kodieren Geschäftsregeln, die im Formular nie sichtbar sind.
Charakterisierungstests: das Wissen einfrieren, bevor Sie umbauen
Der wirksamste technische Schritt, um Domänenwissen zu sichern, sind sogenannte Charakterisierungstests (characterization tests). Der Gedanke ist bewusst bescheiden: Sie schreiben keine Tests, die prüfen, ob das System richtig rechnet. Sie schreiben Tests, die festhalten, was das System aktuell tut — richtig oder falsch.
In der Praxis heißt das: Sie nehmen eine zentrale Berechnungsklasse, füttern sie mit realen Eingabedaten und schreiben das aktuelle Ergebnis als erwarteten Wert in den Test. Mit PHPUnit sieht das im Kern so aus, dass Sie über einen Datensatz echter Fälle iterieren und Ist gegen zuvor festgehaltenes Ist prüfen. Ab diesem Moment ist das Verhalten dokumentiert und geschützt. Wenn Sie jetzt refaktorieren, das Framework aktualisieren oder von einem alten Symfony- auf ein aktuelles migrieren, meldet der Test sofort, sobald sich das Verhalten ändert. Das eingefrorene Fachwissen wird zum Sicherheitsnetz.
Ein pragmatischer Weg, an reale Eingabedaten zu kommen: Loggen Sie in der Produktion (anonymisiert und DSGVO-konform) Ein- und Ausgaben der kritischen Funktion mit, und leiten Sie daraus Ihre Testfälle ab. So testen Sie gegen echte Fälle, nicht gegen Ihre Annahmen darüber, was echte Fälle sind.
Wissen dorthin schreiben, wo es gelesen wird
Ein häufiger Fehler: Das gerettete Wissen landet in einem 80-seitigen Word-Dokument, das niemand öffnet. Wissen überlebt dort, wo Entwickler ohnehin hinschauen. Schreiben Sie deshalb bevorzugt in den Code selbst — als aussagekräftigen Kommentar direkt an der magischen Zahl („Typ 3 = Bestandskunden aus der Übernahme 2015, andere Steuerlogik"), als sprechenden Methodennamen, als benannte Konstante statt einer nackten 7.
Für Zusammenhänge, die über eine einzelne Zeile hinausgehen, haben sich zwei Formate bewährt: kurze Architecture Decision Records (ADRs) im Repository für die großen Weichenstellungen, und eine schlanke fachliche Glossardatei, die Domänenbegriffe definiert. Beides liegt im Git-Repo, wird mitversioniert und altert nicht in einem vergessenen Wiki.
Die Reihenfolge entscheidet über den Erfolg
Der teure Fehler ist, mit dem Umbau zu beginnen, bevor das Wissen gesichert ist. Wer erst refaktoriert und dabei stillschweigend einen Sonderfall entfernt, den keiner mehr verstand, bemerkt den Schaden oft erst Wochen später — beim falsch berechneten Monatsabschluss. Die richtige Reihenfolge ist unspektakulär, aber robust: erst befragen und dokumentieren, dann mit Charakterisierungstests absichern, dann erst modernisieren.
Sie modernisieren nicht Code. Sie modernisieren die Verpackung um ein Fachwissen, das sich über Jahre bewährt hat — und dieses Fachwissen dürfen Sie unterwegs nicht verlieren.
Ein ehrlicher Praxis-Tipp zum Schluss
Fangen Sie klein an. Suchen Sie sich die eine Funktion, bei der Ihnen am meisten Angst wäre, wenn niemand mehr wüsste, wie sie funktioniert — die Rechnungsberechnung, die Provisionslogik, die Vertragsverlängerung. Sichern Sie genau die zuerst mit ein paar Charakterisierungstests und einem halben Tag Gespräch mit der Fachabteilung. Sie werden überrascht sein, wie viel Wissen an einer einzigen Stelle hängt — und wie ruhig Sie danach schlafen. Genau bei dieser Arbeit, dem Sichern von Domänenwissen vor der Modernisierung, unterstützt LegacyWerk, wenn die Kollegen fehlen, die das System noch im Kopf haben.
