Modernisierungsentscheidung
Legacy-System stabilisieren oder neu schreiben?
Eine Entscheidungsmatrix für Veränderungsdruck, Testbarkeit, Betrieb, Daten, Integrationen und den benötigten Zeitwert.
Die kurze Antwort
Ob ein Legacy-System stabilisiert oder neu geschrieben werden sollte, hängt von technischen, betrieblichen und wirtschaftlichen Befunden ab. Das Alter des Systems allein ist kein ausreichendes Kriterium.
Eine Stabilisierung ist häufig der nächste sinnvolle Schritt, wenn das System weiterhin Geschäftswert liefert und Risiken schrittweise begrenzt werden können. Eine Neuentwicklung sollte ernsthaft geprüft werden, wenn ein klar abgrenzbares Zielsystem einen belegbaren Engpass des Bestands auflöst und Migration sowie Parallelbetrieb beherrschbar sind.
Entscheidungsrahmen
Technisch zählen unter anderem Änderungsrisiko, Systemverständnis, Testbarkeit, Build und Deployment, Datenmigration, Integrationen und das aktuelle Betriebsrisiko.
Wirtschaftlich zählen der benötigte Zeitwert, der Aufwand für Parallelbetrieb und Verifikation, die verbleibende Nutzungsdauer und die Folgen eines verzögerten Nutzens. Dafür gibt es keine universelle Schwelle.
Entscheidungsmatrix: stabilisieren oder neu schreiben
Jede Zeile liefert ein Indiz, keine automatische Entscheidung. Die Befunde müssen gemeinsam betrachtet und nach Geschäftsrisiko gewichtet werden.
| Kriterium | Spricht eher für Stabilisierung | Spricht eher für eine Neuentwicklung |
|---|---|---|
| Änderungstakt | Der Bestand muss laufend angepasst werden und kleine sichere Änderungen schaffen kurzfristig Wert. | Ein abgrenzbarer Bereich bleibt während der Neuentwicklung fachlich ausreichend stabil. |
| Systemverständnis und Busfaktor | Wissen kann durch Analyse, Pairing, Tests und Dokumentation verbreitert werden. | Das erforderliche Verhalten lässt sich unabhängig vom Bestand vollständig spezifizieren und abnehmen. |
| Testbarkeit | Kritische Abläufe lassen sich mit Charakterisierungs- und Integrationstests absichern. | Das Verhalten ist klar definiert, aber im Bestand nur mit unverhältnismäßigem Risiko prüfbar. |
| Build und Deployment | Messbare Engpässe können schrittweise beseitigt und Releases reproduzierbar gemacht werden. | Die Lieferkette ist an nicht ersetzbare technische Grenzen des Bestands gebunden. |
| Datenmigration | Datenmodell und Historie sind komplex, und ein sicherer Schnitt ist noch nicht belegt. | Migration, Validierung, Rückfallweg und Datenverantwortung sind konkret geplant. |
| Integrationen | Viele implizite oder schwer änderbare Schnittstellen erfordern zuerst Transparenz und Verträge. | Schnittstellen sind inventarisiert, versionierbar und gegen ein Zielsystem testbar. |
| Regulatorische und vertragliche Vorgaben | Bestehende Nachweise und Abnahmen dürfen nur kontrolliert verändert werden. | Neue Abnahmen, Aufbewahrungspflichten und Verträge sind im Programm berücksichtigt. |
| Aktuelles Betriebsrisiko | Akute Risiken verlangen zuerst kurze Maßnahmen für Stabilität, Beobachtbarkeit oder Rollback. | Der Bestand kann während der Entwicklung sicher betrieben werden, ohne notwendige Verbesserungen aufzuschieben. |
| Zeit bis zum benötigten Nutzen | Der Nutzen wird in kleinen Schritten benötigt und kann im Bestand früher erreicht werden. | Der benötigte Nutzen liegt hinter einer belegten Grenze des Bestands und der längere Vorlauf ist tragbar. |
Hinweise aus dem Systemalltag
- Für Stabilisierung spricht, dass kritische Abläufe bekannt sind, der Bestand weiterentwickelt werden muss und begrenzte Maßnahmen Release- oder Betriebsrisiken messbar senken können.
- Für eine ernsthafte Neuentwicklungsprüfung spricht, dass fachliche Grenzen, Datenmigration, Integrationen und Abnahme des Zielsystems klar beschrieben werden können und der Bestand einen zentralen Bedarf dauerhaft blockiert.
Daten und Voraussetzungen
- Benötigt werden technische Befunde zu Code, Architektur, Build, Tests, Deployment, Betrieb, Daten und Schnittstellen.
- Getrennt davon werden wirtschaftliche Annahmen zu Zeitwert, Migrationsaufwand, Parallelbetrieb, Folgekosten und geplantem Nutzungshorizont dokumentiert.
Vorgehen in Schritten
- Aktuelle Risiken und Engpässe werden mit beobachtbaren Daten beschrieben, nicht mit allgemeinen Urteilen über Legacy-Code.
- Für jedes Kriterium werden Stabilisierung und Neuentwicklung anhand desselben Zielbilds und derselben Randbedingungen verglichen.
- Vor einer großen Festlegung wird der kleinste Schritt gewählt, der die unsicherste Annahme prüft. Das kann ein Code Forensic Assessment, eine technische Spitze oder ein abgegrenztes Stabilisierungspaket sein.
Ergebnis der Analyse
- Eine begründete Entscheidung mit getrennten technischen und wirtschaftlichen Annahmen.
- Ein nächster prüfbarer Schritt, der Risiko oder Unsicherheit reduziert, bevor ein Großprojekt gebunden wird.
Grenzen und Abgrenzung
- Es gibt keine universelle Kennzahl, ab der ein System neu geschrieben werden muss. Die Gewichtung hängt vom konkreten Geschäft, Betrieb und Zielsystem ab.
- Beispielrechnungen sind Modellannahmen. Sie ersetzen weder reale Aufwandsdaten noch eine Prüfung von Migration, Abnahme und Betriebsfolgen.
Prüffragen
- Technische und wirtschaftliche Kriterien sind getrennt dokumentiert.
- Das Zielsystem, der Migrationsweg und die Abnahme sind konkreter als ein allgemeiner Wunsch nach neuer Technik.
- Risiken von Parallelbetrieb, Datenübernahme und Schnittstellen sind benannt.
- Die nächste Maßnahme prüft eine entscheidende Annahme und bindet noch nicht das gesamte Programm.
Quellen und Einordnung
Die Quellen stützen die technische Einordnung oder beschreiben den Umfang einer verknüpften Leistung. Projektergebnisse und Modellannahmen sind keine allgemeine Wirkungszusage.