Refactoring oder Neuentwicklung? Was Führungskräfte über Altsysteme wissen sollten

Fast jedes Unternehmen hat eines: ein System, das seit vielen Jahren zuverlässig läuft, das niemand gern anfasst und das nur noch wenige Mitarbeitende im Detail verstehen. Spätestens wenn kleine Änderungen Monate dauern oder für die eingesetzte Plattform keine Sicherheitsupdates mehr erscheinen, steht die Frage im Raum: Refactoring oder Neuentwicklung?

Der Wunsch nach einem sauberen Neuanfang ist verständlich, doch er gehört zu den riskantesten Entscheidungen in der IT. Dieser Beitrag zeigt, was ein Altsystem wirklich kostet, wann sich die schrittweise Modernisierung lohnt, wann eine Neuentwicklung gerechtfertigt ist und warum die beste Lösung oft dazwischen liegt.

Was ein Altsystem wirklich kostet

Alter allein ist kein Problem. Der Softwareexperte Michael Feathers definiert Legacy-Code in seinem Standardwerk „Working Effectively with Legacy Code“ schlicht als „Code ohne Tests“^*. Entscheidend ist also nicht das Baujahr, sondern ob sich ein System gefahrlos ändern lässt. Fehlt diese Sicherheit, wird jede Anpassung zum Wagnis. Releases werden seltener, Entwicklungszeiten länger, und das Wissen konzentriert sich auf wenige Köpfe.

Diese technischen Schulden haben einen Preis. In einer Umfrage von McKinsey aus dem Jahr 2020 unter 50 CIOs großer Finanz- und Technologieunternehmen bezifferten die Befragten ihre technischen Schulden auf 20 bis 40 Prozent des Werts ihrer gesamten Technologielandschaft vor Abschreibungen. Zudem flossen nach ihren Angaben 10 bis 20 Prozent des Budgets für neue Produkte in die Behebung von Altlasten statt in Innovation.

Hinzu kommt die Regulierung. Seit dem 6. Dezember 2025 gilt in Deutschland das NIS2-Umsetzungsgesetz. Es verpflichtet die erfassten Unternehmen zu Sicherheitsmaßnahmen bei der Wartung ihrer IT-Systeme, „einschließlich Management und Offenlegung von Schwachstellen“ (§ 30 BSIG). Die Geschäftsleitung muss diese Maßnahmen umsetzen und ihre Umsetzung überwachen (§ 38 BSIG). Ein Altsystem ohne Sicherheitsupdates wird damit zur Chefsache.

Refactoring: modernisieren im laufenden Betrieb

Martin Fowler, Autor des Standardwerks „Refactoring“, beschreibt Refactoring als Änderung der internen Struktur einer Software, die sie „leichter verständlich und günstiger veränderbar“ macht, „ohne ihr beobachtbares Verhalten zu ändern“^*. Das System wird also nicht ersetzt, sondern Schritt für Schritt aufgeräumt. Verflochtene Module werden getrennt, veraltete Bibliotheken ausgetauscht, Frameworks auf aktuelle Versionen gehoben. Automatisierte Tests sichern jeden Schritt ab; oft müssen sie zuerst geschrieben werden.

Für die Unternehmensführung hat dieser Weg handfeste Vorteile. Das Risiko bleibt gering, weil jede Änderung überschaubar ist und sich zurücknehmen lässt. Das System liefert weiterhin Wert, das im Code gespeicherte Fachwissen bleibt erhalten, und das Budget lässt sich in Etappen steuern. An seine Grenzen stößt Refactoring, wenn das Fundament nicht mehr trägt: wenn Programmiersprache oder Plattform keine Zukunft haben oder sich das Geschäftsmodell so verändert hat, dass die Grundstruktur des Systems nicht mehr passt. Dann wird nur noch eine Fassade renoviert, hinter der das eigentliche Problem bleibt.

Neuentwicklung: der verlockende Neuanfang

Eine Neuentwicklung verspricht moderne Technologie, eine saubere Architektur und das Ende aller Altlasten. Der Softwareunternehmer Joel Spolsky hat diesen Traum im April 2000 am Beispiel von Netscape seziert. Der Browserhersteller hatte beschlossen, seinen Code von Grund auf neu zu schreiben. Für Spolsky war das „der schlimmste strategische Fehler, den ein Softwareunternehmen machen kann“^*. Das letzte große Release lag zu diesem Zeitpunkt fast drei Jahre zurück, und Netscape musste laut Spolsky „hilflos“ zusehen, wie der eigene Marktanteil einbrach.

Sein Kernargument gilt bis heute: Alter Code wirkt unübersichtlich, steckt aber voller Erfahrung. Hinter mancher seltsamen Zeile verbirgt sich eine Fehlerkorrektur, und jeder dieser Fehler brauchte, so Spolsky, „Wochen im realen Einsatz“^*, bis er überhaupt entdeckt wurde. Wer neu schreibt, wirft dieses Wissen weg. Hinzu kommt der Second-System-Effekt, den Fred Brooks schon 1975 in „The Mythical Man-Month“ beschrieb: Beim Nachfolgesystem wollen Teams alles nachholen, was beim ersten zu kurz kam, und der Umfang wächst. Gleichzeitig muss das Altsystem weiter gepflegt werden, oft mit neuen Anforderungen, die das Ziel der Neuentwicklung laufend verschieben.

Besonders riskant ist die Umstellung in einem einzigen Schritt, der sogenannte Big Bang. Die britische Bank TSB migrierte im April 2018 auf eine neue IT-Plattform. Unmittelbar danach kam es zu massiven Störungen in den Filialen sowie im Telefon-, Online- und Mobile-Banking; betroffen war ein erheblicher Teil der 5,2 Millionen Kunden. Erst im Dezember 2018 kehrte die Bank zum Normalbetrieb zurück. Die britischen Aufsichtsbehörden FCA und PRA verhängten dafür 2022 Strafen von zusammen 48,65 Millionen Pfund. „Die Versäumnisse in diesem Fall waren weitreichend und schwerwiegend“^*, erklärte Mark Steward, damals Exekutivdirektor für Enforcement und Marktaufsicht der FCA.

Der dritte Weg: schrittweise ablösen

Zwischen Sanierung und Abriss liegt ein Ansatz, den Fowler nach einer Pflanze benannt hat, deren Wuchs er während eines Urlaubs im australischen Queensland beobachtete: der Würgefeige, englisch Strangler Fig. Sie keimt in der Krone eines Wirtsbaums, schickt ihre Wurzeln am Stamm hinab bis in den Boden und überdauert den Wirt am Ende. Übertragen auf Software heißt das: Vor das Altsystem wird eine Schnittstelle gesetzt, über die Funktion für Funktion auf neue Komponenten umgeleitet wird. Das alte System schrumpft, bis es abgeschaltet werden kann.

Fowler begründet den Ansatz nüchtern. Der Ersatz eines ernsthaften IT-Systems dauere lange, „und die Nutzer können nicht auf neue Funktionen warten“^*. Den scheinbar einfachen Plan einer gleichwertigen Neuentwicklung habe er mit seinen Kollegen „meistens in Flammen aufgehen“^* sehen. Beim graduellen Vorgehen fallen Investitionen und Erträge dagegen „schrittweise und sichtbar“^* an. Für das Management ist das der entscheidende Punkt: Jede Etappe liefert nutzbare Ergebnisse, und das Vorhaben lässt sich neu priorisieren, ohne dass bereits investiertes Geld verloren ist.

Moderne Werkzeuge verändern diese Rechnung nur teilweise. KI-Assistenten helfen inzwischen dabei, undokumentierten Code zu erschließen und fehlende Tests zu ergänzen. Die Grundsatzentscheidung und die Verantwortung für das Ergebnis nehmen sie niemandem ab.

Woran Sie den richtigen Weg erkennen

Für die Einordnung genügen meist fünf Fragen. Ist die fachliche Logik des Systems noch richtig, oder hat sich das Geschäft grundlegend verändert? Werden Programmiersprache, Frameworks und Plattform noch gepflegt? Gibt es Tests, Dokumentation und Menschen, die das System verstehen? Lässt es sich in Teile zerlegen, die einzeln ersetzt werden können? Und wie lange kann das Unternehmen auf neue Funktionen verzichten?

Stimmen Logik und technische Basis, ist Refactoring fast immer der wirtschaftlichere Weg. Ist das Fundament überholt, führt an einer Neuentwicklung kaum ein Weg vorbei. Sie sollte dann aber nach dem Prinzip der Würgefeige erfolgen, nicht als Big Bang. Eine Neuentwicklung in einem Zug ist nur bei kleinen, gut verstandenen Systemen vertretbar, deren Ausfall das Geschäft nicht gefährdet.

Fazit: eine unternehmerische Entscheidung

Refactoring oder Neuentwicklung ist weniger eine technische als eine unternehmerische Frage. Es geht um Risiko, Kapitalbindung und Geschwindigkeit. In den meisten Fällen gewinnt nicht der radikale Schnitt, sondern eine kontinuierliche, gut geplante Modernisierung, die Bewährtes erhält und Neues dort baut, wo es den größten Nutzen stiftet.

Voraussetzung dafür ist ein ehrliches Bild des Ist-Zustands, von der Codequalität über Abhängigkeiten bis zur Sicherheitslage. Genau hier unterstützt 4eB. Im Rahmen unserer IT-Beratung analysieren wir gewachsene Systeme und erarbeiten mit Ihnen einen Modernisierungsplan, der zu Budget und Geschäftszielen passt. Als Partner für Software- und App-Entwicklung setzen wir ihn anschließend um: durch Refactoring, Versions-Upgrades oder die schrittweise Ablösung einzelner Komponenten – ohne den laufenden Betrieb zu gefährden.

Quellen

• Michael C. Feathers: Working Effectively with Legacy Code, Prentice Hall, 2004
• Vishal Dalal, Krish Krishnakanthan, Björn Münstermann, Rob Patenge: Tech debt: Reclaiming tech equity, McKinsey, Oktober 2020
• § 30 BSIG (Risikomanagementmaßnahmen) und § 38 BSIG (Pflichten der Geschäftsleitung) in der Fassung des NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetzes, in Kraft seit 6. Dezember 2025
• Martin Fowler: DefinitionOfRefactoring, 1. September 2004
• Joel Spolsky: Things You Should Never Do, Part I, Joel on Software, 6. April 2000
• Frederick P. Brooks Jr.: The Mythical Man-Month, Addison-Wesley, 1975
• Financial Conduct Authority: TSB fined £48.65m for operational resilience failings, 20. Dezember 2022
• Martin Fowler: Strangler Fig, 22. August 2024

* Zitate aus englischsprachigen Quellen sind eigene Übersetzungen. Die Bilder in diesem Beitrag sind KI-generiert.