Legacy-Software modernisieren: Wege und Risiken
Irgendwann reicht Wartung nicht mehr. Die Sprachversion ist End of Life, das Framework wird nicht mehr gepflegt, die Erweiterbarkeit ist erschöpft. Welcher Weg führt aus dieser Lage?
Die spontane Antwort lautet oft: neu bauen. Sie ist meistens falsch. Dieser Beitrag stellt die drei seriösen Methoden gegenüber und zeigt, woran Sie die passende Wahl erkennen. Eine Definition des Begriffs finden Sie im Glossareintrag Modernisierung.
Die drei Methoden im Überblick
| Methode | Vorgehen | Risiko | Dauer | Typische Eignung |
|---|---|---|---|---|
| Refactoring | Code Schritt für Schritt verbessern, Technik bleibt | gering | laufend | Code im Kern solide |
| Strangler-Fig | Neue Komponenten ersetzen alte parallel | mittel | 6 bis 24 Monate | Architektur veraltet, Betrieb muss laufen |
| Neuentwicklung | Komplett neu bauen, Altsystem läuft parallel | hoch | 1 bis 3 Jahre und mehr | Altsystem technisch nicht zu retten |
Welcher Weg passt, hängt von vier Faktoren ab: Zustand des Codes, geschäftliche Bedeutung, verfügbares Budget, Risikotoleranz.
Refactoring: Sanieren statt abreißen
Refactoring bedeutet, den Code Schritt für Schritt zu verbessern. Funktionen aufräumen, Abhängigkeiten entwirren, Tests einfügen, veraltete Muster ersetzen. Mehr zum Begriff im Glossar zu Refactoring.
Pro: Geringes Risiko. System bleibt verfügbar. Verbesserungen sofort spürbar. Geringe Einstiegshürde.
Contra: Begrenzt. Bei grundsätzlich falscher Architektur reicht es nicht. Versions- oder Plattformwechsel sind damit nicht zu leisten.
Wann sinnvoll: Code ist im Kern solide, Geschäftslogik funktioniert. Es geht um Qualität, Sicherheit und Erweiterbarkeit. In der Praxis ist Refactoring der Einstieg in fast jede Modernisierung.
Strangler-Fig: Das Alte umwachsen lassen
Das Strangler-Fig-Pattern hat seinen Namen von einer Pflanze, die einen Baum umwächst, bis dieser nicht mehr nötig ist. Neue Funktionen wachsen außerhalb des Altsystems, bestehende werden Stück für Stück migriert. Eines Tages ist das Altsystem leer.
Pro: Betrieb läuft durchgehend. Neue Funktionen sofort modern gebaut. Jede migrierte Komponente reduziert das Risiko. Politisch gut absicherbar.
Contra: Komplex in der Umsetzung. Zwei Systeme laufen zeitweise nebeneinander und müssen sauber zusammenarbeiten. Erfordert klare Architekturentscheidungen.
Wann sinnvoll: Architektur ist nicht mehr zukunftsfähig, ein Neubau wäre zu riskant oder zu lang. Der elegante Mittelweg für mittlere und große Systeme.
Neuentwicklung: Der teure Klassiker
Der vollständige Neubau ist das, was viele Anbieter empfehlen. Für sie ist es einfacher zu planen und abzurechnen. Für Sie ist es meist die teuerste und riskanteste Option.
Pro: Frischer Code, moderne Architektur, keine Altlasten. Klarer Schnitt zu früheren Entscheidungen.
Contra: Dauert in der Regel länger als geplant. Kostet meist mehr als geplant. Während der Bauzeit fließt nichts in das Altsystem zurück. Über Jahre gewachsene Geschäftslogik landet selten vollständig im Lastenheft.
Wann sinnvoll: Altsystem ist technisch nicht zu retten. Geschäftslogik soll grundlegend überdacht werden. Es gibt klare strategische Gründe für einen Schnitt. Ein realistisch geplanter Neubau dauert für eine geschäftskritische Anwendung selten unter einem Jahr.
Entscheidungsmatrix
| Situation | Empfohlene Methode |
|---|---|
| Sprachversion EOL, Architektur tragfähig | Refactoring plus Versions-Upgrade |
| Framework EOL, viele Module, hoher Verfügbarkeitsdruck | Strangler-Fig |
| Geschäftsmodell ändert sich grundlegend | Neuentwicklung mit Parallelbetrieb |
| Kleine Anwendung, wenige Nutzer, klare Logik | Neuentwicklung im Einzelfall vertretbar |
| Hohe Datenmenge, gewachsene Sonderfälle | Strangler-Fig, niemals Big-Bang |
Warum ein Big-Bang fast immer scheitert
"Big Bang" bedeutet: Heute läuft das Alte, morgen das Neue, dazwischen liegt ein Stichtag. Verlockend einfach, in der Praxis selten erfolgreich. Die Gründe:
Migrationsdaten. Bestehende Daten müssen ins neue System überführt werden. Ein eigenes Projekt.
Schulung. Alle Nutzer müssen ab Stichtag mit dem neuen System klarkommen. Auch gute Software hat eine Lernkurve.
Vergessene Funktionen. Es zeigt sich erst nach dem Wechsel, dass eine seltene, aber wichtige Funktion fehlt.
Kein Rückweg. Wenn das Neue nicht funktioniert, steht alles still.
Kumulierte Bugs. Was verstreut entstanden wäre, trifft am ersten Tag alle Nutzer auf einmal.
Phasen eines realistischen Projekts
- Bestandsaufnahme. Sprachversion, Framework, Abhängigkeiten, fachliche Funktion, Nutzergruppen.
- Zielbild. Wo soll das System in zwei Jahren stehen? Begründet, keine Wunschliste.
- Wegwahl. Refactoring, Strangler-Fig oder Neuentwicklung, dokumentiert.
- Sicherheitsnetz. Tests für kritische Abläufe, Backups, Wiederherstellbarkeit.
- Umsetzung in Etappen. Jede Etappe bringt konkreten Nutzen und geht in Produktion, bevor die nächste beginnt.
- Stabilisierung und Lernen. Nach jeder Etappe wird beobachtet und nachjustiert.
Häufige Fallstricke
Unterschätzte Komplexität der Altsoftware. Was wie eine kleine Funktion aussieht, ist oft das Ergebnis jahrelanger Sonderwünsche.
Fehlende Beteiligung der Nutzer. Wer ohne Fachseite plant, baut an den Bedürfnissen vorbei.
Wechsel mehrerer Dinge gleichzeitig. Neue Sprache, neues Framework, neue Datenbank, neue Architektur. Wenn etwas schiefgeht, weiß niemand mehr, wo.
Kein klarer Verantwortlicher. Modernisierung braucht eine Person mit Mandat und Überblick.
Vergessenes Tagesgeschäft. Während der Modernisierung läuft das Altsystem weiter und braucht weiter Pflege.
Fazit
Es gibt keinen pauschal besten Weg. Es gibt den Weg, der zum Codezustand, zum Budget und zur Risikotoleranz passt. Der Schlüssel liegt nicht in der Technologie, sondern in der Planung.
Wenn ein Projekt ansteht, finden Sie unser Vorgehen, Ablauf und Preise unter Modernisierung.
