Refaktorisierung oder Neuschreiben ist selten eine Stilfrage und fast nie ein Urteil über „schönen“ oder „hässlichen“ Code. In realen Vorhaben gewinnt meist die Option, die Abnahme, Migration und Betriebsübergang beherrschbar hält. Genau deshalb ist der frühe Komplett-Rewrite oft die riskantere Kaufentscheidung: Er verlangt hohe Vorleistung, bevor Fachbereiche überhaupt belastbar bestätigen können, dass das neue System im Alltag dieselben kritischen Sonderfälle sauber trägt.
Der häufigste Fehler steckt in der Reihenfolge. Teams diskutieren früh über Stack, Cloud-Zielbild und neue Oberfläche. Erst später fällt auf, dass Sonderfälle, Datenzustände und implizite Geschäftsregeln kaum sauber beschrieben sind. Dann wird der Neubau teuer, obwohl die Präsentation vorher überzeugend wirkte.
Meine These: Ein früher Komplett-Rewrite ist in Legacy-Vorhaben öfter ein Beschaffungsfehler als ein Technikfehler. Zielarchitekturen lassen sich gut verkaufen. Die Rekonstruktion von Betriebswissen nicht. Genau dort entstehen die harten Überraschungen.
Wann lohnt sich Refaktorisierung?
Schlechter Code allein ist kein Grund für einen Neubau. Entscheidend ist, ob das System noch änderbar, testbar, beobachtbar und betrieblich beherrschbar gemacht werden kann. Wenn diese vier Eigenschaften mit vertretbarem Aufwand wiederherstellbar sind, ist Refaktorisierung meist die bessere Wette.
Das gilt besonders bei Systemen, deren Fachlogik seit Jahren reale Geschäftsprozesse korrekt abbildet: Abrechnung, Freigaben, Preisregeln, Vertragslogik, Ausnahmen. Solche Regeln stehen selten vollständig in Dokumentationen. Sie stecken im Verhalten des Systems, in Supportfällen und in den Routinen der Fachbereiche.
Für Refaktorisierung sprechen vor allem drei Signale: Kritische Abläufe lassen sich über Logs, Reports, Tickets oder Fachwissen nachvollziehen. Risiken können an Modulen, Schnittstellen oder Datenzugriffen isoliert werden. Und die Plattform ist noch supportfähig oder mit überschaubarem Aufwand auf einen unterstützten Stand bringbar.
Supportstatus ist dabei kein Nebenthema. Wenn Betriebssystem, Datenbank, Middleware oder Framework noch im Herstellersupport sind, bleibt Handlungsspielraum. Fehlt dieser Support, kippt die Entscheidung oft Richtung Neubau oder zumindest Richtung tiefere Erneuerung. Das ist ein objektiveres Kriterium als jede Geschmacksdebatte über alten Code.
Refaktorisierung wird oft mit kosmetischem Aufräumen verwechselt. Gemeint ist etwas anderes: kritische Pfade mit Tests absichern, Integrationskanten kapseln, riskante Abhängigkeiten herauslösen, Deployments stabilisieren und Beobachtbarkeit nachrüsten. Das ist kein Schönheitsprogramm. Es ist operative Risikoreduktion.
Ein nüchterner Blick auf Delivery hilft mehr als Architekturfolien. Wenn Releases selten sind, Änderungen regelmäßig Seiteneffekte auslösen und Wiederherstellung nach Fehlern zu lange dauert, frisst der Bestand Lieferfähigkeit. Die DORA-Metriken sind hier nützlich, aber nur als Betriebsindikator. Sie zeigen, ob ein System wirtschaftlich noch tragbar ist. Sie ersetzen keine Modernisierungsstrategie.
Zusätzlich sollte geprüft werden, ob sich der Bestand in sinnvolle Modernisierungseinheiten zerlegen lässt. Wenn ein Team einzelne Domänen, Schnittstellen oder Datenzugriffe separat härten kann, steigt die Erfolgschance deutlich. Fehlt jede sinnvolle Schnittkante, wird Refaktorisierung schnell zur Dauerbaustelle. Dann ist nicht der Code alt, sondern die Änderungsökonomie kaputt.
Ein Punkt wird in Unternehmen regelmäßig unterschätzt: Refaktorisierung schützt vorhandene Abnahmefähigkeit. Fachbereiche kennen das Verhalten des Systems, auch wenn sie es nicht formal dokumentiert haben. Wer schrittweise umbaut, kann mit Referenzfällen, Parallelvergleichen und enger Rückkopplung arbeiten. Das ist mühsam, aber beherrschbar. Ein kompletter Neubau zwingt dieselben Fachbereiche dagegen oft zu einer Vollabnahme unter Zeitdruck.
Alt ist nicht das Problem. Unbeherrschbar ist das Problem.
Wer einen schrittweisen Umbau prüfen will, findet in Legacy-Modernisierung als geplanter Umbau einen sinnvollen Bezugsrahmen. Gerade bei tragfähiger Fachlogik ist kontrollierte Entkopplung oft vernünftiger als ein kompletter Neustart.
Wann ist ein Rewrite sinnvoll?
Ein Rewrite braucht eine höhere Beweislast. Er geht länger in Vorleistung, verschiebt Nutzen nach hinten und erhöht das Risiko fachlicher Abweichungen. Der Satz „der Code ist zu alt“ reicht nicht. Tragfähige Gründe sind härter.
Ein Neubau ist sinnvoll, wenn zentrale Komponenten aus dem Herstellersupport gefallen sind und sich das Risiko nicht wirtschaftlich entschärfen lässt. Ohne Sicherheitsaktualisierungen wird technische Schuld schnell zu einem Governance- und Betriebsproblem. Das gilt besonders für Systeme mit sensiblen Daten, externen Schnittstellen oder hoher Verfügbarkeitsanforderung.
Typisch ist ein Bestand, in dem Mandantenlogik, Berechtigungen und Datenzugriffe tief ineinander verschachtelt sind. Jede neue Region, jedes neue Produkt und jede zusätzliche Compliance-Vorgabe zieht dann Änderungen durch denselben alten Kern. Wenn saubere Mandantenfähigkeit, klar getrennte Domänen, API-zentrierte Integration oder ein belastbares Sicherheitsmodell nur noch mit unverhältnismäßigem Aufwand nachrüstbar wären, ist Refaktorisierung oft nur eine teure Verzögerung.
Manchmal verliert der Bestand sogar seine Referenzfunktion. Wenn niemand mehr belastbar erklären kann, warum das System in Grenzfällen so reagiert, wie es reagiert, wird jede Änderung zum Blindflug. Paradoxerweise kann genau das einen Rewrite rechtfertigen. Nicht weil Neubau einfacher wäre, sondern weil der Bestand fachlich nicht mehr verlässlich als Maßstab dient.
Ebenso kritisch ist der organisatorische Bruch. Wenn das Unternehmen in kurzer Zeit neue Produkte, neue Regionen, neue Mandantenmodelle oder neue Compliance-Anforderungen bedienen muss, kann ein Bestandssystem zum strukturellen Engpass werden. Dann ist nicht nur der Code das Problem, sondern das Betriebsmodell. Ein Rewrite ist in solchen Fällen kein Luxus, sondern eine Reaktion auf veränderte Marktanforderungen.
Hier wird in Angeboten oft zu weich formuliert. Ich formuliere es absichtlich härter: Wer Vollparität verspricht, ohne bewusst Altlasten zu streichen, verkauft meist Unsicherheit als Komfort. In Legacy-Modernisierung ist „alles bleibt, nur moderner“ einer der teuersten Sätze im Projekt.
Für den Übergang bleibt das Strangler-Muster relevant. Microsoft Azure beschreibt es als schrittweisen Ersatz von Funktionen statt eines Umschalttags mit Gesamtrisiko. Der Punkt ist nicht methodische Eleganz. Der Punkt ist, dass Wissen, Daten und Betriebszustände nicht gleichzeitig neu entstehen. Sie müssen kontrolliert überführt werden.
Aus Projektsicht wird der Unterschied sehr konkret: Ein Rewrite bindet Monate an Vorleistung in Architektur, Datenmodell, Testaufbau und neue Integrationen, bevor die erste belastbare Fachabnahme überhaupt möglich ist. Gleichzeitig steigt das Migrationsrisiko, weil historische Sonderfälle erst spät sichtbar werden. Wenn dieser Vorlauf nicht durch klare Zielvorteile gedeckt ist, kaufen Sie vor allem Abnahmeaufwand und spätere Korrekturschleifen ein.
Kosten, Nutzen und versteckte Aufwände realistisch bewerten
Bei Refaktorisierung oder Neuschreiben wird zu oft über Entwicklungskosten gesprochen und zu selten über Übergangskosten. Genau dort kippt die Wirtschaftlichkeit. Datenmigration, Parallelbetrieb, Testdaten, Fachabnahme, Schulung, Monitoring, Rückfalloption und temporäre Doppelpflege sind keine Nebenkosten. Sie sind oft der eigentliche Preis der Entscheidung.
Refaktorisierung wirkt auf dem Papier manchmal teurer, weil sie weniger spektakulär aussieht und mehr operative Disziplin verlangt. Ein Rewrite wirkt dagegen sauber budgetierbar, weil ein neues Team auf einer neuen Basis startet. Diese Klarheit ist häufig trügerisch. Sobald reale Sonderfälle, historische Daten und Integrationen auftauchen, wird aus dem vermeintlich sauberen Neubau ein langes Übergangsprogramm.
Ich habe in der Praxis öfter gesehen, dass Unternehmen den Neubau als Kostenkontrolle verkaufen, obwohl sie in Wahrheit Unsicherheit nur in spätere Projektphasen verschieben. Das ist kein kleiner Unterschied. Es verändert Beschaffung, Steuerung und Erwartungsmanagement.
Die erste entscheidende Frage lautet: Wann entsteht der erste messbare Nutzen im Betrieb und nicht nur auf dem Projektplan? Danach folgen drei weitere Punkte, die in realen Entscheidungen fast immer den Ausschlag geben: Wie teuer wird fachliche Gleichwertigkeit im Übergang, welche Option senkt das Betriebsrisiko innerhalb der nächsten 12 bis 18 Monate und welche Variante bindet die knappen Fachverantwortlichen am längsten? Gerade diese letzte Frage wird in Business Cases systematisch zu klein gerechnet.
Refaktorisierung liefert Nutzen früher, wenn kritische Pfade priorisiert werden. Das kann eine stabilere Integrationsstrecke sein, ein entkoppelter Importprozess oder ein abgesicherter Abrechnungsablauf. Ein Rewrite bietet zwar mehr architektonischen Freiheitsgrad, verlangt dafür aber längere Vorleistung und eine deutlich härtere Rekonstruktion des Ist-Verhaltens.
