Neu schreiben vs. Refactoring: Ein Entscheidungsframework für Legacy-Systeme

Die Entscheidung, die Karrieren entgleisen lässt

Irgendwo in einem Sitzungssaal trifft gerade ein CTO eine der folgenreichsten Entscheidungen in der Software: Sollen wir dieses System von Grund auf neu schreiben oder weiter refaktorieren, was wir haben?

In beide Richtungen falsch entschieden, sind die Folgen gravierend. Greenfield-Rewrites geraten bekanntermaßen außer Kontrolle – Netscapes Entscheidung von 1999, seinen Browser von Grund auf neu zu schreiben, hätte das Unternehmen beinahe zerstört, und das Muster hat sich seitdem dutzendfach in Konzernen wie Startups wiederholt. Doch sich zu weigern, eine wirklich unwartbare Codebasis zu modernisieren, ist genauso teuer: Die Entwicklergeschwindigkeit verschlechtert sich, Talente gehen, und die Wartungslast verschlingt einen immer größeren Anteil des Engineering-Budgets.

Die Entscheidung ist schwer, nicht weil die technischen Daten mehrdeutig wären, sondern weil sie emotional aufgeladen ist. Entwickler, die das bestehende System gebaut haben, verteidigen es. Entwickler, die es geerbt haben, wollen es niederbrennen. Das Management sieht einen Rewrite als Momentum, selbst wenn er Risiko ist. Das Ergebnis ist eine Entscheidung aus dem Bauch heraus, aus Politik und Gefühl statt aus einer nüchternen Bewertung der Evidenz.

Dieser Beitrag liefert ein strukturiertes Framework, um diese Entscheidung zu treffen. Es umfasst die vier Dimensionen, die die richtige Antwort tatsächlich bestimmen – Gesundheit der Codebasis, Geschäftsrisiko, Teamfähigkeit und Zeit-Constraints – und gibt Ihnen einen Bewertungsansatz, den Sie Stakeholdern mit Selbstvertrauen präsentieren können.

Warum die Rewrite-Option meist überschätzt wird

Bevor wir ins Framework einsteigen, lohnt es sich, einer systematischen Verzerrung ins Auge zu sehen: Engineering-Teams überschätzen durchgängig, wie viel besser ein Rewrite sein wird, und unterschätzen, wie lange er dauern wird.

Die Grundursache ist das, was Joel Spolsky als die Tendenz beschrieb, unbekannten Code mit schlechtem Code zu verwechseln. Wenn Sie ein System erben, das Sie nicht gebaut haben, fühlt sich jede Eigenheit wie ein Bug an. Jede Designentscheidung sieht falsch aus. Der natürliche Instinkt ist, von vorne anzufangen.

Aber Legacy-Systeme tragen angesammeltes Wissen, das unsichtbar ist, bis es weg ist. Die Edge Cases, die seltsam aussehende bedingte Logik verursacht haben. Die Performance-Workarounds für eine Datenbankabfrage, die zehntausendmal am Tag aufgerufen wird. Der Fehlerbehandlungscode, der redundant erscheint, bis sich eine Drittanbieter-API um 2 Uhr nachts unerwartet verhält. Ein Rewrite verwirft dieses Wissen und muss es neu entdecken – meist in der Produktion.

Die Datenlage zu Software-Rewrites ist nicht ermutigend. Studien über Enterprise-Software-Projekte hinweg zeigen durchgängig, dass Rewrites von Grund auf zwei- bis viermal länger dauern als geschätzt, häufig das Budget sprengen und oft dieselbe zugrunde liegende Funktionalität zu höheren Gesamtkosten liefern, als es eine strukturierte Modernisierung getan hätte.

Das ist kein Argument gegen Rewrites – es ist ein Argument dafür, eine hohe Hürde zu setzen, bevor man sich für einen entscheidet.

Das Bewertungsframework mit vier Dimensionen

Jede der vier Dimensionen unten erhält einen Wert von 0 bis 25, für ein Maximum von insgesamt 100. Ein Wert unter 40 spricht für Refactoring. Ein Wert zwischen 40 und 65 deutet auf einen hybriden Ansatz hin (inkrementelle Modernisierung, oft als Strangler-Fig-Pattern bezeichnet). Ein Wert über 65 ist der Bereich, in dem ein Rewrite vertretbar wird.

Dimension 1: Gesundheit der Codebasis (0–25 Punkte)

Diese misst, wie schwer der bestehende Code zu verstehen, zu ändern und zu testen ist. Nützliche Signale:

Zyklomatische Komplexität. Eine Codebasis, in der Funktionen routinemäßig Komplexitätswerte über 15–20 haben, ist eine, in der nicht einmal die Autoren die Logik im Kopf halten können. Vergeben Sie 5 Punkte, wenn mehr als 20 % der Funktionen diese Schwelle überschreiten.

Testabdeckung. Produktivsysteme mit weniger als 40 % Testabdeckung sind nicht sicher in großem Maßstab zu refaktorieren – jede Änderung riskiert unbekannte Regressionen. Vergeben Sie 5 Punkte, wenn die Abdeckung unter 40 % liegt.

Kopplung und Abhängigkeitsgesundheit. Zirkuläre Abhängigkeiten, enge Kopplung zwischen nicht verwandten Modulen und über die Codebasis verstreuter globaler Zustand machen Refactoring gefährlich ohne erhebliche Vorab-Investition in Testinfrastruktur. Vergeben Sie 5 Punkte, wenn der Abhängigkeitsgraph mehr als eine Handvoll zirkulärer Pfade hat.

Technologie-End-of-Life. Eine PHP-5.6-Anwendung ist nicht nur Legacy – sie ist ein Sicherheitsrisiko auf einer Laufzeit ohne Herstellersupport. Vergeben Sie 5 Punkte, wenn die Laufzeit oder das Framework jenseits von End-of-Life ohne Upgrade-Pfad ist.

Onboarding-Friktion. Fragen Sie Ihre letzten drei neuen Entwickler, wie lange es dauerte, bis sie ihren ersten sinnvollen Beitrag leisteten. Wenn die Antwort mehr als drei Wochen lautet, vergeben Sie 5 Punkte.

Für die meisten ausgereiften Legacy-Systeme, denen wir in Legacy-Code-Optimierung-Engagements begegnen, liegt ein realistischer Wert auf dieser Dimension bei 10–15.

Dimension 2: Geschäftsrisiko (0–25 Punkte)

Diese misst, was ein Rewrite das Unternehmen an Risiko und Disruption kosten würde, nicht nur an Engineering-Zeit.

Umsatzabhängigkeit. Wenn das betrachtete System die zentrale umsatzgenerierende Anwendung ist – kein Backoffice-Tool –, ist das Risiko eines Rewrites existenziell. Vergeben Sie 0–5 je nach Zentralität des Systems für den Umsatz: 0 für periphere Tools, 5 für das System, das jede Transaktion verarbeitet.

Regulatorische und Compliance-Exposition. Finanzdienstleistungen, Gesundheitswesen und Behördensoftware operieren unter Compliance-Regimen, die ein Rewrite von Tag eins an navigieren muss. Eine Compliance-Anforderung während der Übergangsphase zu verfehlen, ist ein rechtliches Risiko, nicht nur ein technisches. Vergeben Sie 0–5 Punkte je nach regulatorischer Komplexität.

Integrations-Oberfläche. Ein System mit 25 ein- und ausgehenden Integrationen – ERP-Systeme, Zahlungsabwickler, externe APIs, Partner-Feeds – hat eine Rewrite-Oberfläche, die mit jeder Verbindung wächst. Vergeben Sie 0–5 Punkte je nach Anzahl und Kritikalität der Integrationen.

Betriebliches Wissens-Lock-in. Wie viel betriebliches Wissen existiert nur in den Köpfen der Menschen, die das aktuelle System gebaut haben? Wenn diese Personen nicht verfügbar oder nicht mehr im Unternehmen sind, verliert ein Rewrite den Zugang zum institutionellen Gedächtnis, das erklärt, warum sich das System so verhält, wie es das tut. Vergeben Sie 0–5 Punkte je nach Wissenskonzentration.

Wettbewerbliches Timing. Steht das Unternehmen unter Wettbewerbsdruck, der einen 12–18-monatigen Rewrite untragbar macht? Oder gibt es ein stabiles Fenster, in dem die Investition strategisch sinnvoll ist? Vergeben Sie 0–5 Punkte: 5, wenn der Zeitdruck hoch ist, 0, wenn es ein klares Fenster gibt.

Dimension 3: Teamfähigkeit (0–25 Punkte)

Ein Rewrite erfordert spezifische Fähigkeiten, die sich von denen unterscheiden, die zum Warten und Refaktorieren eines Legacy-Systems nötig sind. Diese Dimension bewertet die Lücke zwischen dem, was ein Rewrite braucht, und dem, was Ihr Team aktuell hat.

Erfahrung im Architekturdesign. Von vorne anzufangen erfordert jemanden, der belastbare Entscheidungen über Datenmodelle, Service-Grenzen, API-Verträge und Infrastrukturwahl treffen kann. KI-gestützte Entwicklung und Vibe Coding können Code schnell scaffolden, aber architektonische Integrität erfordert Urteilsvermögen, das daher kommt, solche Entscheidungen schon getroffen – und daraus gelernt – zu haben. Vergeben Sie 5 Punkte, wenn dem Team ein Senior-Architekt mit relevanter Domänenerfahrung fehlt.

Full-Stack-Verantwortung. Rewrites geraten oft ins Stocken, wenn Frontend- und Backend-Teams unterschiedliche Annahmen über den API-Vertrag oder das Datenmodell haben. Vergeben Sie 5 Punkte, wenn es keinen klaren technischen Eigentümer mit Autorität über das Gesamtsystem gibt.

Test- und CI/CD-Disziplin. Ein Rewrite, der ohne starke Testabdeckung und Continuous-Deployment-Infrastruktur ausgeliefert wird, reproduziert die Wartbarkeitsprobleme des Legacy-Systems schlicht innerhalb von 18 Monaten. Vergeben Sie 5 Punkte, wenn das Team historisch Produktivsysteme ohne automatisierte Testsuiten ausgeliefert hat.

Domänenwissen. Die gefährlichsten Rewrites passieren, wenn das Team, das das neue System baut, nicht versteht, warum sich das Legacy-System so verhält, wie es das tut. Geschäftsregeln, die willkürlich aussehen, haben oft historische Gründe. Vergeben Sie 5 Punkte, wenn das Domänenwissen auf ein oder zwei Personen konzentriert ist, die nicht stark in den Rewrite eingebunden sein werden.

Kapazität für Parallelbetrieb. Die meisten verantwortungsvollen Rewrites erfordern, beide Systeme während des Übergangs parallel zu betreiben, mit Datensynchronisation und Cutover-Planung. Vergeben Sie 5 Punkte, wenn dem Team die Kapazität fehlt, beide Systeme gleichzeitig zu warten.

Dimension 4: Zeit- und Kosten-Constraints (0–25 Punkte)

Die letzte Dimension verankert die Analyse in praktischen Constraints, die das theoretische Ideal oft überschreiben.

Finanzierungssicherheit. Ein Rewrite, der für sechs Monate finanziert ist, realistisch aber achtzehn dauert, ist ein gescheiterter Rewrite. Vergeben Sie 5 Punkte, wenn die Finanzierung für den realistischen Zeitrahmen nicht gesichert ist.

Wartungskosten-Trajektorie. Berechnen Sie, was das aktuelle System jährlich an Wartung kostet – Entwicklerzeit für Bugfixes, Incident-Response, Deployment-Komplexität – und projizieren Sie sie nach vorne. Vergeben Sie 5 Punkte, wenn die aktuelle Trajektorie eine Schwelle überschreitet, an der das System innerhalb von 18–24 Monaten untragbar wird.

Inkrementelle Lieferbarkeit. Kann Refactoring auf monatlicher Basis sinnvolle Verbesserungen liefern, Stakeholder eingebunden halten und Risiko reduzieren, während es Wert liefert? Oder ist das System so tief gekoppelt, dass inkrementelle Arbeit keinen sichtbaren Fortschritt erzeugt? Vergeben Sie 5 Punkte, wenn die Struktur der Codebasis inkrementelle Verbesserung unplausibel macht.

Wettbewerbliche Feature-Lücke. Fällt das Unternehmen hinter Wettbewerber zurück, nicht wegen der Marktstrategie, sondern weil die Technologie Features nicht schnell genug ausliefern kann? Vergeben Sie 5 Punkte, wenn die Engineering-Geschwindigkeit der Hauptengpass für die Umsetzung der Produkt-Roadmap ist.

Externe Forcing Function. Gibt es eine harte Deadline – eine Vertragsverlängerung, ein Compliance-Audit, ein Infrastruktur-End-of-Life-Datum –, die den Zeitrahmen unabhängig vom Umfang nicht verhandelbar macht? Vergeben Sie 5 Punkte, wenn ein hartes Constraint die Entscheidung faktisch binär macht.

Den Score interpretieren

Sobald Sie Werte über alle vier Dimensionen haben, sagt Ihnen die Gesamtsumme, in welche Richtung Sie tendieren sollten – aber sie sagt Ihnen auch, welche Dimensionen die Entscheidung treiben, was ebenso wichtig ist wie die Gesamtsumme.

Ein hoher Wert bei Gesundheit der Codebasis kombiniert mit einem niedrigen Wert beim Geschäftsrisiko deutet darauf hin, dass ein Rewrite technisch gerechtfertigt, aber strategisch riskant ist. Die richtige Antwort ist meist inkrementelle Modernisierung: die Codebasis systematisch verbessern, während das Geschäft betriebsfähig bleibt, mit Mustern wie Strangler Fig, um Hochrisiko-Komponenten schrittweise zu ersetzen.

Ein hoher Wert bei Teamfähigkeit mit einem niedrigen Wert bei Gesundheit der Codebasis deutet darauf hin, dass das Team die Fähigkeiten hat, einen Rewrite erfolgreich durchzuführen, die Codebasis aber vielleicht nicht so verloren ist, wie es sich anfühlt. Ein Code-Quality-Audit offenbart oft, dass die schlimmsten Probleme in 20–30 % der Codebasis konzentriert sind und gezieltes Refactoring dieser Komponenten 80 % des Nutzens zu einem Bruchteil der Rewrite-Kosten erzeugt.

Ein Wert über 65, bei dem alle vier Dimensionen sinnvoll beitragen – die Codebasis ist wirklich unwartbar, das Team ist fähig, der Zeitrahmen ist tragfähig und das Geschäftsrisiko ist beherrschbar –, ist das Szenario, in dem ein Rewrite die richtige Entscheidung ist. Diese Situationen existieren, aber sie sind seltener, als der emotionale Sog zum „Neuanfang“ vermuten lässt.

Der hybride Weg, den die meisten Teams gehen sollten

In der Praxis fällt die Mehrheit der Legacy-Systeme, die wir in Tech-Stack-Strategie-Engagements bewerten, in den Bereich 35–65 – klar mit erheblichem Modernisierungsbedarf, aber keine guten Kandidaten für einen Rewrite von Grund auf.

Der wirksamste Ansatz in diesem Bereich ist strukturierte inkrementelle Modernisierung:

Identifizieren Sie den Blast Radius. Welche Komponenten des Legacy-Systems verursachen die meisten Incidents, die meiste Entwickler-Friktion und die meisten Einschränkungen bei der Auslieferung neuer Features? Diese werden zu den ersten Zielen.

Errichten Sie zuerst das Sicherheitsnetz. Bevor Sie Produktionscode anfassen, investieren Sie 2–4 Wochen in das Hinzufügen von Charakterisierungstests, die das aktuelle Verhalten der risikoreichsten Komponenten dokumentieren. Diese Investition zahlt sich sofort aus, indem sie nachfolgende Änderungen sicher macht.

Wenden Sie das Strangler-Fig-Pattern an. Bauen Sie neue Funktionalität als separate, moderne Services oder Module, die mit dem Legacy-System koexistieren. Leiten Sie den Traffic schrittweise von alt nach neu. Dieser Ansatz hält das System durchgehend betriebsfähig und liefert sichtbaren Fortschritt an Stakeholder.

Verfolgen Sie die Reduktion der Wartungskosten. Messen Sie die für Wartung aufgewendeten Entwicklerstunden vor und nach jedem Modernisierungszyklus. Diese Daten bauen den Business Case für fortgesetzte Investition und machen den Prozess für nicht-technische Stakeholder lesbar.

Dieser Ansatz reduziert Wartungskosten typischerweise um 35–45 % innerhalb von 12 Monaten, während das System in kontinuierlicher Produktion bleibt – ein Ergebnis, das ein Big-Bang-Rewrite im selben Zeitrahmen selten erreicht, weil die Vorteile des Rewrites aufgeschoben werden, bis das neue System vollständig live ist.

Den Fall gegenüber Stakeholdern vertreten

Das Bewertungsframework ist gerade deshalb wertvoll, weil es eine belastbare Empfehlung erzeugt. „Der Code ist schlecht und wir sollten ihn neu schreiben“ ist kein Business Case. Ein strukturiertes Argument, das sagt „Das System erreicht 71 auf unserer Vier-Dimensionen-Bewertung, die Wartungskosten-Trajektorie überschreitet unsere Tragfähigkeitsschwelle im dritten Quartal nächsten Jahres, und die Bewertung der Teamfähigkeit legt nahe, dass wir vor Beginn Senior-Architektur-Unterstützung hinzuziehen müssen“, ist ein Business Case.

Für CTOs, die dieses Gespräch mit Boards, CFOs oder Gründern führen, die großen technischen Investitionen skeptisch gegenüberstehen, ist der nützlichste Rahmen Kostenvermeidung: Was kostet die aktuelle Trajektorie, und was kostet die vorgeschlagene Alternative? Wenn Sie zeigen können, dass das aktuelle System in zwei Jahren das 2,5-Fache des Engineering-Budgets erfordert, um denselben Output zu erhalten, hört die Investition in Modernisierung auf, wie ein Luxus auszusehen, und beginnt, wie Risikomanagement auszusehen.

Eine zweite Meinung einholen

Ein Muster, das wir regelmäßig in Code-Quality-Consulting-Engagements sehen, ist, dass die Debatte „neu schreiben vs. refaktorieren“ seit 12–18 Monaten innerhalb einer Organisation läuft, Führungsaufmerksamkeit verschlingt und Team-Friktion erzeugt, wo eine externe technische Bewertung sie in zwei bis drei Wochen hätte auflösen können.

Externe Prüfer bringen zwei Dinge mit, die interne Teams nicht haben: Sie haben mehr Codebasen gesehen (was die Schweregrad-Bewertung kalibriert), und sie haben keinen emotionalen Anteil am bestehenden System. Ein Senior-Entwickler, der zwanzig PHP-Monolithen modernisiert hat, kann Ihnen an einem Tag sagen, ob Ihr System im obersten Quartil der Komplexität liegt oder im untersten – ein Kontext, der von innerhalb einer einzelnen Organisation sehr schwer zu entwickeln ist.

Wenn Sie mitten in dieser Entscheidung stecken, erwägen Sie, die interne Debatte mit einer externen technischen Bewertung zu verankern, bevor Sie in die eine oder andere Richtung Budget binden. Die Kosten der Bewertung sind ein Rundungsfehler im Vergleich zu den Kosten der falschen Entscheidung.

Wolf-Tech bietet für genau solche Situationen kostenlose Erstberatungen an. Melden Sie sich unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io – und lassen Sie uns Ihre Codebasis mit frischem Blick betrachten.