Refactoring oder Neubau? Eine Entscheidungshilfe
Gewachsene Software bauen Sie schrittweise um, solange Datenmodell und Plattform tragen; neu gebaut wird sie, wenn das Datenmodell nicht mehr passt oder die Plattform keine Updates mehr bekommt. Auch ein Neubau gelingt besser in Etappen als an einem Stichtag.
Der Wunsch nach einem Neubau hat eine Vorgeschichte. Kleine Änderungen dauern Wochen, bestimmte Module fasst niemand mehr gern an, und das Team schlägt vor, alles neu und diesmal richtig zu schreiben. Was hinter diesen Zeichen steckt, erklärt Technische Schulden erklärt für Geschäftsführer. Hier geht es um die Entscheidung, die danach ansteht: den Bestand Stück für Stück verbessern oder eine neue Anwendung entwickeln lassen.
Refactoring heißt dabei, die Struktur des Codes zu verbessern, ohne sein Verhalten zu ändern. Ein Neubau ersetzt die Anwendung durch eine neue, meist mit neuem Datenmodell und oft mit neuer Technik. Zwischen beiden liegt ein dritter Weg, der Neubau in Etappen, der weiter unten beschrieben ist. Wie eine Modernisierung im Einzelnen abläuft und wie Sie eine veraltete PHP-Version anheben, sind eigene Fragen, die hier nur am Rand vorkommen.
Ausgangslage
Warum Neubauten länger dauern als gedacht
Ein Neubau beginnt mit einer Schätzung des Funktionsumfangs, und diese Schätzung kennt nur das, was jemand aufgeschrieben hat. Die alte Anwendung enthält mehr: Sonderfälle für einzelne Kunden, Korrekturen nach Fehlern, Rundungsregeln, die vor Jahren mit der Buchhaltung abgestimmt wurden. Joel Spolsky hat das in seinem Blog im April 2000 am Beispiel von Netscape beschrieben: Wer Code wegwirft und von vorn beginnt, wirft das Wissen weg, das in den unschönen Stellen steckt. Netscape hatte bei Erscheinen der Beta von Version 6.0 fast drei Jahre lang keine größere neue Version ausgeliefert.
Martin Fowler beschreibt dasselbe Problem aus Sicht der Nutzer: Ein ernsthaftes IT-System zu ersetzen dauert lange, und die Nutzer können nicht so lange auf neue Funktionen warten. In der Zwischenzeit läuft die alte Anwendung weiter, braucht Updates und Fehlerbehebungen und wird weiter ergänzt, solange das Geschäft nicht stillsteht. Jede dieser Erweiterungen muss der Neubau nachholen, bevor er die alte Anwendung ablösen kann.
Ein Neubau braucht deshalb Gründe, die über den Zustand des Codes hinausgehen.
Kriterien
Datenmodell, Wissen, Technik, Geschäft
Gehen Sie die Zeilen mit Ihrem Entwicklerteam durch und markieren Sie je Zeile die Spalte, die für Ihre Anwendung zutrifft. Das Datenmodell wiegt am schwersten, weil sich darüber jede Funktion, jede Auswertung und jede Schnittstelle definiert.
Zur Zeile Pflegeaufwand: Eine Plattform kann im Browser schnell sein und trotzdem viel Betreuung verlangen, etwa wenn ein statischer Build, lang laufende PHP-Prozesse und ein eigener Application-Server zusammenspielen und nur wenige Menschen diese Kombination kennen. Wiegt dieser Aufwand schwerer als der Geschwindigkeitsgewinn, kann die Prüfung auch zu einer schlichteren Technik führen, die das Team selbst betreiben kann.
| Spricht für Refactoring | Spricht für Neubau | |
|---|---|---|
| Datenmodell | Die Tabellen bilden das Geschäft noch ab, es fehlen einzelne Felder oder Beziehungen | Das Geschäft hat sich grundlegend geändert, etwa von einem auf viele Mandanten oder von Einzel- auf Abo-Verkauf |
| Fachwissen | Die Regeln stehen vor allem im Code und lassen sich mit Tests festhalten | Die Regeln sind vollständig und aktuell beschrieben, oder sie gelten nicht mehr |
| Plattform | Sprache und Framework erhalten Sicherheitsupdates, ein Upgrade-Pfad ist dokumentiert | Für die Plattform gibt es keine Updates und keinen Weg zu einer unterstützten Version |
| Pflegeaufwand der Technik | Die Technik ist aufwendig, lässt sich aber Teil für Teil verschlanken | Der Betrieb verlangt Spezialwissen, das im Team nicht vorhanden ist und nicht aufgebaut werden soll |
| Geschäft während der Arbeit | Neue Funktionen müssen weiter erscheinen | Ein Stopp für neue Funktionen über Monate ist tragbar |
| Risiko | Viele kleine Umstellungen, jede einzeln rückgängig zu machen | Das Team kann eine große Umstellung an einem Stichtag absichern, mit Datenmigration und Rückweg |
| Erster Nutzen | Nach der ersten Etappe | Nach der vollständigen Umstellung |
Strangler-Muster
Neubau in Etappen
Martin Fowler hat den Weg zwischen Umbau und Neubau nach der Würgefeige benannt, einer Pflanze, die auf einem Baum keimt, ihn mit der Zeit umschließt und am Ende an seiner Stelle steht. Übertragen auf Software heißt das: Neue Teile wachsen neben der alten Anwendung, übernehmen deren Aufgaben Stück für Stück, und am Ende wird der alte Rest abgeschaltet. Fowler hat das Bild Anfang der 2000er-Jahre beschrieben und seinen Text im August 2024 überarbeitet.
Der Ablauf in vier Schritten:
Eingang bündeln: Vor die alte Anwendung kommt eine Stelle, über die alle Anfragen laufen, etwa ein Router auf dem Webserver. Sie entscheidet pro Adresse oder Funktion, ob die alte oder die neue Anwendung antwortet.
Ersten Teil wählen: Gut geeignet ist ein Bereich mit klaren Grenzen und spürbarem Nutzen, etwa der Export für die Buchhaltung oder das Kundenkonto. Vorher halten Tests fest, was der alte Teil tut; wie das ohne bestehende Tests geht, zeigt Legacy-Code ohne Tests.
Umleiten und beobachten: Die Anfragen für diesen Bereich gehen an den neuen Teil. Treten Fehler auf, schaltet der Router zurück.
Abschalten: Erst wenn der neue Teil eine Weile stabil läuft, wird der alte Code entfernt. Dann folgt die nächste Etappe.
Fowler nennt den Preis dieses Wegs offen: Es braucht eine Übergangsarchitektur, damit alte und neue Teile nebeneinander laufen, und dieser Code wird am Ende wieder weggeworfen. Besonders heikel ist die Datenhaltung. Greifen alte und neue Teile auf dieselbe Datenbank zu, bleibt das alte Datenmodell länger bestehen; bekommt der neue Teil eine eigene Datenbank, braucht es einen Abgleich in beide Richtungen.
Neubau in Etappen bedeutet nicht, die Anwendung in viele kleine Dienste zu zerlegen. Ein gut gegliederter Monolith ist für eine typische mittelständische Fachanwendung das passendere Ziel; die Gründe stehen in Microservices, die niemand bestellt hat.
Rechnung
Kosten beider Wege vergleichen
Eine vollständige Kostenrechnung stellt beide Wege mit allen Posten nebeneinander, auch mit denen, die im Angebot für einen Neubau leicht fehlen. Die folgenden Werte sind Annahmen für eine Fachanwendung, die seit mehreren Jahren läuft und rund zehn Monate Neubauzeit bräuchte. Ersetzen Sie sie durch die Werte aus Ihrem Befund.
Neubau an einem Stichtag:
Nachbau des Funktionsumfangs: 100 Personentage
Datenmigration mit Probeläufen: 10 Personentage
Pflege der alten Anwendung während der Bauzeit: 10 Monate zu je 1,5 Personentagen, also 15 Personentage
Summe: 100 + 10 + 15 = 125 Personentage
Neubau in Etappen:
Sechs Etappen zu je 15 Personentagen, also 90 Personentage
Übergangsarchitektur mit Router und Datenabgleich: 15 Personentage
Pflege der verbleibenden alten Teile: 12 Monate zu je 1 Personentag, also 12 Personentage
Summe: 90 + 15 + 12 = 117 Personentage
Damit stehen 125 Personentage für den Neubau am Stichtag gegen 117 Personentage für den Weg in Etappen, eine Differenz von 8 Personentagen oder gut 6 Prozent. Multiplizieren Sie beide Summen mit dem Tagessatz aus Ihrem Angebot; am Verhältnis ändert das nichts.
Die Differenz ist klein. Für die Wahl zählen zwei Unterschiede, die in der Summe nicht auftauchen. Der erste: Beim Weg in Etappen bringt die erste Etappe nach etwa zwei Monaten Nutzen, beim Neubau am Stichtag erst die Umstellung nach zehn. Der zweite: Die größte Zahl der Rechnung, die 100 Tage Nachbau, ist zugleich die unsicherste, weil sie nur den Funktionsumfang kennt, den jemand aufgeschrieben hat. Bei Etappen fällt eine Fehlschätzung nach der ersten Etappe auf, beim Neubau unter Umständen erst kurz vor dem Stichtag.
Festhalten
Die Entscheidung dokumentieren
Halten Sie die Entscheidung auf einer Seite fest, bevor die Arbeit beginnt. Diese Angaben gehören hinein:
Ergebnis der Tabelle: welche Zeilen für welchen Weg sprechen, mit einem Satz Begründung je Zeile.
Annahmen der Rechnung: jede Zahl mit ihrer Herkunft, etwa aus einem Befund oder aus einer Schätzung des Teams.
Erste Etappe oder erster Meilenstein: was danach messbar anders ist.
Abbruchkriterium: etwa „Liegt die erste Etappe mehr als 30 Prozent über der Schätzung, wird der Plan neu bewertet“.
Prüftermin: ein festes Datum, an dem die Entscheidung mit den echten Zahlen der ersten Etappe überprüft wird.
Ein solches Blatt liegt am besten im Repository der Anwendung, neben dem Code, um den es geht. Wer die Entscheidung in zwei Jahren nachvollziehen will, findet dort Kontext, Optionen und Gründe.
Rückfragen
Häufige Fragen
-
Ein Vorgehen, bei dem eine neue Anwendung neben der alten wächst und deren Aufgaben Funktion für Funktion übernimmt, bis die alte abgeschaltet werden kann. Der Name geht auf Martin Fowler zurück, der es mit der Würgefeige verglichen hat. Voraussetzung ist eine Stelle, die Anfragen wahlweise an alt oder neu weiterleitet.
-
Für eine Fachanwendung, die über Jahre gewachsen ist, sind mehrere Monate bis Jahre realistisch, je nach Umfang und Zahl der Schnittstellen. Länger als geplant dauert er, wenn der alte Funktionsumfang nur teilweise bekannt ist oder die alte Anwendung während der Bauzeit weiter erweitert wird. Planen Sie deshalb einen Zwischenstand, an dem der Neubau seine erste echte Aufgabe übernimmt.
-
Beim Umbau in Etappen geht das, weil die alte Anwendung läuft, bis der jeweilige Teil ersetzt ist, und neue Funktionen im neuen Teil entstehen können. Beim Neubau am Stichtag läuft die alte Anwendung ebenfalls weiter, aber jede Erweiterung dort muss im Neubau nachgebaut werden. Wer am Stichtag umstellen will, friert deshalb größere Erweiterungen der alten Anwendung ein und bremst damit das Geschäft für die Bauzeit.
Nachweise
Quellen und Stand
Stand: 19.08.2026. Die Kostenrechnung beruht auf angenommenen Werten für eine Beispielanwendung.
Artikel teilen