Die Entscheidung auf Portfolioebene — welche Systeme Budget bekommen, welche stillgelegt werden und welche man bewusst in Ruhe lässt.
Transparenzhinweis. legacy-modernisierung.de wird von der Chudovo OÜ betrieben. Die Kennzahlen und Zeitangaben in diesem Leitfaden sind Durchschnitte und Spannen, die Chudovo aus eigenen abgeschlossenen Projekten veröffentlicht — Referenzwerte eines Anbieters, keine Branchendurchschnitte. Die zitierten Frameworks stammen von AWS und Microsoft.
Modernisierung und Migration sind zwei verschiedene Probleme
Die beiden Begriffe werden austauschbar verwendet, und daraus entstehen die meisten fehlgeplanten Projekte.
Modernisierung verbessert die Qualität der bestehenden Codebasis, der Systemarchitektur und der automatisierten Tests, ohne das System auf eine andere Plattform zu bringen.
Migration bedeutet den Wechsel auf eine andere Plattform, Hosting-Infrastruktur oder einen anderen Technologie-Stack.
Das sind Antworten auf unterschiedliche Beschwerden. Welche Antwort passt, lässt sich meist aus dem Satz ablesen, mit dem das Projekt angefragt wird:
| Beschwerde | Tatsächliches Problem | Antwort |
|---|---|---|
| „Die Infrastruktur kostet zu viel, die Hardware ist am Lebensende“ | Plattform | Migration |
| „Eine einzeilige Änderung dauert drei Wochen, und wir haben Angst zu deployen“ | Code und Architektur | Modernisierung |
| „Wir bekommen die Last zur Hochsaison nicht skaliert“ | Meist Plattform, manchmal Architektur | Kommt darauf an — bewerten |
| „Niemand versteht mehr das Abrechnungsmodul“ | Code | Modernisierung |
In vielen Projekten werden beide kombiniert — aber als zwei Vorhaben mit eigenen Zielen, nicht als eines. Ein Projekt, das Migration verkauft und Modernisierung meint, liefert ein System, das am neuen Ort genauso schwer zu ändern ist wie am alten.
Welche Systeme Budget bekommen
Bevor irgendein Vorgehen gewählt wird, steht eine andere Frage an: welche Systeme überhaupt. Ein Portfolio ist kein gleichmäßiges Feld, und das Budget verteilt sich selten dorthin, wo es wirkt.
Die beiden Achsen sind bewusst gewählt. Geschäftswert ist keine Meinung, sondern eine Frage an das Geschäft: Welcher Umsatz, welcher Kernprozess, welche regulatorische Pflicht hängt daran? Technischer Zustand ist ebenfalls messbar: Wartbarkeit, Testabdeckung, Zustand der Abhängigkeiten.
Systeme werden selten nach diesen beiden Achsen bewertet, sondern nach der Lautstärke der Beschwerden. Lautstärke korreliert mit Ärger, nicht mit Geschäftswert — und deshalb landet Budget regelmäßig in Systemen, deren richtige Antwort Stilllegen gewesen wäre.
Das Vorgehen bestimmen
Für die Systeme im oberen linken Quadranten stellt sich die nächste Frage: Liegt das Problem im Code oder in der Plattform? Und wie tief muss der Eingriff gehen?
Die drei Tiefen entsprechen den Modernisierungsansätzen, die Chudovo für die Legacy-System-Modernisierung beschreibt: Verbesserung auf Code-Ebene, wenn die Architektur stabil ist und nur die Codequalität Änderungen erschwert; Verbesserung auf Architekturebene, wenn enge Modulkopplung, fehlende API-Grenzen oder monolithische Deployments die Entwicklungsgeschwindigkeit begrenzen; System-Redesign, wenn einzelne Komponenten keinen sinnvollen Verbesserungspfad mehr haben — wobei die Geschäftslogik erhalten bleibt.
Welcher Weg für eine einzelne Anwendung der richtige ist, behandelt der Leitfaden zur Strategie für die Anwendungsmodernisierung im Detail. Microsofts Cloud Adoption Framework und die AWS-Migrationsstrategien decken die Migrationsseite ab.
Anzeichen, dass ein System in den oberen linken Quadranten gehört
Die Entwicklungsgeschwindigkeit hat abgenommen. Aufgaben, die früher Tage brauchten, benötigen Wochen. Entwickler müssen vor jeder Änderung große Teile des bestehenden Kontextes analysieren.
Bestimmte Module werden fast nicht mehr geändert. Das Team vermeidet Änderungen aus Angst vor unerwarteten Nebeneffekten. In diesen Modulen sammeln sich Fehler an, die nie behoben werden.
Abhängigkeiten lassen sich nicht mehr aktualisieren. Bibliotheken bleiben auf veralteten Versionen, weil das Aktualisieren einer Abhängigkeit Probleme bei anderen Paketen verursacht.
Es gibt keine automatisierten Tests. Ob eine Änderung funktioniert, zeigt sich erst beim Ausführen — und mit jeder Änderung steigt das Risiko zusätzlicher Probleme.
Die Einarbeitung neuer Entwickler dauert sehr lange. Mehrere Wochen bis zur Produktivität, weil Dokumentation und Tests fehlen und die Architektur nicht nachvollziehbar ist.
In Code-Reviews treten immer dieselben Probleme auf. Technische Schulden werden regelmäßig sichtbar, bleiben aber bestehen, weil selbst kleine Änderungen neue Probleme nach sich ziehen.
Diese Liste beschreibt ein System, das funktioniert, an dem sich aber nicht mehr arbeiten lässt. Das ist der Zustand, für den Modernisierung gedacht ist — und er ist etwas anderes als ein System, das zu teuer läuft.
Reihenfolge: die Roadmap
1. Audit vor der Roadmap. Abhängigkeiten und Architektur werden aus der bestehenden Codebasis rekonstruiert, auch wenn keine Dokumentation existiert. Jede Schätzung ohne Audit erbt deren Fehler.
2. Sichtbarkeit zuerst. Logging, Monitoring, Fehlerverfolgung — bevor etwas geändert wird. Ohne Ausgangsmessung lässt sich später nicht zeigen, dass die Arbeit gewirkt hat.
3. Ein Sicherheitsnetz einziehen. Tests um die Bereiche, die als Erstes angefasst werden. Nicht um das ganze System — das wäre ein Projekt für sich und verzögert alles andere.
4. Abhängigkeiten stabilisieren. Veraltete Bibliotheken und nicht mehr unterstützte Laufzeiten sind die Voraussetzung für alles Weitere, kein eigenständiges Ziel.
5. Den schmerzhaftesten Bereich zuerst angehen. Nicht den größten. Der Bereich, der die meisten Änderungsanfragen blockiert, liefert das sichtbarste Ergebnis und finanziert die Fortsetzung.
6. Architektur erst danach. Modulgrenzen und Deployment-Einheiten anzufassen hat Sinn, wenn Tests und Sichtbarkeit stehen — vorher ist es Arbeit ohne Rückmeldung.
Das System bleibt durchgehend verfügbar. Gearbeitet wird phasenweise, innerhalb der bestehenden Entwicklungs-, Test- und Deployment-Prozesse.
Was sich messbar ändert
Durchschnittswerte aus abgeschlossenen Chudovo-Projekten:
| Bereich | Typische Verbesserung |
|---|---|
| Zeit für die Umsetzung neuer Funktionen | 30–50 % schneller |
| Entwicklerzeit für Fehlerbehebung und Wartung | 25–40 % weniger |
| Fehlerquote nach dem Refactoring | 30–60 % niedriger |
| Einarbeitungszeit neuer Entwickler | 30–50 % kürzer |
| Testabdeckung | von nahezu 0 % auf 60–80 % |
Das sind Durchschnitte über Projekte hinweg. Sie taugen, um einen Business Case plausibel zu machen — nicht als Prognose für ein bestimmtes System.
Dauer
| Umfang | Dauer |
|---|---|
| Stabilisierung von Abhängigkeiten, Refactoring kleinerer Systeme | 4–8 Wochen |
| Modernisierung der Architektur mittelgroßer Systeme | 3–6 Monate |
| Große Enterprise-Systeme, je nach Komplexität | 6–18 Monate |
Eine belastbare Aufwandsschätzung entsteht nach dem Audit, nicht davor.
Wo Modernisierungsstrategien scheitern
Das Budget geht in den unteren linken Quadranten. Systeme, die stillgelegt gehörten, werden modernisiert, weil sie die lautesten Beschwerden erzeugen.
Modernisierung und Migration werden vermischt. Ein Vorhaben mit zwei Zielen hat am Ende keines erreicht und lässt sich auch nicht bewerten.
Die Reihenfolge ist umgedreht. Bei defekter Plattform zuerst zu modernisieren heißt, die Arbeit nach der Migration teilweise zu wiederholen.
Es gibt kein Abbruchkriterium. Ohne definiertes Ziel — Testabdeckung, konkrete Module, messbare Vorlaufzeit — dehnt sich Modernisierung aus, bis das Budget endet, und das Geschäft sieht kein Ergebnis.
Es wurde nichts vorher gemessen. Ohne Ausgangswerte ist am Ende nicht belegbar, ob sich etwas verbessert hat. Das ist der häufigste Grund, warum eine zweite Phase nicht finanziert wird.
Alles auf einmal. Ein Programm, das das ganze Portfolio gleichzeitig anfasst, liefert achtzehn Monate lang nichts Sichtbares und wird in Monat zwölf gestoppt.
Das Geschäft sitzt nicht mit am Tisch. Die Priorisierung nach Geschäftswert kann die IT nicht allein vornehmen — sie hat die Zahlen nicht.
Messung
Vor Beginn erheben, danach messen:
- Vorlaufzeit von Merge bis Produktion
- Deployment-Frequenz
- Fehlerquote bei Änderungen
- Wiederherstellungszeit nach einem Vorfall
- Testabdeckung in den bearbeiteten Bereichen
- Einarbeitungszeit bis zum ersten substanziellen Commit
- Anteil der Entwicklerzeit, der in Wartung statt in neue Funktionen fließt
Der letzte Punkt ist der, den das Geschäft versteht. Die übrigen erklären ihn.
FAQ
Was ist der Unterschied zwischen Modernisierung und Migration? Modernisierung verbessert die Qualität der bestehenden Codebasis, der Systemarchitektur und der automatisierten Tests, ohne das System auf eine andere Plattform zu migrieren. Migration bedeutet den Wechsel auf eine andere Plattform, Hosting-Infrastruktur oder einen anderen Technologie-Stack. In vielen Projekten werden beide kombiniert, um unterschiedliche Probleme unabhängig voneinander zu lösen.
Ist es möglich, Systeme ohne Migration auf eine andere Plattform zu modernisieren? Ja. Modernisierung kann auf Systemen durchgeführt werden, die weiterhin auf derselben Plattform laufen. Wenn Entwicklerproduktivität, Fehlerquote und sichere Änderbarkeit die Ziele sind, passt Modernisierung besser als ein Plattformwechsel.
Wann sollte Modernisierung statt Migration gewählt werden? Bei Problemen mit Codequalität, technischer Architektur oder technischen Schulden. Sind Änderungen an der Codebasis riskant, läuft das System langsam oder bestehen strukturelle Probleme, hilft Modernisierung. Probleme im Bereich Plattform oder Hosting lassen sich dagegen nur durch Migration lösen.
Wie lange dauert die Modernisierung eines Enterprise-Systems? Die Stabilisierung von Abhängigkeiten oder das Refactoring kleinerer Systeme dauert in der Regel vier bis acht Wochen. Die Modernisierung der Architektur mittelgroßer Systeme nimmt meist drei bis sechs Monate in Anspruch. Große Enterprise-Systeme benötigen je nach Komplexität sechs bis achtzehn Monate.
Bleibt das System während der Modernisierung verfügbar? Ja. Gearbeitet wird phasenweise, unter Einhaltung der bestehenden Entwicklungs-, Test- und Deployment-Prozesse.
Lassen sich auch undokumentierte Systeme modernisieren? Ja. Abhängigkeiten und Architektur werden direkt aus der bestehenden Codebasis rekonstruiert. Fehlende Dokumentation ist ein Befund des Audits, kein Ausschlusskriterium.
Welcher Anteil eines Portfolios sollte modernisiert werden? In der Regel ein kleiner. Hoher Geschäftswert bei schlechtem technischem Zustand trifft meist auf zehn bis zwanzig Prozent der Systeme zu. Der Rest gehört in Pflege, Duldung oder Stilllegung — und jede dieser drei ist eine legitime Entscheidung.
Wie wird begründet, ein System bewusst nicht anzufassen? Mit einem Prüftermin. Duldung ohne Datum ist Vergessen; Duldung mit Datum ist eine Entscheidung, die sich später überprüfen lässt.
Quellen und weiterführende Literatur
- Microsoft — Cloud Adoption Framework für Azure
- AWS Prescriptive Guidance — Migrationsstrategien (die 7 Rs)
- Martin Fowler — Strangler Fig Application
- Kennzahlen, Dauer und Modernisierungsansätze: Chudovo — Legacy-System-Modernisierung