Sieben Wege, was jeder davon tatsächlich verändert, und die Entscheidung zwischen Refactoring und Neuentwicklung, die das Budget bestimmt.
Transparenzhinweis. legacy-modernisierung.de wird von der Chudovo OÜ betrieben. Die Kosten- und Zeitangaben in diesem Leitfaden sind die Spannen, die Chudovo aus eigenen abgeschlossenen Projekten veröffentlicht. Sie sind Referenzwerte eines Anbieters, keine Branchendurchschnitte. Die zitierten Frameworks stammen von AWS, Microsoft und Martin Fowler.
Eine Entscheidung auf Anwendungsebene
Die Portfoliostrategie entscheidet, welche Systeme Budget bekommen. Dieser Leitfaden behandelt den nächsten Schritt: Sie haben eine Anwendung, sie ist eine Investition wert, und Sie müssen den Weg festlegen.
Die Wege sind nicht austauschbar. Sie unterscheiden sich um den Faktor zwanzig in den Kosten und sie verändern unterschiedliche Teile des Systems. Deshalb ist die Wahl nach Vorliebe statt nach Diagnose der teuerste Fehler, der hier möglich ist.
Die sieben Wege
Die Systematik stammt von AWS und ist dort als „7 Rs“ dokumentiert; Microsoft behandelt dasselbe Feld im Cloud Adoption Framework. Auf eine einzelne Anwendung angewendet:
Warum Stilllegen und Standardsoftware zuerst kommen. Beide beseitigen das Problem, statt es zu lösen, und beide werden regelmäßig übersprungen, weil das Gespräch mit „wie modernisieren wir das“ beginnt statt mit „sollte das überhaupt existieren“. Eine Anwendung, die seit zwei Jahren kaum genutzt wird, braucht keine Strategie. Eine Lohnbuchhaltung muss nicht individuell entwickelt sein.
Was jeder Weg tatsächlich verändert
Die Wege werden meist als Leiter mit steigendem Aufwand dargestellt. Das verdeckt die nützlichere Tatsache: Sie verändern unterschiedliche Schichten. Wer rehostet, weil „wir modernisieren müssen“, hat die Schicht nicht angefasst, aus der die Beschwerde kam.
Refactoring, Reengineering oder Neuentwicklung
Für Anwendungen im unteren Zweig — wo der Code das Problem ist — lautet die eigentliche Frage, wie weit man geht. Drei Begriffe werden austauschbar benutzt und bedeuten Unterschiedliches:
Refactoring verändert die interne Struktur bestehenden Codes, ohne das externe Verhalten zu ändern. Die Anwendung tut dasselbe, wird aber testbar, änderbar und verständlich. Das ist die Standardantwort und die günstigste.
Reengineering geht weiter: Änderungen am Technologie-Stack, Überarbeitung des Datenmodells, Neubau einzelner Komponenten. Die Arbeit beginnt als Refactoring und eskaliert dort, wo Refactoring nicht ausreicht.
Neuentwicklung ersetzt die Anwendung vollständig und bewahrt dabei die Geschäftslogik, nicht die Implementierung.
Der Test für eine Neuentwicklung
Eine Neuentwicklung ist dann gerechtfertigt, wenn die vorhandene Codebasis nicht mehr sinnvoll genutzt werden kann. Das kommt realistisch betrachtet seltener vor, als es behauptet wird. Die meisten „wir müssen neu schreiben“-Argumente bedeuten übersetzt „die Codebasis ist unangenehm“ — und das ist ein Argument für Refactoring.
Drei Prüfungen, bevor eine Neuentwicklung beschlossen wird:
- Ist die Geschäftslogik irgendwo außer im Code dokumentiert? Wenn nicht, bedeutet eine Neuentwicklung, jahrelang gewachsene Regeln neu zu entdecken — meist aus Produktionsstörungen nach dem Start
- Können altes und neues System parallel laufen? Wenn nicht, planen Sie eine Big-Bang-Umstellung, und genau daran scheitern Neuentwicklungen
- Entwickelt das Team neu, das das System kennt? Eine Neuentwicklung durch Leute, die das Original nie gepflegt haben, reproduziert dessen Fehler und fügt neue hinzu
Übersteht ein Vorhaben alle drei Prüfungen, ist es vermutlich richtig. Die meisten tun es nicht.
Anzeichen, dass Refactoring der richtige Weg ist
- Das Hinzufügen einer einfachen Funktion erfordert Änderungen an mehreren Stellen, die nicht miteinander verbunden sein sollten
- Bestimmte Codestellen werden bewusst vermieden, weil die Auswirkungen schwer vorhersehbar sind
- Bugs sind schwer zu finden, weil die Logik unübersichtlich ist und keine klare Trennung existiert
- Die Einarbeitung neuer Entwickler dauert lange, da die Dokumentation unzureichend oder fehlerhaft ist
- Tests sind langsam oder werden ausgelassen, weil ihre Stabilität schwer sicherzustellen ist
- Builds und Deployments erfordern manuelle Eingriffe
Das beschreibt eine Anwendung, die funktioniert, an der sich aber nicht mehr arbeiten lässt — genau der Fall, für den Refactoring da ist.
Wie Refactoring im laufenden Betrieb umgesetzt wird
Die Anwendung bleibt in Betrieb. Das ist eine Anforderung, kein Komfortmerkmal: Ein Projekt, das einen Feature-Stopp braucht, ist in Wahrheit eine Neuentwicklung.
Audit zuerst, Umfang danach. Ein technisches Audit ermittelt den Umfang der technischen Schulden, die betroffenen Bereiche und deren Priorität. Schätzungen ohne Audit sind Vermutungen.
Schrittweise Umsetzung. Die Arbeit erfolgt in Phasen, während das Produktivsystem weiterläuft. Jede Phase wird geprüft, bevor die nächste beginnt — das lässt Raum, den Ansatz nach dem ersten Realitätskontakt anzupassen.
Feature Flags, wo nötig. Neue Pfade laufen parallel zu alten, der Traffic wird schrittweise umgeleitet, ein Rollback ist sofort möglich. Dasselbe Prinzip wie Martin Fowlers Strangler-Fig-Muster, nur im kleineren Maßstab.
Geschäftslogik bleibt erhalten. Die Regeln, Berechnungen und Abläufe, auf die sich das Unternehmen stützt, sind das Vermögen. Die Implementierung ist es nicht.
Kosten und Dauer
Veröffentlichte Spannen von Chudovo für Anwendungs-Refactoring:
| Umfang der Anwendung | Dauer | Kosten |
|---|---|---|
| Kleinere Legacy-Anwendung, kleiner Umfang | 4–8 Wochen | €5.000–10.000 |
| Mittelgroß, einige Module, mittlere Testabdeckung | 2–4 Monate | €15.000–25.000 |
| Große Enterprise-Anwendung: verteilte Komponenten, fehlende Testabdeckung, regulatorische Anforderungen | 4–12 Monate | ab €30.000 |
Entscheidend für die Einstufung sind Modulanzahl, vorhandene Testabdeckung und regulatorischer Rahmen — nicht die Codezeilen. Eine Anwendung mit 200.000 Zeilen und funktionierender Test-Suite ist ein kleineres Projekt als eine mit 60.000 Zeilen ohne Tests.
Wo Anwendungsmodernisierung scheitert
Der Weg stand vor der Diagnose fest. „Wir gehen in die Cloud“ ist eine Entscheidung über Hosting, die auf Anwendungen angewendet wird, deren Probleme im Code liegen.
Rehosting wurde als Modernisierung verkauft. Die Anwendung läuft an einem neuen Ort und verhält sich identisch — einschließlich der drei Wochen Vorlaufzeit, die das Projekt ausgelöst haben.
Eine Neuentwicklung wurde gewählt, weil die Codebasis unangenehm war. Die drei Prüfungen oben existieren, weil das der teuerste Fehler dieser Liste ist.
Das Audit wurde übersprungen. Der Umfang entstand aus einer Begehung und einigen Meinungen. Jede folgende Schätzung erbt diesen Fehler.
Refactoring hatte kein Abbruchkriterium. Ohne definiertes Ziel — Testabdeckung, konkrete Module, messbare Vorlaufzeit — dehnt sich Refactoring aus, bis das Budget endet, und das Unternehmen sieht kein Ergebnis.
Geschäftslogik wurde nicht von der Implementierung getrennt. Besonders bei Neuentwicklungen geht genau das verloren: Regeln, die nur im Code existierten, werden durch Produktionsfehler wiederentdeckt.
Messung
Vorher erheben, nachher messen:
- Vorlaufzeit von Merge bis Produktion
- Fehlerquote bei Änderungen
- Defektrate in den bearbeiteten Bereichen
- Testabdeckung in den berührten Bereichen
- Einarbeitungszeit bis zum ersten substanziellen Commit
Veröffentlichte Durchschnittswerte aus Chudovo-Projekten: 30–50 % schnellere Umsetzung neuer Funktionen, 25–40 % weniger Zeit für Fehlerbehebung und Wartung, 30–60 % niedrigere Defektraten, Testabdeckung von nahezu null auf 60–80 %. Das sind Durchschnitte über Projekte hinweg — brauchbar, um einen Business Case zu plausibilisieren, nicht als Prognose für Ihren Fall.
FAQ
Was ist der Unterschied zwischen Refactoring und Neuschreiben? Refactoring verändert die interne Code-Struktur, ohne das externe Verhalten zu ändern. Ein Neuschreiben entwickelt die Anwendung von Grund auf neu. Refactoring ist die sichere Option, wenn mit bestehendem Code weitergearbeitet werden kann; eine vollständige Neuentwicklung ist nur nötig, wenn die Codebasis nicht mehr sinnvoll nutzbar ist — was seltener vorkommt, als behauptet wird.
Was ist der Unterschied zwischen Refactoring und Reengineering? Refactoring betrifft die Code-Überarbeitung ohne Änderung der Funktionalität. Reengineering kann Änderungen am Technologie-Stack, am Datenmodell oder an der Architektur umfassen. Projekte beginnen meist als Refactoring und eskalieren dort, wo es nicht ausreicht.
Bleibt die Anwendung während des Refactorings im Betrieb? Ja. Die Arbeit läuft parallel zur Entwicklung, bei Bedarf mit Feature Flags. Ein Projekt, das einen Stopp erfordert, sollte als Neuentwicklung bewertet werden.
Wie lange dauert Anwendungs-Refactoring? Vier bis acht Wochen bei kleineren Anwendungen mit begrenztem Umfang. Zwei bis vier Monate bei mittelgroßen Anwendungen mit einigen Modulen und mittlerer Testabdeckung. Vier bis zwölf Monate bei großen Enterprise-Anwendungen mit verteilten Komponenten, fehlender Testabdeckung und regulatorischen Anforderungen.
Ist Rehosting eine Form der Modernisierung? Nein. Rehosting ändert, wo die Anwendung läuft. Wenn die Beschwerde Entwicklungsgeschwindigkeit, Defektraten oder Wartbarkeit betrifft, hilft Rehosting nicht.
Welcher Weg ist der günstigste? Stilllegen, dann Beibehalten. Beide werden regelmäßig übersehen, weil das Gespräch mit dem Wie beginnt statt mit dem Ob.