Legacy-Systeme verstehen

Warum das eigentliche Problem oft nicht im System liegt

Nachdem im ersten Artikel Altbetrieb heißt nicht Stillstand klar wurde, dass der Altbetrieb kein Nebenkriegsschauplatz ist, sondern das eigentliche Risiko trägt, kommt die nächste unbequeme Frage: Was passiert in diesem System eigentlich genau?

Die ehrliche Antwort ist in vielen Fällen: Niemand weiß es so genau.

Nicht, weil sich niemand damit beschäftigt hätte, sondern weil sich das System über Jahre hinweg verändert hat – ohne dass dieses Wissen strukturiert festgehalten wurde.

Das eigentliche Problem: fehlendes Verständnis, nicht fehlende Technik

Die Bewertung „Legacy = veraltet“ greift in der Praxis zu kurz. Die meisten dieser Systeme laufen seit vielen Jahren stabil. Sie sind nicht deshalb schwierig, weil sie technisch „falsch“ sind, sondern weil sie nicht (mehr) vollständig nachvollziehbar sind.

Was fehlt, ist daher zunächst keine neue Architektur, sondern ein klares Bild davon:

Und genau dieses Bild lässt sich oft nicht allein aus dem Code ableiten.

Gewachsene Systeme haben keine zentrale Wahrheit

Ein wesentlicher Unterschied zu modernen Systemen ist, dass es keine zentrale Stelle gibt, an der man „nachschauen“ könnte. Stattdessen verteilt sich die Logik auf:

Gerade Hintergrundprozesse werden dabei oft übersehen: Cronjobs, die regelmäßig Daten exportieren, Preise synchronisieren oder externe Kanäle wie Marktplätze und Vergleichsportale bedienen. Sie laufen zuverlässig im Hintergrund, oft ohne dass man sie bei dem Versuch die Funktionsweise des Systems zu verstehen, sofort bemerkt.

Auch auf Infrastrukturebene steckt häufig relevante Logik: Weiterleitungen, Rewrite-Regeln oder spezielle VHost-Konfigurationen, die über Jahre ergänzt wurden. Sie beeinflussen das Verhalten des Shops, ohne im eigentlichen Anwendungscode sichtbar zu sein.

Nicht selten liegt ein Teil der Geschäftslogik damit außerhalb des Shops selbst.

Überlagerte Logik statt klarer Struktur

Über die Jahre entsteht zudem ein typisches Muster: Neue Anforderungen werden ergänzt, bestehende Logik wird nicht oder nicht vollständig entfernt. Je älter das System ist, oft auch nicht aus Nachlässigkeit, sondern aus Vorsicht. Niemand möchte riskieren, durch eine lokale Änderung die Funktionsweise des gesamten Systems zu beschädigen. Die alte IT-Weisheit: “Never touch a running system” lässt grüßen.

Also bleibt alte Logik bestehen – und neue kommt oben drauf.

Das führt dazu, dass mehrere Logikschichten gleichzeitig aktiv sind:

Was von außen wie ein Fehler wirkt, ist oft das Zusammenspiel mehrerer Regeln aus unterschiedlichen Jahren. Alte Logik verschwindet selten. Sie wird nur unsichtbar – oder bleibt als vermeintlich „auskommentierter“ Rest bestehen.

Warum der Code allein nicht reicht

Ein häufiger erster Ansatz ist: „Dann schauen wir uns eben den Code an.“ Der Code zeigt allerdings bei Legacy-Systemen nur einen Teil der Realität.

Ein großer Teil der tatsächlichen Logik liegt außerhalb:

Dieses Zusammenspiel ist nicht immer auf den ersten Blick zu verstehen.

Wie man ein solches System tatsächlich versteht

Ein gewachsenes System lässt sich nicht linear „durchlesen“ – in der Praxis nähert man sich dem System von mehreren Seiten gleichzeitig.

Einstieg über reale Abläufe

Der erste Schritt ist: verstehen, was im Alltag passiert.

Es geht darum zu erkennen, wo überhaupt relevante Logik stattfindet.

Datenflüsse nachvollziehen

Darauf aufbauend wird untersucht:

Dabei gehören auch zeitgesteuerte Prozesse zwingend dazu:

Diese Prozesse sind oft nicht direkt sichtbar, greifen aber tief in die Systemlogik ein.
Wer sie nicht kennt, versteht das System nicht vollständig.

Sonderlogik freilegen

Besonders relevant sind die Stellen, an denen das System vom Standard abweicht:

Genau dort liegt in der Regel die geschäftskritische Logik. Und genau dort ist sie oft historisch am stärksten gewachsen und gleichzeitig am wenigsten dokumentiert.

Realität gegen Code prüfen

Ein zentraler Schritt besteht darin, nicht nur den Code zu betrachten, sondern das tatsächliche Verhalten des Systems zu überprüfen:

Der Code sagt, was passieren soll – das System zeigt, was tatsächlich passiert.

Implizites Wissen einbeziehen

Ein oft unterschätzter Faktor ist das Wissen der Personen, die täglich mit dem System arbeiten.

Typische Aussagen wie:

weisen häufig direkt auf kritische Logik hin, die im Code selbst nicht offensichtlich ist.

Der fehlende Baustein: strukturierte Dokumentation

Ein zentraler Punkt wird in diesem Zusammenhang fast immer sichtbar: Das System ist nicht dokumentiert. Oder zumindest nicht so, dass es direkt nutzbar wäre.

Dabei ist genau das der entscheidende Schritt:

Erst durch eine strukturierte Dokumentation entsteht ein gemeinsames Verständnis.

Und erst dieses Verständnis ermöglicht:

Ohne diese Grundlage bleibt jede Änderung ein Risiko.

Warum das nicht „mal eben“ geht

An diesem Punkt wird meist klar, warum solche Systeme schwer greifbar sind: Die relevanten Informationen liegen nicht zentral vor, sondern sie müssen zusammengetragen, überprüft und eingeordnet werden.

Und jede Annahme muss gegen die Realität getestet werden, weil Fehler unmittelbare Auswirkungen haben.

In der Praxis bedeutet das: mehrere Tage strukturierte Analyse, Tests und Abstimmung, bevor belastbare Aussagen möglich sind.

Nicht, weil das System unnötig kompliziert ist, sondern weil seine Logik über Jahre gewachsen ist – und nie vollständig zusammengeführt wurde.

Warum Rewrites daran oft scheitern

Wenn ein System ersetzt wird, wird in der Regel das Sichtbare übernommen:

Was verloren geht, sind genau die Dinge, die vorher schon nicht klar dokumentiert waren:

Der neue Shop ist dann zwar technisch modern – aber in entscheidenden Punkten unvollständig. Der Rewrite ersetzt den Code, aber nicht das Verständnis.

Fazit: Verstehen vor Verändern

Gewachsene Systeme sind selten elegant, aber oft erstaunlich robust. Nicht, weil sie perfekt sind, sondern weil sie über Jahre an reale Anforderungen angepasst wurden.

Das eigentliche Risiko liegt deshalb nicht im System selbst, sondern im fehlenden Verständnis darüber.

Wer hier ansetzt, schafft die Grundlage für alles Weitere:

Und genau dieser Schritt entscheidet darüber, ob ein System zum Problem wird – oder zur stabilen Basis.

In vielen Projekten wird dieser Schritt übersprungen. Die Folgen zeigen sich dann erst später.