Legacy Modernisierung: Neu schreiben oder Refactoring? Und warum die schrittweise Ablösung oft sicherer ist

Viele Unternehmen, die schon länger am Markt sind, haben ein System, über das in Besprechungen nur vorsichtig gesprochen wird. Darauf laufen die Fakturierung, das Lager oder die Fertigung, zahlreiche Personen haben es angepasst, kaum jemand versteht es bis ins Detail, und jede Änderung ist langsam und teuer.

Wenn schließlich darüber entschieden wird, liegt oft ein Satz auf dem Tisch: Wir schreiben alles neu. Das klingt verlockend, ist aber riskant: Alter Code ist ein Archiv von Geschäftsregeln, Ausnahmen und Korrekturen, die sich über Jahre angesammelt haben und oft nirgends aufgeschrieben sind, und wer ihn auf einen Schlag wegwirft, wirft auch dieses Wissen weg. Dabei kennt die Legacy Modernisierung mehr Formen als „so lassen“ oder „neu schreiben“, und bei einem großen, geschäftskritischen System ist es meist sicherer, es im laufenden Betrieb Stück für Stück abzulösen.

Symptome: ein System, vor dem sich das Unternehmen fürchtet

Michael Feathers, Autor des Buches Working Effectively with Legacy Code, definiert Legacy Code schlicht als Code ohne Tests. Ein Legacy-System erkennen Sie also nicht am Alter, sondern daran, ob es sich sicher ändern lässt. Typische Anzeichen:

• Eine einzige Person, die das System versteht. Scheidet sie aus, verliert das Unternehmen die Fähigkeit, einen Schlüsselprozess zu ändern.
• Angst vor Deployments. Änderungen werden zu großen Paketen gebündelt, sodass sich bei einem Fehler dessen Ursache schwerer finden lässt.
• Veraltete Technologien, für die sich nur schwer Fachkräfte finden lassen und die der Hersteller nicht mehr unterstützt.
• Sicherheitsrisiken, die sich ohne Eingriff in den Systemkern nicht beheben lassen.
• Neue Werkzeuge lassen sich nicht anbinden. Das System hat keine API-Schicht, also keine definierte Schnittstelle für den Datenaustausch, und so wird jede Anbindung an einen Onlineshop oder ein KI-Werkzeug zu einem eigenen Projekt.

All das sind Formen technischer Schulden, die der Beitrag Ein Unternehmen ist ein Produkt als Prinzip des gesamten Unternehmens beleuchtet.

Das betrifft auch den Staat. Der US-Rechnungshof GAO hat in einem Bericht vom Juli 2025 die 11 kritischsten Bundessysteme benannt, die eine Modernisierung benötigen. Acht davon verwenden veraltete Sprachen wie COBOL und Assembler, und sieben laufen nach Angaben der Behörden mit bekannten Sicherheitslücken, die sich ohne Modernisierung nicht beheben lassen.

Warum „Wir schreiben alles neu“ so verlockend ist

Ein Big Bang Rewrite bedeutet, ein neues System von Grund auf zu bauen und das gesamte Unternehmen auf einen Schlag darauf umzustellen. Er verspricht einen sauberen Neuanfang und moderne Technologie. Joel Spolsky nennt in einem Essay aus dem Jahr 2000 einen weniger schmeichelhaften Grund: Programmierer halten alten Code vor allem deshalb für ein Durcheinander, weil es schwieriger ist, Code zu lesen, als ihn zu schreiben. Code von Grund auf neu zu schreiben, bezeichnete er als den schlimmsten strategischen Fehler, den ein Softwareunternehmen machen kann. Als Beispiel führte er Netscape an: Version 6.0 ging fast drei Jahre nach Version 4.0 in die erste öffentliche Beta, und der Marktanteil des Unternehmens sank in der Zwischenzeit drastisch.

Das ist eine zugespitzte Position, die konkreten Mechanismen des Scheiterns lassen sich jedoch benennen:

• Verborgene Regeln. Die unschönen Stellen im alten Code sind laut Spolsky oft Fehlerkorrekturen für Probleme, die sich erst nach Wochen realer Nutzung gezeigt haben. Ein Rewrite verwirft sie, und dieselben Fehler können erneut auftreten, wieder erst im Produktivbetrieb.
• Doppelte Entwicklung. Laufende Anforderungen aus dem Geschäft werden laut den Autoren von Thoughtworks weiterhin im Altsystem umgesetzt, sodass das Unternehmen zwei Entwicklungsstränge gleichzeitig bezahlt.
• Lange Zeit ohne Nutzen. Martin Fowler erinnert daran, dass die Ablösung eines ernstzunehmenden IT-Systems lange dauert und Nutzer nicht auf neue Funktionen warten können.
• Ein bewegliches Ziel. Die Autoren von Thoughtworks beschreiben eine Organisation mit einer Reihe von Modernisierungsprogrammen über jeweils drei bis fünf Jahre. In jedem davon überholten die sich wandelnden Anforderungen des Geschäfts die Technologiestrategie, und man begann von vorn. Wo ein Programm als Big Bang angelegt war, bedeutete das, den Großteil der Arbeit wegzuwerfen.

Sechs Optionen und wann welche passt

1. Behalten und stabilisieren. Monitoring für Fehler und Ausfälle, Backups und Dokumentation ergänzen und eine zweite Person einarbeiten, die das System versteht. Das passt, wenn das System seine Arbeit erledigt und sich selten ändert. Oft ist das der günstigste Weg, das Risiko zu senken.
2. Refaktorisieren. Refactoring ist laut Martin Fowler eine Änderung der inneren Struktur von Software, die sie verständlicher und kostengünstiger anpassbar macht, ohne ihr beobachtbares Verhalten zu verändern. Das passt, wenn die Technologie in Ordnung, der Code aber verworren ist.
3. Auf neue Infrastruktur umziehen, etwa vom eigenen Server in die Cloud. Das passt, wenn der Betrieb oder die Hardware das Problem ist. Eine schlechte Anwendungslogik heilt der Umzug nicht.
4. Schrittweise ablösen. Das passt bei großen, kritischen Systemen, die nicht stillstehen dürfen, deren Verhalten niemand vollständig kennt und die noch lange parallel zu neuen Systemen laufen können.
5. Fertige Software kaufen. Bei einem Standardprozess wie Buchhaltung oder Zeiterfassung ist eine Eigenentwicklung meist überflüssig, allerdings muss sich der Prozess dann dem Produkt anpassen. Diese Entscheidung behandelt der Beitrag Sieben SaaS-Tools oder ein System?
6. Stilllegen. Bedient das System einen Prozess, den es nicht mehr gibt, ist vorher noch zu prüfen, ob andere Systeme oder Reports Daten daraus beziehen.

Strangler Fig: Das neue System wächst neben dem alten

Der Name Strangler Fig Pattern geht auf eine Metapher von Martin Fowler zurück: Im Jahr 2001 sah er in den Regenwäldern von Queensland Würgefeigen, die einen Wirtsbaum nach und nach umwachsen, bis sie ihn ersetzen. Ebenso entsteht das neue System nicht anstelle des alten, sondern daneben. Es übernimmt eine Funktion nach der anderen, bis sich das alte System abschalten lässt.

Die Dokumentation von Microsoft beschreibt den Mechanismus: Zwischen die Nutzer und beide Systeme wird eine Fassade geschaltet, also ein Vermittler, der Anfragen schrittweise vom alten auf das neue System umleitet, zum Beispiel zunächst nur die Angebotskalkulation. Die Nutzer merken von der Migration nichts. Das alte System bleibt laut Feathers als Rückfallebene für den Fall von Problemen bestehen.

Fowler verschweigt den Preis nicht: eine Übergangsarchitektur für den Parallelbetrieb beider Systeme, die nach Abschluss wieder verschwindet. Das geringere Risiko und der frühere Nutzen überwiegen ihn seiner Ansicht nach, weil die ausgetauschten Teile klein sind. Er warnt jedoch, dass ohne einen Wandel in Kultur und Führung auch das neue System in einem ähnlichen Durcheinander endet.

Die Daten sind der schwierigste Teil

Code lässt sich Stück für Stück austauschen, auf die Daten aber sind während der Umstellung beide Systeme gleichzeitig angewiesen. Eine Datenmigration, also die Übertragung von Daten aus der alten Struktur in die neue, ist kein einfaches Kopieren. Forscher des Trinity College Dublin weisen darauf hin, dass Daten aus Altsystemen häufig von schlechter Qualität sind, auf die neue Struktur abgebildet und oft auch bereinigt werden müssen. In der Praxis geht es etwa um Dubletten, zweckentfremdete Felder und Werte, die nur der alte Code versteht.

Microsoft empfiehlt, die Daten schrittweise und nach Bereichen zu trennen: die neue Datenbank mit einer Initialladung befüllen, weitere Änderungen per Change Data Capture übertragen, also durch das Erfassen von Änderungen in der alten Datenbank, vor der Umstellung die Übereinstimmung prüfen und die alten Objekte erst nach der Validierung des neuen Systems entfernen. Bis dahin ist ein Rollback möglich, danach ist er deutlich aufwendiger und riskanter.

Für jede Art von Daten muss während der Umstellung klar sein, welches System die Single Source of Truth ist, also die einzige verbindliche Quelle. Lässt sich die Adresse eines Kunden in beiden Systemen ändern, droht, dass am Ende jedes System eine andere führt. Unsere praktische Schlussfolgerung: Eine bestimmte Angabe sollte immer nur in einem System geändert werden, und die übrigen Systeme übernehmen sie von dort lediglich. Der umfassenderen Rolle von Daten widmet sich der Beitrag Ihre Daten sind der Vorsprung.

Wie Sie herausfinden, was das System wirklich tut

Feathers weist darauf hin, dass Menschen eine Vorstellung davon im Kopf haben, was ein System tut, und vergessen nachzusehen, was es tatsächlich tut. Drei Quellen helfen dabei:

• Beobachtung der Nutzer. Verfolgen, was Menschen mit dem System tun, und nicht, was sie darüber erzählen. Hier zeigen sich Workarounds, nebenher geführte Tabellen und manuelle Schritte.
• Logs, also Protokolle der Systemaktivität. Sie zeigen, welche Funktionen wie oft und von wem genutzt werden, und helfen, unerwartete Abhängigkeiten aufzudecken.
• Tests des aktuellen Verhaltens. Feathers beschreibt Charakterisierungstests: Man stellt dem Code eine Frage und hält die ermittelte Antwort als erwartetes Ergebnis fest. So entstehen Regressionstests, also automatische Prüfungen, die nach jeder Änderung sicherstellen, dass weiterhin funktioniert, was bisher funktioniert hat.

Die Autoren von Thoughtworks beschreiben ein Team, das im Produktivbetrieb den Ersatz einer Integrations-Middleware testete, also der Software, die die übrigen Systeme miteinander verbindet. Kurz darauf stimmten kritische Managementreports nicht mehr. Nach langer Suche stellte sich heraus, dass die Datenbank der Middleware in ein Data Warehouse repliziert wurde, aus dem die Reports gespeist wurden. Abhilfe schaffte erst ein temporärer Mechanismus, der die fehlenden Daten im Data Warehouse ergänzte.

Die Reihenfolge: größter Schmerz, kleinstes Risiko

Die Migration sollte nicht der erste Schritt sein. Auch hier gilt für uns die Reihenfolge Remove, Simplify, Automate, Augment: zuerst streichen, dann vereinfachen, erst danach automatisieren und erweitern. Die Autoren von Thoughtworks weisen darauf hin, dass die meisten Altsysteme im Laufe der Zeit durch Funktionen aufgebläht werden, die niemand nutzt, und berufen sich auf einen Bericht der Standish Group aus dem Jahr 2014, wonach dies 50 % der Funktionen betrifft. Für ein konkretes System ist das nur ein Richtwert, die tatsächliche Lage zeigen die Logs. Eine gestrichene Funktion muss weder analysiert noch migriert oder getestet werden, und Workarounds für die Grenzen des Altsystems sollten Sie bei der Übertragung lieber vereinfachen als kopieren.

Der erste abgelöste Teil sollte spürbare Schmerzen verursachen, etwa das Geschäft ausbremsen, und zugleich vergleichsweise unabhängig vom Kern sein. Feathers rät, sich auf Teile zu konzentrieren, die wachsen werden und zugleich Schwierigkeiten bereiten, und für das Umleiten von Anfragen Nahtstellen zu finden. So nennt er Punkte, an denen sich ein Verhalten durch ein anderes ersetzen lässt.

Risiken und wie Sie sie während der Umstellung messen

Eine schrittweise Ablösung beseitigt das Risiko nicht, sie teilt es in kleinere, messbare Stücke auf. Das Gegenteil veranschaulicht die Entscheidung der britischen Finanzaufsicht FCA vom 20. Dezember 2022. Die Bank TSB verlagerte am Wochenende vom 20. bis 22. April 2018 den Großteil ihres Betriebs und ihrer Kundendaten auf eine neue, noch nicht erprobte Plattform. Es folgten schwerwiegende Probleme beim Online-Banking, beim Mobile-Banking und bei Kartenzahlungen, und bis zum 7. April 2019 gingen bei der Bank 225.492 Beschwerden ein. Die FCA stellte Versäumnisse bei Planung, Tests und Risikomanagement sowie bei der Überwachung des externen Dienstleisters fest, wies darauf hin, dass die Bank nach dem Go-live praktisch nicht mehr auf die ursprüngliche Plattform zurückkehren konnte, und verhängte eine Geldbuße von 29,75 Mio. GBP.

Einen sichereren Weg beschrieb Vicent Martí von GitHub im Jahr 2015. Das Team ersetzte einen der kritischsten Teile des Codes direkt im Produktivbetrieb: Alter und neuer Code liefen parallel, die Ergebnisse wurden verglichen, und der Nutzer erhielt stets das Ergebnis des alten Codes. Das Experiment startete mit 1 % der Anfragen und wurde schrittweise ausgeweitet, bis es 24 Stunden lang auf 100 % ohne Abweichungen lief. Der Vergleich deckte zudem 2 schwerwiegende Fehler in der ursprünglichen Lösung auf, die jahrelang niemand bemerkt hatte.

Was Sie also beobachten sollten:

• Die Übereinstimmung der Ergebnisse von alter und neuer Lösung auf realen Daten vor der Umstellung.
• Fehlerrate und Performance nach jeder Umleitung.
• Den Rückweg: wie schnell das Unternehmen zum ursprünglichen Zustand zurückkehren kann.
• Die Datenkonsistenz und die Zahl manueller Korrekturen.
• Den Anteil des übernommenen Betriebs. Wächst er über längere Zeit nicht, wird das Projekt zu einem Parallelbetrieb ohne Ende.

Wann ein kompletter Rewrite gerechtfertigt ist

Ein kompletter Rewrite ist nicht immer ein Fehler. Feathers beschreibt ihn als geschäftliche Entscheidung über die Rentabilität, versucht selbst aber zuerst ein Refactoring und erinnert daran, dass meist nicht das ganze System neu geschrieben werden muss und gezielte Neuentwicklungen einzelner Teile oft sehr wirksam sind. Microsoft nennt Fälle, in denen sich eine schrittweise Ablösung nicht eignet: Das System ist klein und lässt sich einfach als Ganzes ersetzen, es besteht kein Zugriff auf den Quellcode, oder die bisherige Lösung muss schnell außer Betrieb genommen werden. Die Autoren von Thoughtworks lassen eine originalgetreue Nachbildung der alten Funktionen bei Systemen mit gut bekannter Spezifikation gelten, bei denen eine bestimmte Eingabe eine bestimmte Ausgabe ergeben muss, halten solche Fälle aber für die Ausnahme.

Unsere Sicht: Ein Rewrite ist auch dann vertretbar, wenn sich das Geschäft so stark verändert hat, dass das Altsystem eine Arbeitsweise unterstützt, von der sich das Unternehmen verabschiedet. Dann geht es jedoch um ein neues Produkt mit neuer Aufgabenstellung und nicht um eine Kopie der alten Funktionen.

Die Legacy Modernisierung beginnt deshalb nicht mit der Wahl der Technologie, sondern mit dem Verständnis, welche Arbeit das System für das Unternehmen leistet, welche seiner Teile tatsächlich genutzt werden und wo genau der Schmerz entsteht. Wer diese Diagnose überspringt, entscheidet blind zwischen Rewrite und Refactoring.

Was Sie mitnehmen

• Sie wählen nicht nur zwischen „belassen“ und „neu schreiben“, sondern aus sechs Optionen. Stabilisierung, fertige Software oder Stilllegung sind oft günstiger als ein Rewrite.
• Finden Sie vor der Migration heraus, was das System wirklich tut: durch Beobachtung der Menschen, anhand der Logs und mit Tests des aktuellen Verhaltens.
• Streichen Sie zuerst ungenutzte Funktionen, sonst migrieren und testen Sie diese unnötig.
• Lösen Sie ein großes, kritisches System in Teilen ab, beginnen Sie dort, wo der Schmerz am größten und das Risiko am kleinsten ist, und halten Sie sich einen Rückweg offen.
• Legen Sie für jede Art von Daten die Single Source of Truth fest und messen Sie die Übereinstimmung der Ergebnisse, die Fehlerrate und den Anteil des übernommenen Betriebs.