Legacy-Software modernisieren: Schrittweise oder Big Bang?
Gewachsene Software ist kein Fehler — sie ist der Beweis, dass Ihr Geschäft funktioniert. Aber irgendwann wird das alte System zur Bremse. Die Frage ist nicht ob, sondern wie Sie modernisieren. Dieser Ratgeber zeigt die drei Wege und hilft bei der Entscheidung.
Woran Sie erkennen, dass Ihre Software ein Legacy-Problem hat
Nicht jede alte Software ist Legacy. Legacy wird sie erst, wenn sie Ihr Unternehmen ausbremst statt voranzubringen. Diese Warnsignale sprechen eine deutliche Sprache:
- Deployments dauern Tage statt Minuten — jedes Release wird zum Nervenkitzel
- Keiner traut sich, den Code anzufassen — aus Angst, etwas kaputtzumachen
- Ein einziger Entwickler kennt das System — und der ist seit Jahren überlastet
- Es gibt keine automatisierten Tests — jede Änderung wird manuell durchgetestet
- Neue Features dauern immer länger — was früher Wochen brauchte, dauert jetzt Monate
- Security-Patches können nicht eingespielt werden, weil Abhängigkeiten veraltet sind
Die drei Modernisierungsstrategien
Big Bang / Neuentwicklung
Das alte System wird komplett durch eine Neuentwicklung ersetzt. Hohes Risiko, aber ein sauberes Ergebnis ohne technische Altlasten. Funktioniert nur, wenn das System gut verstanden ist und genug Budget da ist.
- Saubere Architektur ohne Kompromisse
- Moderne Technologie-Basis von Anfang an
- Hohes Risiko — Projekte scheitern häufig an Umfang und Komplexität
- Kein Geschäftswert bis zum Go-Live — lange Durststrecke
Strangler Fig Pattern
Teile des alten Systems werden schrittweise durch neue Komponenten ersetzt. Das alte System läuft weiter, während die neuen Teile drumherum wachsen — wie eine Würgefeige um einen Baumstamm. Geringeres Risiko, messbarer Fortschritt.
- System bleibt während der Migration produktiv
- Risiko verteilt sich auf viele kleine Schritte
- Früh messbarer Geschäftswert — jede Komponente liefert sofort
- Temporär erhöhte Komplexität durch Parallelbetrieb
Inkrementelles Refactoring
Das bestehende System wird von innen heraus verbessert: Tests nachrüsten, Abhängigkeiten aktualisieren, Code aufräumen. Geringstes Risiko, aber die grundlegende Architektur bleibt bestehen.
- Geringstes Risiko — kleine, kontrollierte Änderungen
- Kein Parallelbetrieb nötig — ein System, ein Team
- Begrenzte Transformationstiefe — fundamentale Architekturprobleme bleiben
- Gefahr des endlosen Bastelns ohne klares Ziel
Kosten-Nutzen-Analyse im Vergleich
| Kriterium | Big Bang | Strangler Fig | Refactoring |
|---|---|---|---|
| Zeitrahmen | 12–24 Monate bis Go-Live | 6–18 Monate, erste Ergebnisse nach Wochen | Fortlaufend, kein festes Ende |
| Risiko | Hoch — Alles-oder-nichts am Go-Live-Tag | Mittel — verteilt auf viele kleine Releases | Niedrig — minimale Änderungen je Schritt |
| Kosten | Hoch und schwer planbar — Scope Creep typisch | Mittel bis hoch, aber planbar pro Komponente | Niedrig pro Iteration, aber Gesamtkosten unklar |
| Geschäftsunterbrechung | Ja — Umstellung am Stichtag, Downtime wahrscheinlich | Nein — System läuft durchgehend | Nein — Änderungen im laufenden Betrieb |
| Ergebnis | Komplett neues System ohne Altlasten | Schrittweise modernisiertes System | Verbessertes bestehendes System |
Die versteckten Kosten von Legacy-Software
Viele Unternehmen unterschätzen, was sie der Betrieb veralteter Software tatsächlich kostet. Die direkten Wartungskosten sind nur die Spitze des Eisbergs.
- Wartungskosten steigen exponentiell — je älter der Code, desto teurer jede Änderung
- Entwickler für veraltete Technologien sind kaum zu finden — und entsprechend teuer
- Security-Risiken durch ungepatchte Abhängigkeiten und fehlende Updates
- Integrationen mit modernen Tools und APIs sind unmöglich oder extrem aufwendig
- Wettbewerbsfähigkeit sinkt — während die Konkurrenz schneller liefert, kämpfen Sie mit dem Bestand
Entscheidungsmatrix: Welcher Weg passt zu Ihnen?
Big Bang passt, wenn ...
- Das System ist klein und gut verstanden
- Sie können sich eine Übergangsphase mit Downtime leisten
- Die alte Technologie ist so veraltet, dass Refactoring sinnlos wäre
- Budget und Zeitrahmen sind großzügig bemessen
Strangler Fig passt, wenn ...
- Das System ist groß und geschäftskritisch
- Es muss während der Modernisierung weiterlaufen
- Sie wollen schrittweise Ergebnisse statt alles auf eine Karte setzen
- Einzelne Module lassen sich klar abgrenzen und separat ersetzen
Refactoring passt, wenn ...
- Die grundlegende Architektur ist solide — nur der Code braucht Pflege
- Die Technologie-Basis ist noch aktuell und wird unterstützt
- Budget für eine größere Modernisierung fehlt aktuell
- Das Hauptproblem ist fehlende Testabdeckung oder veraltete Dependencies
Unser ehrliches Fazit
Big-Bang-Neuentwicklungen scheitern häufiger als sie gelingen. Nicht wegen schlechter Entwickler, sondern weil die Komplexität gewachsener Systeme systematisch unterschätzt wird. Was in 10 Jahren organisch entstanden ist, lässt sich selten in 12 Monaten sauber nachbauen.
Für die meisten Unternehmen ist das Strangler Fig Pattern der sicherste Weg: Sie modernisieren Stück für Stück, sehen früh Ergebnisse und können jederzeit Prioritäten anpassen. Das alte System läuft weiter, während das neue drumherum wächst.
Bei devRocks begleiten wir Legacy-Modernisierungen von der Bestandsanalyse bis zur Ablösung der letzten Alt-Komponente. Wir schneiden Ihr System in sinnvolle Domänen, definieren klare Schnittstellen und ersetzen Modul für Modul — ohne Ihr Tagesgeschäft zu unterbrechen.
Weiterlesen
Häufige Fragen
Was ist Legacy-Software?
Legacy-Software bezeichnet Systeme, die seit vielen Jahren im Einsatz sind und auf veralteten Technologien basieren. Typische Merkmale sind fehlende Dokumentation, monolithische Architektur, mangelnde Testabdeckung und Abhängigkeit von Technologien, für die kaum noch Entwickler zu finden sind.
Wie lange dauert eine Legacy-Modernisierung?
Das hängt stark vom Umfang ab. Einzelne Module oder Services lassen sich in 2–4 Monaten modernisieren. Eine vollständige Systemablösung dauert typischerweise 12–24 Monate. Der Strangler-Fig-Ansatz — schrittweises Ersetzen einzelner Komponenten — reduziert das Risiko und liefert früh sichtbare Ergebnisse.
Komplett neu schreiben oder schrittweise modernisieren?
Ein kompletter Rewrite ist verführerisch, aber riskant — laut Branchenerfahrung scheitern über 50 % der Big-Bang-Rewrites an Komplexität und Zeitdruck. Schrittweise Modernisierung ist fast immer der sicherere Weg: Sie migrieren Modul für Modul, behalten das Altsystem als Fallback und reduzieren das Projektrisiko deutlich.
Was kostet eine Legacy-Modernisierung?
Die Kosten variieren je nach Systemgröße und Modernisierungstiefe. Als Orientierung: Einfache Refactoring-Projekte beginnen bei 30.000–80.000 €. Umfangreiche Modernisierungen mit Architekturwechsel liegen bei 100.000–500.000 €+. Die Investition amortisiert sich durch niedrigere Wartungskosten, höhere Entwicklerproduktivität und reduzierte Ausfallrisiken.
Wann sollte man ein Legacy-System ablösen?
Klare Warnsignale sind: steigende Wartungskosten bei sinkendem Nutzen, keine verfügbaren Entwickler für die eingesetzte Technologie, Sicherheitslücken, die nicht mehr gepatcht werden können, und zunehmende Ausfallzeiten. Wenn die jährlichen Wartungskosten 50 % oder mehr einer Neuentwicklung erreichen, ist Modernisierung wirtschaftlich dringend.
Legacy-System bremst Sie aus?
In einem kostenlosen Erstgespräch analysieren wir gemeinsam Ihre Ausgangslage und zeigen, welcher Modernisierungsweg für Ihr System der richtige ist — ohne Verpflichtung.
Kostenlos beraten lassen