Legacy-Software ist oft erfolgreicher, als ihr Ruf vermuten lässt. Viele alte Systeme laufen seit Jahren, weil sie wichtige Geschäftsprozesse zuverlässig abbilden. Das Problem beginnt, wenn dieselbe Software nicht mehr verändert werden kann: Jede Anpassung dauert Wochen, Wissen sitzt bei einzelnen Personen, Schnittstellen fehlen, Sicherheitsupdates werden schwierig und neue digitale Produkte kommen nicht voran.
Deshalb suchen Unternehmen nach "Legacy-Software modernisieren", "Altsystem ablösen" oder "Software Migration Kosten". Die eigentliche Frage lautet: Wie modernisiert man ein kritisches System, ohne den laufenden Betrieb zu gefährden?
Dieser Beitrag erklärt, wann Modernisierung sinnvoll ist, welche Strategien es gibt, welche Kosten entstehen und wie eine Software-Agentur ein Legacy-Projekt strukturiert angehen kann.
Was ist Legacy-Software?
Legacy-Software ist nicht automatisch schlechte Software. Der Begriff beschreibt Systeme, die fachlich wichtig sind, aber technisch oder organisatorisch schwer weiterzuentwickeln sind. Typische Merkmale:
- veraltete Programmiersprachen oder Frameworks
- fehlende Tests
- schlechte oder fehlende Dokumentation
- wenige Entwickler mit Systemwissen
- manuelle Deployments
- unsichere Abhängigkeiten
- langsame Performance
- keine oder instabile Schnittstellen
- Datenmodelle, die nicht mehr zur Realität passen
Ein System wird nicht über Nacht zum Legacy-System. Meist wächst technische Schuld über Jahre, bis Änderungen immer teurer werden.
Wann wird Legacy-Software zum Risiko?
Modernisierung wird dringend, wenn eines oder mehrere Signale auftreten:
- Neue Funktionen dauern unverhältnismäßig lange.
- Fehlerbehebungen erzeugen neue Fehler.
- Sicherheitsupdates sind kaum noch möglich.
- Es gibt keine aktiven Maintainer für wichtige Bibliotheken.
- Daten müssen manuell zwischen Systemen kopiert werden.
- Das System verhindert neue Geschäftsmodelle.
- Betrieb oder Hosting hängen an alter Infrastruktur.
- Schlüsselpersonen verlassen das Unternehmen.
Besonders kritisch ist die Kombination aus hohem Geschäftswert und niedriger Änderbarkeit. Dann ist das System wichtig genug, um nicht abgeschaltet zu werden, aber zu starr, um mit dem Unternehmen mitzuwachsen.
Modernisieren oder neu entwickeln?
Viele Teams wünschen sich einen klaren Neustart. In der Praxis ist ein kompletter Neubau aber riskant, wenn das bestehende System viel Fachlogik enthält. Oft ist nicht dokumentiert, warum bestimmte Regeln existieren. Diese Regeln stecken im Code, in Datenbankstrukturen, in Exporten oder in manuellen Workarounds.
| 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 nicht mehr passend | hoch, wenn Fachlogik unbekannt ist |
Ein kompletter Neubau kann sinnvoll sein, wenn das alte System fachlich nicht mehr zum Unternehmen passt. Häufiger ist jedoch eine schrittweise Modernisierung die bessere Wahl.
Die sicherste Strategie: Schrittweise ersetzen
Bei kritischen Systemen ist ein Big-Bang-Wechsel gefährlich. Sicherer ist eine inkrementelle Strategie: Das alte System bleibt zunächst in Betrieb, während einzelne Bereiche neu gebaut und kontrolliert umgeleitet werden. Dieses Prinzip wird oft als Strangler-Fig-Ansatz beschrieben.
Praktisch kann das bedeuten:
- neue Schnittstellen vor das Altsystem setzen
- einzelne Funktionen in moderne Services auslagern
- neue Oberflächen auf bestehende Daten bauen
- Datenmigration schrittweise vorbereiten
- alte Module erst abschalten, wenn neue stabil laufen
So sinkt das Risiko, weil nicht alles auf einmal migriert werden muss.
Was kostet Legacy-Modernisierung?
Kosten hängen stark von Systemgröße, Codequalität, Datenmodell, Dokumentation und Betriebsrisiko ab. Orientierung:
| Projekt | Typischer Umfang | Realistischer Korridor |
|---|---|---|
| Technischer Audit | Code, Architektur, Risiken, Roadmap | 5.000 bis 20.000 EUR |
| Refactoring-Paket | Tests, Code-Struktur, Dependencies, Build | 15.000 bis 60.000 EUR |
| Modulmodernisierung | einzelner Prozess oder Service wird ersetzt | 40.000 bis 150.000 EUR |
| Systemmigration | Daten, Schnittstellen, neue App, Betrieb | ab 150.000 EUR |
Diese Zahlen sind bewusst breit. Ein kleines internes Tool kann überschaubar modernisiert werden. Ein geschäftskritisches System mit Datenmigration, Benutzerrollen, Reporting, Buchhaltung und externen Schnittstellen ist ein mehrmonatiges Programm.
Phase 1: System verstehen
Vor jeder Modernisierung sollte klar sein, was das System wirklich tut. Dazu gehören:
- Code- und Architektur-Review
- Datenbankanalyse
- Infrastruktur-Check
- Abhängigkeitsanalyse
- Sicherheits- und Datenschutzprüfung
- Interviews mit Fachabteilungen
- Analyse manueller Workarounds
- Bewertung aktueller Fehler und Engpässe
Diese Phase ist wichtig, weil Legacy-Systeme oft mehr Fachwissen enthalten als die Dokumentation. Wer zu früh neu baut, riskiert, kritische Regeln zu übersehen.
Phase 2: Risiken priorisieren
Nicht alles muss gleichzeitig modernisiert werden. Sinnvoll ist eine Priorisierung nach Geschäftswert und technischem Risiko.
Hohe Priorität haben Bereiche, die:
- häufig geändert werden
- viele Fehler verursachen
- Sicherheitsrisiken enthalten
- wichtige Daten bewegen
- neue Produkte blockieren
- stark von einzelnen Personen abhängen
Niedrige Priorität haben stabile Module, die selten geändert werden und keine akuten Risiken erzeugen. Sie dürfen oft länger bleiben, solange sie sauber gekapselt sind.
Phase 3: Tests und Sicherheitsnetz aufbauen
Legacy-Modernisierung ohne Tests ist riskant. Auch wenn das bestehende System keine Tests hat, kann man nachträglich ein Sicherheitsnetz aufbauen:
- Charakterisierungstests für bestehendes Verhalten
- API-Tests für kritische Endpunkte
- Datenmigrationstests
- End-to-End-Tests für Kernprozesse
- Monitoring für Fehler und Performance
- Rollback-Strategien für Deployments
Tests müssen nicht sofort alles abdecken. Sie sollten zuerst die Prozesse schützen, die finanziell, rechtlich oder operativ kritisch sind.
Phase 4: Schnittstellen stabilisieren
Viele Altsysteme sind schwer zu modernisieren, weil andere Systeme direkt auf Datenbanktabellen, Exporte oder manuelle Dateien zugreifen. Eine sinnvolle Zwischenstufe ist eine stabile API-Schicht.
Diese API kann:
- Zugriffe kontrollieren
- Datenformate vereinheitlichen
- neue Frontends ermöglichen
- externe Integrationen vereinfachen
- spätere Ablösung vorbereiten
Gerade bei API- und Schnittstellenentwicklung ist wichtig, nicht nur technische Endpunkte zu bauen, sondern fachliche Verantwortlichkeiten zu klären.
Phase 5: Datenmigration planen
Datenmigration ist oft der kritischste Teil. Alte Daten sind selten so sauber, wie sie aussehen. Typische Probleme:
- doppelte Datensätze
- fehlende Pflichtfelder
- veraltete Statuswerte
- freie Textfelder statt strukturierter Daten
- historische Sonderfälle
- widersprüchliche Kundendaten
Eine gute Migration besteht nicht nur aus einem Importskript. Sie braucht Mapping, Validierung, Testläufe, Fachabnahme und einen Plan für den Übergang. Bei kritischen Daten sollte es außerdem eine Rückfallstrategie geben.
Typische Fehler bei Legacy-Projekten
Alles auf einmal ersetzen
Ein großer Neubau wirkt sauber, ist aber riskant. Je mehr Fachlogik unbekannt ist, desto höher die Gefahr, dass der Neubau wichtige Sonderfälle vergisst.
Nur die Technologie betrachten
Legacy ist nicht nur ein Framework-Problem. Prozesse, Daten, Verantwortlichkeiten und Betrieb gehören dazu. Ein modernes Framework löst keine unklaren Geschäftsregeln.
Keine Fachabteilungen einbeziehen
Die Menschen, die täglich mit dem System arbeiten, kennen viele Sonderfälle. Ohne dieses Wissen entstehen neue Systeme, die technisch modern, aber fachlich unvollständig sind.
Betrieb vergessen
Modernisierung endet nicht beim Launch. Monitoring, Backups, Security-Updates, Deployment-Prozesse und Support müssen geplant werden.
Checkliste für die Modernisierung
Vor dem Start sollten Unternehmen diese Fragen beantworten:
- Welche Prozesse sind geschäftskritisch?
- Welche Teile des Systems ändern sich häufig?
- Welche Abhängigkeiten sind veraltet oder unsicher?
- Gibt es Tests oder nur manuelle Prüfung?
- Welche Daten müssen migriert werden?
- Welche Schnittstellen existieren bereits?
- Wer kennt die fachlichen Sonderfälle?
- Welche Risiken sind akzeptabel?
- Gibt es einen Rollback-Plan?
- Wie wird der Erfolg der Modernisierung gemessen?
Mögliche Erfolgskriterien sind kürzere Release-Zyklen, weniger Fehler, bessere Performance, geringere Betriebskosten, bessere Sicherheit oder schnellere Umsetzung neuer Funktionen.
Fazit
Legacy-Software modernisieren heißt nicht, alles Alte sofort wegzuwerfen. Gute Modernisierung beginnt mit Verständnis, Priorisierung und einem Sicherheitsnetz. Danach können kritische Teile schrittweise ersetzt, Schnittstellen stabilisiert und Daten kontrolliert migriert werden.
Für Unternehmen ist das oft wirtschaftlicher als ein radikaler Neubau. Die Software bleibt während der Modernisierung nutzbar, Risiken werden sichtbar und Investitionen fließen dorthin, wo sie den größten Effekt haben.
