Legacy-Software ist oft erfolgreicher, als ihr Ruf vermuten lässt: Viele alte Systeme laufen seit Jahren, weil sie zentrale Geschäftsprozesse zuverlässig abbilden. Teuer wird nicht das Alter, sondern die Starrheit. Technische Schuld bindet laut McKinsey nach Einschätzung von CIOs 20 bis 40 Prozent des Werts eines gesamten IT-Bestands – und 10 bis 20 Prozent der Budgets für neue Produkte fließen still in das Aufräumen von Altlasten ab.
Die eigentliche Frage lautet deshalb nicht „neu oder behalten", sondern: Wie modernisiert man ein kritisches System, ohne den laufenden Betrieb zu gefährden? Dieser Beitrag zeigt, wann Modernisierung dringend wird, welche Strategien es gibt und was sie im DACH-Raum realistisch kostet.
Wann Legacy-Software vom Asset zum Risiko wird
Ein System wird nicht über Nacht zum Legacy-Risiko – kritisch wird die Kombination aus hohem Geschäftswert und niedriger Änderbarkeit. Dann ist die Software zu wichtig, um sie abzuschalten, aber zu starr, um mit dem Unternehmen mitzuwachsen. Genau dort wächst technische Schuld über Jahre, bis jede Änderung teuer wird.
Konkrete Warnsignale, dass Modernisierung dringend wird:
- Neue Funktionen dauern unverhältnismäßig lange, Fehlerbehebungen erzeugen neue Fehler.
- Sicherheitsupdates sind kaum noch möglich, wichtige Bibliotheken haben keine aktiven Maintainer.
- Daten werden manuell zwischen Systemen kopiert, Schnittstellen fehlen oder sind instabil.
- Betrieb und Hosting hängen an veralteter Infrastruktur, Wissen sitzt bei einzelnen Personen.
Dass dies kein Randthema ist, zeigt der DACH-Markt: Der Branchenverband Bitkom widmet der Software-Modernisierung 2025 eine eigene Praxis-Publikation, weil veraltete Architekturen die Digitalisierung vieler Unternehmen ausbremsen. Wer früh hinschaut, hat mehr Optionen – ein strukturierter Software-Audit macht den Zustand messbar.
Modernisieren oder neu bauen? Die Strategien im Vergleich
Der Wunsch nach dem sauberen Neustart ist verständlich – in der Praxis ist der komplette Neubau aber der riskanteste Weg. Große „Big-Bang"-Rewrites scheitern überdurchschnittlich oft, weil unklar ist, warum bestimmte Regeln existieren. Diese Regeln stecken im Code, in Datenbankstrukturen, in Exporten und in manuellen Workarounds – nicht in der Dokumentation. Genau davor warnt auch Martin Fowler in seinem Klassiker zur Strangler-Fig-Application.
| Ansatz | Geeignet für | Risiko |
|---|---|---|
| Refactoring | Code ist nutzbar, aber schwer wartbar | gering bis mittel |
| Replatforming | Infrastruktur oder Hosting ist veraltet | mittel |
| Rewriting einzelner Module | klare, abgrenzbare Teilbereiche | mittel |
| Schrittweise Ablösung | kritisches System mit vielen Funktionen | mittel bis hoch, aber kontrollierbar |
| Kompletter Neubau | altes System ist fachlich klein oder unpassend | hoch, wenn Fachlogik unbekannt ist |
Ein Neubau kann die richtige Wahl sein, wenn das alte System fachlich nicht mehr zum Unternehmen passt. Häufiger aber gewinnt die schrittweise Modernisierung – sie hält das Risiko klein und liefert früh Ergebnisse.
Der sichere Weg: schrittweise ersetzen
Bei kritischen Systemen ist ein Big-Bang-Wechsel gefährlich – sicherer ist eine inkrementelle Ablösung. Das alte System bleibt in Betrieb, während einzelne Bereiche neu gebaut und kontrolliert umgeleitet werden. Dieses Muster ist als Strangler-Fig-Ansatz bekannt: Neue Services wachsen um das Altsystem herum und übernehmen nach und nach seine Aufgaben.
In der Praxis folgt das einem klaren Fahrplan – fünf Phasen, die sich überlappen, aber aufeinander aufbauen.
- Phase 1 – Verstehen: Code- und Architektur-Review, Datenbank- und Abhängigkeitsanalyse, Interviews mit den Fachabteilungen. Legacy-Systeme enthalten oft mehr Fachwissen als ihre Dokumentation.
- Phase 2 – Priorisieren: nach Geschäftswert und technischem Risiko. Hohe Priorität haben Bereiche, die häufig geändert werden, viele Fehler verursachen oder neue Produkte blockieren.
- Phase 3 – Absichern: Charakterisierungstests, API-Tests, Monitoring und Rollback-Strategien. Zuerst die Prozesse schützen, die finanziell, rechtlich oder operativ kritisch sind.
- Phase 4 – Schnittstellen stabilisieren: eine saubere API-Schicht vor das Altsystem setzen, statt andere Systeme direkt auf Tabellen zugreifen zu lassen.
- Phase 5 – Ersetzen: einzelne Module ablösen und alte erst abschalten, wenn die neuen stabil laufen.
Was kostet Legacy-Modernisierung?
Es gibt keinen Pauschalpreis – die Kosten hängen von Systemgröße, Codequalität, Datenmodell und Betriebsrisiko ab. Als grobe Orientierung dienen die folgenden Korridore. Sie basieren auf typischen Agentur-Projekten im DACH-Raum, wo Tagessätze für erfahrene Teams meist zwischen 900 und 1.400 € liegen; freiberufliche IT-Profis lagen 2025 laut freelancermap im Schnitt bei rund 102 € pro Stunde.
| Projekt | Typischer Umfang | Realistischer Korridor |
|---|---|---|
| Technischer Audit | Code, Architektur, Risiken, Roadmap | 5.000–20.000 € |
| Refactoring-Paket | Tests, Code-Struktur, Dependencies, Build | 15.000–60.000 € |
| Modulmodernisierung | einzelner Prozess oder Service wird ersetzt | 40.000–150.000 € |
| Systemmigration | Daten, Schnittstellen, neue App, Betrieb | ab 150.000 € |
Die Korridore sind bewusst breit. Ein kleines internes Tool lässt sich überschaubar modernisieren; ein geschäftskritisches System mit Datenmigration, Benutzerrollen, Reporting und externen Schnittstellen ist ein mehrmonatiges Programm. Wichtig: Modernisierung endet nicht beim Launch – Betrieb, Wartung und Weiterentwicklung gehören in die Kalkulation.
Typische Fehler bei Legacy-Projekten
Die teuersten Fehler sind selten technischer, sondern planerischer Natur. Vier Muster sehen wir immer wieder:
- Alles auf einmal ersetzen. Je mehr Fachlogik unbekannt ist, desto größer die Gefahr, dass der Neubau wichtige Sonderfälle vergisst.
- Nur die Technologie betrachten. Legacy ist kein reines Framework-Problem. Prozesse, Daten, Verantwortlichkeiten und Betrieb gehören dazu – ein modernes Framework löst keine unklaren Geschäftsregeln.
- Fachabteilungen nicht einbeziehen. Die Menschen, die täglich mit dem System arbeiten, kennen die Sonderfälle. Ohne ihr Wissen entstehen technisch moderne, aber fachlich unvollständige Systeme.
- Betrieb vergessen. Monitoring, Backups, Security-Updates und Deployment-Prozesse müssen von Anfang an mitgeplant werden – sonst wandert die technische Schuld nur weiter.
Daten verdienen besondere Aufmerksamkeit: Alte Datenbestände sind selten so sauber, wie sie aussehen. Doppelte Datensätze, fehlende Pflichtfelder, freie Textfelder und historische Sonderfälle machen die Migration zum kritischsten Teil. Eine gute Migration besteht nicht aus einem Importskript, sondern aus Mapping, Validierung, Testläufen, Fachabnahme und einer Rückfallstrategie. Wie wir Datenmodelle und Schnittstellen sauber neu aufsetzen, zeigt unsere Backend-Entwicklung.
Nächste Schritte
Drei Fragen klären die Richtung schneller als jede Tool-Diskussion:
- Geschäftswert: Welche Prozesse sind wirklich kritisch – und welche Teile des Systems ändern sich am häufigsten?
- Risiko: Wo sitzen veraltete Abhängigkeiten, fehlende Tests oder einzelne Wissensträger?
- Daten: Welche Datenbestände müssen migriert werden, und wie sauber sind sie tatsächlich?
Wer hier Antworten hat, braucht keinen Befreiungsschlag, sondern einen Plan. Genau das liefern wir: einen Audit, der Fachlogik, Abhängigkeiten und Datenqualität sichtbar macht, und eine Roadmap, die Risiken priorisiert. Sieh dir unsere Software-Entwicklung an oder buche direkt ein Erstgespräch.
