Field Note: Wann ich aufhöre, ein bestehendes System zu retten

Ich setze die Grenze später, als manche erwarten

Ich baue bestehende Systeme ungern neu. Nicht, weil ich glaube, dass man jedes technische Erbe retten kann. Sondern weil ein gewachsenes System oft mehr enthält als den Code, den man gerade sieht: redaktionelle Abläufe, Datenbeziehungen, Sonderfälle und Entscheidungen, die nie sauber dokumentiert wurden. Wer zu früh neu baut, kann diese Zusammenhänge versehentlich mit entsorgen.

Mein erster Impuls ist deshalb meist nicht: Was wäre die sauberste Architektur? Sondern: Was tut das System tatsächlich, wer verlässt sich darauf, und was davon muss erhalten bleiben? Erst wenn ich das besser verstehe, kann ich sinnvoll entscheiden, ob eine Reparatur reicht oder ob sie nur die nächste Schicht auf ein grundsätzliches Problem legt.

Das heißt nicht, dass ich endlos am Bestand festhalte. Es heißt, dass ich die Grenze nicht am Alter, am verwendeten CMS oder an der Menge der Plugins ziehe. Ein System wird für mich nicht dadurch unrettbar, dass es unordentlich ist. Unordnung lässt sich oft schrittweise reduzieren. Schwieriger wird es, wenn ich nicht mehr zuverlässig feststellen kann, was eine Änderung auslöst und welche Funktion das System überhaupt erfüllen soll.

Erst verstehen, was nicht aufgeschrieben ist

Bei einer Übernahme gibt es oft eine Lücke zwischen dem, was ein System laut Dokumentation tun sollte, und dem, was es im Alltag tatsächlich tut. Manchmal gibt es wenig Dokumentation. Manchmal ist sie vorhanden, aber nicht mehr belastbar. Daraus folgt für mich nicht automatisch, dass alles neu muss. Es folgt zunächst, dass ich nicht so tun darf, als wäre die eigene Annahme schon Wissen.

Ich versuche, die Geschäftslogik sichtbar zu machen: Welche Zustände und Regeln gibt es? Welche Rolle darf was ändern? Woher kommen die Daten, wohin gehen sie, und welche Abläufe hängen davon ab? Wenn zentrale Regeln nur aus widersprüchlichem Verhalten erschlossen werden können und sich nicht verlässlich dokumentieren lassen, wird jede Änderung zum Ratespiel. Dann kann ich weder den Umfang einer Reparatur noch ihre Folgen seriös einschätzen.

Das ist ein anderes Problem als fehlende technische Eleganz. Unschöne Namen oder überladene Bereiche sind nicht automatisch ein Grund für einen Neubau. Nicht dokumentierbare Businesslogik dagegen nimmt mir die Grundlage, Änderungen kontrolliert vorzunehmen. Ich kann eine Stelle verbessern und dabei an anderer Stelle etwas verändern, dessen Zusammenhang ich nicht kenne.

Was ich zuerst prüfe: Kann ich die Regeln, Datenflüsse und Abhängigkeiten so beschreiben, dass eine andere Person nachvollziehen kann, was eine Änderung berührt?

Wenn Seiteneffekte nicht mehr kontrollierbar sind

Ein System darf komplex sein. Aber seine Komplexität muss für mich wenigstens teilweise beobachtbar und begrenzbar bleiben. Wenn eine Änderung an einer Stelle an mehreren unerwarteten Stellen wirkt, ohne dass ich die Verbindung erklären oder gezielt prüfen kann, steigt das Risiko mit jedem Eingriff.

Dann reicht es nicht, Änderungen einfach vorsichtiger zu machen. Vorsicht hilft nur, wenn ich weiß, worauf ich achten muss. Ich brauche einen Weg, den Ausgangszustand zu erfassen, eine Änderung zu begrenzen und anschließend zu prüfen, ob sie das gewünschte Ergebnis erzielt hat. Genau darin liegt für mich der Sinn von Know → Change → Prove: erst verstehen, dann gezielt verändern, anschließend die Wirkung belegen.

Wenn dieser Ablauf am bestehenden System nicht mehr herstellbar ist, ist das ein ernstes Signal. Es kann an fehlenden Tests, unklaren Schnittstellen, verdeckten Abhängigkeiten oder einem Datenmodell liegen, das Funktionen miteinander verknotet. Nicht jedes dieser Probleme verlangt sofort einen kompletten Ersatz. Aber wenn ich die Seiteneffekte weder isolieren noch zuverlässig beobachten kann, muss ich die Frage stellen, ob eine sichere Weiterentwicklung überhaupt noch möglich ist.

Das Datenmodell und die Abhängigkeiten

Ein kaputtes Datenmodell ist für mich nicht bloß eines, das sich rückblickend anders hätte entwerfen lassen. Ein Modell wird zum Hindernis, wenn es die tatsächlichen Inhalte und Beziehungen nicht mehr sinnvoll abbildet und jede weitere Funktion neue Ausnahmen oder Umwege verlangt. Dann wird nicht nur die Oberfläche kompliziert. Auch Pflege, Suche, Auswertung und Übergabe werden schwieriger, weil niemand mehr sicher sagen kann, welche Daten wofür stehen.

Ähnlich bewerte ich Abhängigkeiten. Dass ein System ältere oder ungewohnte Komponenten enthält, ist für sich genommen kein Urteil. Entscheidend ist, ob diese Komponenten noch tragbar sind: Lassen sie sich warten? Sind sie mit den Anforderungen vereinbar? Kann ich sie ersetzen oder abgrenzen, ohne an unbekannten Stellen Folgen auszulösen? Wenn zentrale Abhängigkeiten obsolet sind und kein sinnvoller Weg aus ihnen herausführt, verschiebt sich die Rechnung.

Auch Sicherheit kann diese Rechnung verändern. Ein Sicherheitsrisiko ist für mich kein Punkt, den man gegen ein schönes Design oder eine bequemere Pflege aufwiegen sollte. Zuerst muss klar werden, ob sich das Risiko im Bestand wirksam begrenzen lässt. Wenn nicht, ist Weiterbetrieb keine neutrale Entscheidung. Dann muss ich die Optionen für eine Ablösung oder einen kontrollierten Übergang ernsthaft prüfen.

Reparaturkosten sind nicht die ganze Rechnung

„Änderungskosten höher als Neubau“ klingt eindeutig, ist aber nur dann hilfreich, wenn ich nicht Äpfel mit Birnen vergleiche. Ein Neubau kostet nicht nur Entwicklung. Auch Anforderungen müssen geklärt, Daten übernommen, Abläufe angepasst und das neue System geprüft werden. Und wenn das alte System Funktionen enthält, die niemand mehr überblickt, kann ihre Bedeutung erst während der Ablösung sichtbar werden.

Umgekehrt darf der Bestand nicht deshalb als günstig gelten, weil seine Kosten verteilt und schwer erkennbar sind. Jede Sonderregel, jede fragile Abhängigkeit und jede Änderung, die nur mit hohem Risiko möglich ist, gehört in die Betrachtung. Ich frage nicht nur, was es kostet, den nächsten Fehler zu beheben. Ich frage auch, was es kostet, das System weiter zu betreiben und weiterzuentwickeln, ohne belastbare Kontrolle über die Folgen zu haben.

Der Vergleich ist für mich erst dann brauchbar, wenn beide Wege auf einem ähnlichen Verständnis des gewünschten Ergebnisses beruhen: Was soll erhalten bleiben? Was kann weg? Welche Daten und Abläufe müssen weiter funktionieren? Ohne diese Klärung wird „Neubau“ leicht zu einer Wunschvorstellung und „Reparatur“ zu einer Entscheidung aus Gewohnheit.

Ohne Migrationspfad ist ein Neustart kein Plan

Selbst wenn ich zu dem Schluss komme, dass das bestehende System nicht mehr sinnvoll zu retten ist, folgt daraus nicht automatisch, dass ein kompletter Neubau der nächste Schritt sein sollte. Ich brauche einen plausiblen Migrationspfad. Wie kommen die relevanten Inhalte und Daten in die neue Struktur? Wie lassen sich die nötigen Abläufe abbilden? Kann der Übergang in überprüfbare Schritte zerlegt werden?

Wenn sich diese Fragen nicht beantworten lassen, ist das kein Argument, das Problem zu ignorieren. Es zeigt, dass noch etwas fehlt: ein besseres Verständnis des Bestands, eine klarere Zielarchitektur oder eine realistische Reihenfolge der Ablösung. Manchmal ist ein Zwischenzustand sinnvoller als die Vorstellung, alles auf einmal auszutauschen. Manchmal muss zuerst ein Teilbereich abgegrenzt werden, bevor sich der Rest beurteilen lässt. Welche Form passt, hängt davon ab, was tatsächlich bekannt und veränderbar ist.

Ich ziehe die Grenze also nicht bei „alt“ oder „hässlich“. Ich ziehe sie dort, wo zentrale Geschäftslogik nicht mehr nachvollziehbar wird, Änderungen unkontrollierbare Folgen haben, Datenmodell oder Abhängigkeiten die Weiterentwicklung blockieren, Sicherheitsrisiken nicht wirksam begrenzt werden können und die Kosten des Festhaltens den Nutzen übersteigen. Dazu kommt eine Bedingung: Ich muss einen sinnvollen Weg aus dem Bestand heraus erkennen können.

Wenn mehrere dieser Punkte zusammentreffen, frage ich nicht mehr nur, wie ich das bestehende System repariere. Dann frage ich, welche Teile davon noch eine verlässliche Grundlage bilden können und wie der Übergang kontrollierbar wird. Das ist kein Plädoyer für Neubau. Es ist der Versuch, nicht aus Loyalität zum Bestand an einer Lösung festzuhalten, die sich nicht mehr verantwortungsvoll verändern lässt.

Meine Faustregel: Ich rette ein bestehendes System, solange ich seine Regeln verstehen, Änderungen begrenzen und ihre Wirkung prüfen kann. Wenn das nicht mehr gelingt, prüfe ich nicht den nächsten Trick, sondern den belastbaren Weg aus dem Bestand.

Weiterführend

• Legacy WordPress übernehmen, ohne das System zu zerstören
• WordPress modernisieren statt neu bauen
• WordPress-Relaunch ohne Kontrollverlust planen