- Nicht das Alter einer Software entscheidet, sondern ob ihr fachlicher Kern noch trägt.
- Modernisierung erhält Geschäftswissen, wenn Datenmodell und Produktlogik grundsätzlich stimmen.
- Ein Neubau ist sinnvoll, wenn Reparatur teurer wird als ein gezielter neuer Kern.
“Alt” ist kein ausreichender Grund, Software neu zu bauen. Viele Legacy-Systeme sind unbequem, aber wertvoll: Sie enthalten fachliche Regeln, Datenwissen und Betriebsrealität, die in keiner Spezifikation sauber stehen. Ein kompletter Neubau kann genau dieses Wissen verlieren.
Gleichzeitig ist Modernisierung nicht immer die richtige Antwort. Manche Systeme sind so weit von der heutigen Realität entfernt, dass jede Reparatur nur die nächste Ausnahme vorbereitet. Die Entscheidung braucht deshalb einen Befund, kein Bauchgefühl.
Die richtige Leitfrage
Die zentrale Frage lautet nicht: Wie alt ist die Software? Sondern: Trägt ihr Kern noch?
Ein Kern trägt, wenn:
- das Datenmodell die fachliche Realität grundsätzlich abbildet
- die wichtigsten Regeln im System noch sinnvoll sind
- Nutzer und Betrieb trotz Reibung vom Bestand profitieren
- Änderungen langsam, aber nicht grundsätzlich unmöglich sind
- genug Wissen vorhanden ist, um das System kontrolliert zu verändern
Wenn das zutrifft, ist Modernisierung oft risikoärmer als ein Neubau.
Befund statt Bauchgefühl
Eine sinnvolle Entscheidung entsteht aus einem kurzen technischen Befund. Dabei wird nicht nur Codequalität betrachtet, sondern auch der wirtschaftliche Wert des Bestands.
| Prüffeld | Frage | Hinweis auf Modernisierung | Hinweis auf Neubau |
|---|---|---|---|
| Fachlogik | Bildet das System das Geschäft noch richtig ab? | Regeln sind wertvoll, aber schwer änderbar | Regeln passen nicht mehr zur Realität |
| Datenmodell | Tragen die Datenstrukturen noch? | Modell ist alt, aber fachlich stimmig | Modell blockiert jeden neuen Prozess |
| Änderbarkeit | Kann man risikobegrenzt umbauen? | Kritische Bereiche lassen sich isolieren | Änderungen brechen unvorhersehbar überall |
| Betrieb | Ist das System stabil betreibbar? | Betrieb braucht Updates und Monitoring | Laufzeit, Deployment und Abhängigkeiten sind nicht mehr kontrollierbar |
| Wissen | Gibt es genug Kontext? | Wissen ist verteilt, aber rekonstruierbar | Niemand versteht den Kern ausreichend |
Erst wenn diese Fragen beantwortet sind, lässt sich wirtschaftlich entscheiden, ob Modernisierung, Teilablösung oder Neubau trägt.
Wann Modernisierung sinnvoll ist
Modernisierung lohnt sich, wenn die Software fachlich wertvoll ist, aber technisch bremst. Dann geht es nicht darum, alles neu und schön zu machen, sondern gezielt Tragfähigkeit zurückzugewinnen.
Typische Maßnahmen:
- Abhängigkeiten und Frameworks aktualisieren
- kritische Bereiche durch Tests absichern
- Datenmodell und Schnittstellen schrittweise ordnen
- unklare Module isolieren und ersetzen
- Betrieb, Deployments und Monitoring stabilisieren
- KI-gestützte Weiterentwicklung nur mit Review und Tests einsetzen
Das Ziel ist nicht kosmetische Erneuerung. Das Ziel ist, Änderungen wieder planbar zu machen.
Wann ein Neubau sinnvoller ist
Ein Neubau wird sinnvoll, wenn die Modernisierung nur noch gegen die Grundstruktur arbeitet.
Warnzeichen:
- Das Datenmodell beschreibt nicht mehr das heutige Geschäft.
- Jede neue Funktion braucht Workarounds gegen die Architektur.
- Wichtige Fachlogik ist über zu viele Sonderfälle verteilt.
- Es gibt keine realistische Möglichkeit, den Kern schrittweise zu stabilisieren.
- Der Aufwand, Bestand zu verstehen und zu reparieren, übersteigt den Aufbau eines neuen Kerns.
Auch dann muss nicht alles auf einmal neu entstehen. Oft ist ein gezielter Rebuild des Kerns besser als ein vollständiger Big Bang.
Die wirtschaftliche Entscheidung
Modernisierung ist wirtschaftlich, wenn sie vorhandenes Wissen erhält und die nächsten Jahre wieder handlungsfähig macht. Neubau ist wirtschaftlich, wenn der Bestand so viel Reibung erzeugt, dass jede Investition darin verpufft.
| Befund | Naheliegender Weg |
|---|---|
| Fachlogik trägt, Technik bremst | Modernisieren |
| Einzelne Module sind brüchig | Schrittweise ablösen |
| Datenmodell passt nicht mehr | Neuen Kern prüfen |
| Betrieb ist riskant, Code aber verständlich | Betrieb und Tests stabilisieren |
| Niemand versteht den Bestand | Erst Analyse, dann Entscheidung |
Die erste Phase sollte deshalb keine Umsetzung sein, sondern ein Befund am System.
Ein pragmatischer Modernisierungspfad
In vielen Fällen ist der beste Weg weder Komplettsanierung noch Big Bang. Tragfähiger ist eine Reihenfolge mit klaren Sicherheitsnetzen:
- Kritische Pfade verstehen und dokumentieren.
- Tests um die wichtigsten fachlichen Regeln legen.
- Betrieb, Backups und Deployments stabilisieren.
- Abhängigkeiten und Frameworks kontrolliert aktualisieren.
- Brüchige Module isolieren und gezielt ersetzen.
- Neue Funktionen nur noch auf der stabilisierten Struktur bauen.
So entsteht Fortschritt im laufenden Betrieb, ohne dass das Unternehmen monatelang auf einen unsicheren Neustart wartet.
Fazit
Legacy-Software ist nicht automatisch schlecht. Sie ist oft das komprimierte Wissen eines Geschäfts. Die Frage ist, ob dieses Wissen in einer Struktur steckt, die noch weitergetragen werden kann.
Bei der Software-Modernisierung geht es genau darum: das Tragfähige erhalten, das Brüchige ersetzen und nur dort neu bauen, wo es wirtschaftlich wirklich sinnvoll ist.
