Legacy-Software modernisieren: Wann refactoren, wann neu bauen

Es gibt Software, die seit zwölf Jahren das Herzstück eines Unternehmens ist und auch noch in zehn Jahren laufen wird. Und es gibt Software, die genauso alt ist und das Unternehmen langsam auffrisst. Der Unterschied liegt selten im Code selbst. Er liegt darin, ob das System gepflegt, weiterentwickelt und bei Bedarf modernisiert wurde, oder ob über Jahre nur reagiert wurde, wenn etwas brannte.

Im DACH-Mittelstand findest du beides. Viele ERP-, Branchen- oder Eigenentwicklungen sind über 15 bis 25 Jahre an die individuellen Prozesse angepasst worden. Sie funktionieren noch, aber jede neue Anbindung wird teurer, jede Cloud-Integration ist ein Kraftakt, und jede Mitarbeitersuche scheitert an Technologien, die nur noch ältere Entwickler kennen. Wer das Thema vor sich herschiebt, zahlt jeden Monat dafür. Branchenstudien deuten darauf hin, dass die Wartung veralteter Software 60 bis 80 Prozent vieler IT-Budgets verschlingt. Das ist Geld, das nicht in Innovation fließt.

Die zentrale Frage lautet also nicht ob, sondern wie modernisiert werden sollte. Und genau da scheitern die meisten Projekte.

Warum die meisten Modernisierungen scheitern

Das Standard-Reflex ist: alles wegwerfen, neu machen. Ein kompletter Rewrite klingt sauber, motivierend und nach klarem Schnitt. In der Praxis ist er einer der zuverlässigsten Wege, ein Unternehmen für zwei bis vier Jahre lahmzulegen. Branchenanalysen zu großen Migrationsprojekten zeigen, dass mehr als die Hälfte der vollständigen Rewrites die ursprünglichen Ziele nicht erreichen. Häufig nach Millionen-Investitionen und erheblichen Geschäftsstörungen.

Der Grund ist meistens derselbe. In einem 15 Jahre alten System steckt nicht nur Code. Es stecken tausende kleine Anpassungen, Sonderfälle, Workarounds, ungeschriebene Regeln, die irgendwann einmal jemand wegen eines bestimmten Kunden, einer bestimmten Steuer-Reform oder eines bestimmten Lieferanten eingebaut hat. Das alles muss in der neuen Software ebenfalls funktionieren. Und niemand weiß genau, was alles drin ist. Erst beim Rollout merkt man, was fehlt. Da ist es zu spät.

Die zweite typische Falle: das Gegenteil. Statt zu modernisieren, wird weiter geflickt. Jeder neue Stein im Stapel macht das System brüchiger. Irgendwann fällt es um, oft genau dann, wenn es niemand brauchen kann.

Die echten Optionen

Es gibt mehr als nur „neu bauen” oder „weiter flicken”. Die gängige Klassifikation kennt sechs Strategien, oft als die „6 R” bezeichnet:

1. Retain. System läuft weiter, bewusst keine Änderung. Sinnvoll, wenn der Schmerz noch nicht groß genug ist.
2. Retire. System abschalten, Funktionalität anderweitig abdecken oder einfach streichen. Häufiger sinnvoll als gedacht.
3. Rehost. Software unverändert auf neue Infrastruktur heben („Lift and Shift”). Schnell, billig, aber löst keine fachlichen Probleme.
4. Replatform. Anwendung mit minimalen Anpassungen auf eine neue Plattform bringen, etwa von On-Premise in die Cloud.
5. Refactor. Code-Struktur verbessern, ohne die fachliche Funktion zu ändern. Schritt für Schritt, mit Tests abgesichert.
6. Replace. Bestehendes System durch eine Standardlösung oder eine komplette Neuentwicklung ersetzen.

In der Praxis wird selten nur eine Strategie verfolgt. Bei größeren Modernisierungen kommen oft drei oder vier dieser Ansätze gleichzeitig zum Einsatz, je nachdem, welcher Teil des Systems wie kritisch ist und wie schmerzhaft der jeweilige Schritt wäre.

Wann Refactoring die richtige Wahl ist

Refactoring lohnt sich, wenn die fachliche Logik gut ist und der Code grundsätzlich strukturierbar bleibt. Wenn das System läuft, aber an manchen Stellen unverständlich, schwer zu testen oder kaum noch erweiterbar ist. Wenn die Architektur prinzipiell vernünftig ist, aber einzelne Bereiche aufgeräumt gehören.

Konkret bedeutet Refactoring: Du verbesserst die innere Struktur, ohne dass sich von außen etwas ändert. Module werden klarer geschnitten, Tests werden ergänzt, Abhängigkeiten werden entwirrt. Das Risiko bleibt überschaubar, weil nichts in einem großen Knall ausgetauscht wird. Die Kosten verteilen sich über Monate, manchmal Jahre. Du behältst die fachliche Korrektheit, weil das Verhalten nach außen gleich bleibt.

Refactoring scheitert dann, wenn der Code wirklich nicht mehr zu retten ist, oder wenn das Team nicht diszipliniert genug arbeitet. Refactoring ohne automatisierte Tests ist russisches Roulette. Wer Tests nachträglich nicht aufbauen kann, sollte ehrlich sein und über andere Strategien nachdenken. Mehr zur Bedeutung automatisierter Tests in genau solchen Situationen findest du im Beitrag zu automatisierten Software-Tests.

Wann ein Rewrite die richtige Wahl ist

Ein kompletter Neubau lohnt sich nur in ganz wenigen Fällen. Zum Beispiel, wenn die Plattform technisch nicht mehr zukunftsfähig ist (Visual Basic 6, Delphi-Versionen ohne Support, COBOL-Inseln ohne verfügbare Entwickler). Oder wenn die fachliche Welt sich so stark geändert hat, dass die alte Datenstruktur nicht mehr passt. Oder wenn das System mit drei oder vier Vorgängern verschmolzen ist und die Komplexität jeder Änderung exponentiell gewachsen ist.

Wer sich für einen Rewrite entscheidet, sollte das mit klaren Augen tun. Realistische Zeit: ein bis drei Jahre. Realistisches Risiko: hoch. Realistische Empfehlung: Niemals den Rewrite alleine fahren, ohne dass das alte System parallel weiterläuft. Big-Bang-Migrationen sind die häufigste Ursache für gescheiterte Projekte. Wer von einem Tag auf den anderen umstellt, wird mit Datenverlust, Downtime und Mitarbeiterprotest bezahlt.

Strangler Fig Pattern: Der goldene Mittelweg

Es gibt einen dritten Weg, der in vielen Fällen besser passt als sowohl Refactoring als auch ein kompletter Rewrite. Er heißt Strangler Fig Pattern, geprägt von Martin Fowler 2004 und benannt nach der Würgefeige, die langsam um einen alten Baum herumwächst, bis sie ihn ersetzt hat.

Das Prinzip: Du baust nicht das ganze System neu. Du baust einzelne Module außerhalb neu und leitest den Datenverkehr nach und nach auf die neuen Module um. Eine Routing-Schicht, oft als API-Gateway oder Reverse Proxy umgesetzt, entscheidet, ob ein Request ans alte oder ans neue System geht. Über die Zeit wandern immer mehr Funktionen in die neue Welt, bis am Ende kaum noch etwas vom Original übrig ist.

Die Vorteile sind handfest. Du modernisierst in deinem eigenen Tempo. Du kannst jederzeit einen Schritt zurück gehen, wenn etwas nicht funktioniert. Du musst nicht alles auf einmal verstanden haben, sondern nur den Teil, an dem du gerade arbeitest. Und das alte System bleibt stabil, während um es herum gebaut wird.

Es gibt zwei Stolperfallen, die du kennen solltest. Erstens entstehen Mehrfachhaltungen von Daten, weil das alte und das neue System parallel laufen. Du brauchst Synchronisationsmechanismen, sonst hast du nach drei Monaten zwei Wahrheiten. Zweitens besteht die Versuchung, irgendwann aufzuhören. Wenn die wichtigsten Module umgezogen sind, sinkt der Druck. Was übrig bleibt, kostet weiter Geld in der Wartung. Wer den Strangler-Ansatz wählt, sollte den Endzustand klar definieren und ihn auch wirklich erreichen.

Wie du die Entscheidung triffst

In der Praxis hat sich folgende Reihenfolge bewährt. Erst Bestandsaufnahme: Was tut die Software eigentlich, welche Module sind kritisch, welche sind tot, welche werden täglich benutzt? Sehr oft stellt sich heraus, dass 30 Prozent des Codes seit Jahren nicht mehr ausgeführt werden. Diese Module muss man nicht modernisieren, man kann sie löschen.

Danach Schmerzanalyse: Wo verlieren wir Zeit, Geld oder Kunden? Wo bremst uns die alte Software konkret aus? Diese Stellen sind die besten Kandidaten für eine erste Modernisierung. Nicht der schwierigste Teil zuerst, sondern der mit dem klarsten Nutzen.

Erst dann die Strategie. Für die meisten Mittelständler ist eine Mischung sinnvoll: Stabile, gut funktionierende Module weiterlaufen lassen oder vorsichtig refactoren. Schmerzhafte Module per Strangler Fig schrittweise ersetzen. Tote Module abschalten. Für sehr alte Plattformen kann ein Rehost in die Cloud sinnvoll sein, um zumindest die Infrastruktur-Probleme loszuwerden, bevor man fachlich modernisiert.

Was du nicht tun solltest: dem Team einen Rewrite ohne Erfahrung mit Modernisierungen aufdrücken. Wer nie ein Strangler-Projekt durchgezogen hat, unterschätzt zuverlässig die Synchronisationsthemen, das Routing und die Datenmigration. In dem Bereich lohnt sich externe Erfahrung, sei es durch eine kurze Beratung oder durch eine begleitende individuelle Softwareentwicklung.

Was 2026 anders ist

Zwei Veränderungen sind für Modernisierungsprojekte 2026 relevant. Erstens hilft KI inzwischen tatsächlich beim Verstehen alter Codebasen. Tools wie GitHub Copilot, Sourcegraph Cody oder spezialisierte Modernisierungs-Suiten können Legacy-Code dokumentieren, Tests vorschlagen und Strukturen umbauen. Sie ersetzen keinen Architekten, beschleunigen aber die Diagnosephase erheblich.

Zweitens werden Cloud-Plattformen reifer. Was früher als „Hebt mal eben in die Cloud” oft scheiterte, ist heute deutlich besser unterstützt. Das macht Replatform-Strategien attraktiver, vor allem für Unternehmen, die bisher rein on-premise gefahren sind.

Trotz aller Tools bleibt die wichtigste Frage unverändert. Welcher Schmerz ist heute groß genug, dass sich eine Investition lohnt, und welche Strategie passt zu unserer Mannschaft? Wer das ehrlich beantwortet, vermeidet die Klassiker. Wer die Antwort nicht kennt, sollte sie zuerst klären, bevor er irgendwo Code anfasst. Eine Fokus-Session ist oft der schnellste Weg, um die Optionen einzugrenzen, ohne sich gleich auf einen Pfad festzulegen.