Refaktorisierung oder Neuschreiben: So entscheiden Sie treffsicher
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.
Für Käufer ist die entscheidende Frage nicht, welche Option theoretisch eleganter ist. Die bessere Option ist die, bei der Nutzen, Risiko und Übergangskosten zusammenpassen. Wenn ein Anbieter nur den Entwicklungsaufwand zeigt, aber nicht die Kosten des Übergangsmodells, fehlt die halbe Rechnung.
Ein beobachtbares Muster aus Modernisierungsvorhaben: Die teuersten Überraschungen entstehen selten im Coding, sondern in der Phase, in der Fachbereich und Betrieb bestätigen sollen, dass das neue Verhalten wirklich tragfähig ist. Genau dort kippen Termine, weil Grenzfälle, manuelle Workarounds und alte Datenzustände plötzlich wieder wichtig werden. Wer das im Einkauf nicht einpreist, bewertet nur die halbe Realität.
Angebote und Audits prüfen: Woran Käufer gute von gefährlichen Vorhaben trennen
Wenn Budget freigegeben wird, wird nicht nur Entwicklungsleistung eingekauft. Eingekauft wird Übergangsfähigkeit. Genau deshalb sind viele Angebote operativ zu dünn. Die Zielarchitektur ist sauber gezeichnet, aber Datenmigration, Rückfalloption und fachliche Abnahme bleiben vage. Dort sitzen später die Kosten.
Vor einer Richtungsentscheidung braucht es kein monatelanges Vorprojekt, aber ein Audit mit Substanz. Vier Dinge sollten vorliegen: eine Systemlandkarte mit Abhängigkeiten und kritischen Datenflüssen, eine Sicht auf geschäftskritische Prozesse und Ausnahmen, ein Überblick zu Supportstatus und Sicherheitslage zentraler Komponenten sowie ein grober Übergangspfad mit Pilotbereich und Abnahmekriterien.
Fehlt fast alles davon, lautet die richtige Entscheidung oft weder Refaktorisierung noch Rewrite, sondern zuerst Discovery. Das wirkt langsamer, ist aber meist billiger als ein falsch gestartetes Großprojekt. Ich sehe dabei immer wieder dasselbe Muster: Unternehmen wollen Tempo einkaufen, obwohl ihnen zuerst Entscheidungsfähigkeit fehlt.
Ohne belastbare Ausgangslage sollte kein Einkauf ein großes Rewrite-Budget freigeben. Sonst wird nicht Modernisierung finanziert, sondern eine teure Wette mit zu geringer Audit-Tiefe, unklaren Nicht-Zielen und hoher Wahrscheinlichkeit für spätere Korrekturschleifen.
Seriöse Anbieter fragen früh nach Incident-Historie, Release-Prozess, Integrationsliste, Supportstatus, Zugriff auf Fachverantwortliche und realen Sonderfällen aus dem Betrieb. Wer ohne diese Grundlagen sehr schnell einen Komplettneubau empfiehlt, optimiert oft eher auf Projektvolumen als auf Risikoreduktion.
Prüfen Sie Angebote deshalb nicht zuerst nach Tagessatz oder Teamgröße. Prüfen Sie, ob das Vorhaben die unangenehmen Fragen beantwortet: Wie wird fachliche Gleichwertigkeit nachgewiesen? Welche Daten werden wann migriert? Wo beginnt der Pilot? Wer trägt die Betriebsverantwortung im Übergang? Was wird bewusst nicht übernommen?
Im deutschsprachigen Markt blockiert oft nicht die Technik zuerst, sondern die Freigabekette: Einkauf will Preis- und Vertragsklarheit, Informationssicherheit fordert belastbare Betriebs- und Zugriffsmodelle, Datenschutz verlangt einen sauberen Migrationspfad für personenbezogene Daten, und der Fachbereich akzeptiert keine lange Phase ohne verlässliche Abnahme. Ein Anbieter, der nur Architektur und Liefergeschwindigkeit verkauft, scheitert intern häufig genau an diesen Punkten.
Wenn personenbezogene Daten, revisionsrelevante Historien oder vertraglich gebundene Integrationen im Spiel sind, verändern Governance und Compliance die Entscheidung spürbar. Dann reicht es nicht, dass eine neue Lösung technisch besser ist. Sie muss auch nachweisbar migrierbar, prüfbar und im Übergang kontrollierbar sein. Genau deshalb sind Standards und Vorgaben nur dann relevant, wenn sie Architektur, Kosten oder Rollout tatsächlich verändern. In solchen Fällen tun sie das massiv.
Eine typische Musterkonstellation ist unspektakulärer als viele Angebotsfolien: Das Kernsystem enthält brauchbare Fachlogik, aber drei fragile Integrationen, fehlende Vertragstests und eine instabile Deployment-Strecke bremsen jede Änderung. Ein Komplett-Rewrite löst dieses Problem nicht automatisch. Häufig ist es sinnvoller, zuerst die Integrationskanten zu stabilisieren, Tests aufzubauen und nur klar untragbare Module neu zu entwickeln.
In einem Handelsumfeld mit mehreren angebundenen Drittsystemen war genau diese Reibung der Kostentreiber: nicht der alte Kern, sondern die heikle Umschaltung der Integrationen und die Abnahme der Sonderfälle im laufenden Betrieb. Der eigentliche Rollout wurde dadurch schwerer als die technische Umsetzung des ersten Modernisierungsschritts.
Wer ähnliche Muster erkennt, sollte auch Warnsignale bei wachstumshemmender Legacy prüfen. Dort wird schneller sichtbar, ob wirklich der Kern das Problem ist oder eher die Umgebung aus Prozessen, Schnittstellen und Betrieb.
Der Migrationspfad entscheidet mehr als die Zielarchitektur
Die Qualität der Entscheidung zeigt sich im Übergang. Ein Rewrite ohne Migrationspfad ist kein Plan. Eine Refaktorisierung ohne Priorisierung kritischer Pfade ebenfalls nicht. In beiden Fällen fehlt die operative Logik, die aus Technik eine belastbare Veränderung macht.
Ein tragfähiger Pfad beginnt mit einem Pilotbereich, der geschäftlich relevant, aber begrenzt genug für kontrollierte Lieferung ist. Gute Kandidaten sind ein klar umrissener Importprozess, Reporting, Authentifizierung oder eine Integrationskante mit hohem Änderungsdruck. Schlechte Kandidaten sind diffuse Querschnittsthemen, deren Nutzen erst ganz am Ende sichtbar wird.
Parallelbetrieb ist sinnvoll, wenn fachliche Gleichwertigkeit nicht allein vorab getestet werden kann. Dafür braucht es keine perfekte Doppelwelt, aber klare Regeln: welche Daten synchronisiert werden, welche Nutzergruppen zuerst wechseln, wie Abweichungen erkannt werden und wer im Zweifel den Rückfall entscheidet.
Big Bang sollte ausgeschlossen werden, wenn historische Daten revisionssicher übernommen werden müssen, kritische Integrationen keine realistische Testumgebung haben, Fachbereiche keine lange Änderungssperre tragen oder eine belastbare Rückfalloption fehlt. In solchen Lagen ist Big Bang selten mutig. Meist ist es nur die Verpackung für fehlende Migrationsarbeit.
Ein belastbarer Migrationspfad braucht außerdem messbare Zwischenziele. Dazu gehören etwa sinkende Fehlerquote in einem Teilprozess, kürzere Wiederherstellungszeit, weniger manuelle Eingriffe oder eine klar reduzierte Abhängigkeit von einzelnen Altkomponenten. Ohne solche Zwischenziele bleibt Modernisierung ein Glaubensprojekt. Mit ihnen wird sie steuerbar.
Bei einem typischen Monolithen mit nächtlichem Batchlauf und mehreren Direktzugriffen auf dieselbe Datenbank beginnt die Arbeit nicht mit dem Ersetzen des Kerns. Zuerst werden die kritischen Jobs, Fehlerraten und Laufzeiten instrumentiert, damit sichtbar wird, wo der Betrieb tatsächlich kippt. Danach werden die riskantesten Datenzugriffe und Integrationspunkte isoliert, etwa über klar definierte Schnittstellen oder einen entkoppelten Importdienst. Erst wenn diese Kanten stabil sind, lohnt sich die selektive Ersetzung einzelner Module. Wer diese Reihenfolge ignoriert, modernisiert im Blindflug.
Ein konkretes Muster für kontrollierte Ablösung zeigt eine modernisierte Legacy-Desktop-Anwendung. Solche Vorhaben wirken nach außen oft unspektakulär. Im Betrieb ist genau das meist ein gutes Zeichen.
Entscheidung für Führung, Einkauf und Technik
Die beste Entscheidung entsteht selten in einer einzelnen Architekturrunde. Führung, Einkauf, Betrieb, Sicherheit und Fachbereich müssen dieselbe Richtung tragen. Sonst wird aus einer technischen Entscheidung ein monatelanger Abstimmungskonflikt.
Hilfreich ist eine einfache Priorisierung entlang von fünf Fragen: Ist der Bestand noch supportfähig? Ist die Fachlogik verlässlich rekonstruierbar? Lassen sich Risiken modular isolieren? Gibt es einen realistischen Pilot mit Rückfalloption? Welche Option verbessert die Lieferfähigkeit innerhalb der nächsten 12 bis 18 Monate?
Wenn drei dieser fünf Fragen klar für den Bestand sprechen, ist Refaktorisierung meist die vernünftigere Wahl. Wenn drei klar gegen den Bestand sprechen, sollte ein Neubau ernsthaft vorbereitet werden. Der Grenzfall dazwischen ist kein Zeichen für Unentschlossenheit, sondern für fehlende Fakten. Dann braucht es ein kurzes, hartes Audit statt einer großen Programmentscheidung.
Die unbequeme Wahrheit: Viele Unternehmen entscheiden zu früh auf Rewrite, weil ein Neubau intern leichter zu verkaufen ist als ein kontrollierter Umbau. Neu klingt nach Fortschritt. Refaktorisierung klingt nach Reparatur. Wirtschaftlich ist das oft genau falsch herum.
Am Ende zählt eine einfache Frage: Welche Option senkt das Geschäftsrisiko schneller, ohne die Lieferfähigkeit der nächsten 12 bis 18 Monate zu zerstören? Wenn darauf keine belastbare Antwort mit Pilot, Abnahme und Rückfalllogik vorliegt, ist die Entscheidung noch nicht reif. Dann sollte niemand einen Rewrite kaufen.