Legacy Software modernisieren oder ersetzen ist selten eine rein technische Frage. Geschäftswert, verfügbare Ressourcen und der tatsächliche Zustand des Systems entscheiden mit. Viele Unternehmen entscheiden aus Gewohnheit weiter mit dem Alten oder aus Ungeduld für etwas komplett Neues, ohne die Zwischenstufen ernsthaft zu prüfen.
Wer Legacy Software modernisieren will, hat zwischen Weiterbetrieb und Neubau vier Zwischenstufen. Das 6R-Modell ordnet sie: Retire, Rehost, Revise, Refactor, Rebuild, Replace. Welche Stufe passt, entscheiden vier Faktoren, nämlich technischer Zustand, Geschäftswert, verfügbare Ressourcen und strategisches Ziel. Ein stabiles, aber schwer wartbares System braucht meist Refactor, nicht Replace.
Legacy Software modernisieren nach dem 6R-Modell
Das 6R-Modell unterscheidet sechs Vorgehensweisen für Altsysteme, von der kleinsten bis zur größten Veränderung (ARDURA Consulting, 06/2025).
| Option | Was passiert | Passt, wenn |
|---|---|---|
| Retire | System wird abgeschaltet, ohne Ersatz | kein messbarer Geschäftswert mehr vorhanden ist |
| Rehost | unverändert auf neue Infrastruktur verschieben | nur die Plattform veraltet ist, nicht der Code |
| Revise | kleinere technische Anpassungen ohne Architekturänderung | einzelne Schwächen stören, nicht das Ganze |
| Refactor | Code strukturell überarbeiten, Funktion bleibt gleich | der Code stabil, aber schwer wartbar ist |
| Rebuild | Neuentwicklung auf Basis der bestehenden Logik | die Architektur nicht mehr erweiterbar ist |
| Replace | Ersatz durch eine komplett neue Lösung | Technologie und Fachlogik beide am Ende sind |
Der Entscheidungsbaum in sieben Fragen
Die Reihenfolge der Fragen bestimmt, wie schnell sich eine Option ausschließen lässt.
- Liefert das System noch messbaren Geschäftswert? Nein, dann Retire. Diese Frage klärt sich oft schneller als gedacht, wenn niemand die Nutzungszahlen wirklich kennt.
- Ist die zugrunde liegende Technologie ein Totalschaden? Fehlt der Hersteller, gibt es keinen Support mehr und findet sich auch keine Entwicklerbasis, dann führt kein Weg an Rebuild oder Replace vorbei.
- Ist die Architektur grundsätzlich erweiterbar? Wenn nicht, auch bei funktionierendem Code, begrenzt das jede Modernisierungsoption außer Rebuild oder Replace.
- Ist der Code technisch stabil, aber schwer wartbar? Genau hier passt Refactor am besten (ARDURA, 06/2025). Der Geschäftswert ist vorhanden, das technische Problem liegt in der Codequalität, nicht in der Architektur.
- Reicht eine neue Infrastruktur, ohne den Code zu ändern? Dann ist Rehost die schnellste und günstigste Option.
- Sind nur kleinere technische Schwächen vorhanden? Dann reicht Revise, ohne größeren Eingriff.
- Ist keine der Fragen eins bis sechs klar zu beantworten? Dann braucht es eine tiefere technische Bewertung, bevor eine Entscheidung fällt. Vorschnelle Entscheidungen an dieser Stelle sind der häufigste Grund, warum Modernisierungsprojekte später scheitern.
Was die Entscheidung wirklich bestimmt
Nach ARDURA hängt die Wahl der richtigen Option an vier Faktoren, technischer Zustand, Geschäftswert, verfügbare Ressourcen und strategische Ziele (ARDURA, 06/2025). Ein System mit hohem Geschäftswert und schlechtem technischen Zustand rechtfertigt Investition. Ein System mit niedrigem Geschäftswert rechtfertigt sie unabhängig vom technischen Zustand selten.
Hier lohnt eine deutliche Position. Wer Legacy Software modernisieren will, überspringt Refactoring in der Praxis oft, weil Replace nach dem gründlicheren Weg aussieht, ein neues System ohne alten Ballast. Das ist ein Trugschluss, wenn der Geschäftswert des Altsystems hoch ist und der Code lediglich schwer wartbar, aber technisch stabil. Ein Rebuild oder Replace kostet in diesem Fall deutlich mehr Zeit und Budget, als das eigentliche Problem, die Wartbarkeit, es rechtfertigt.
Ihr Altsystem entlang der sieben Fragen einordnenWir sehen uns Architektur, Abhängigkeiten und Nutzungszahlen an und sagen Ihnen, welche der sechs Optionen bleibt.
Modernisierung im laufenden Betrieb
Rehost und Revise laufen meist parallel zum Tagesgeschäft. Rebuild und Replace verlangen dagegen fast immer eine Übergangsphase mit Parallelbetrieb, in der altes und neues System gleichzeitig laufen.
Ein Vertragsdetail wird dabei oft übersehen. Wer ein Altsystem ersetzt, sollte prüfen, wie stark der neue Anbieter oder Entwicklungspartner erneuten Lock-in erzeugt. Die wichtigsten Schutzklauseln dafür beschreiben wir im Beitrag zu Vendor Lock-in vermeiden. Wie sich die Kosten über fünf Jahre verteilen, steht im Beitrag zu versteckten Kosten.
Häufige Fragen
Woran erkennt man den technologischen Totalschaden eines Systems?
Typische Anzeichen sind ein Hersteller, der keinen Support mehr anbietet, eine Programmiersprache oder Plattform, für die kaum noch Entwickler zu finden sind, und eine Architektur, die keine neuen Funktionen mehr zulässt, ohne bestehende zu gefährden. Treffen mehrere dieser Punkte zu, führt kaum ein Weg an Rebuild oder Replace vorbei (ARDURA, 06/2025).
Geht Modernisierung im laufenden Betrieb?
Bei Rehost und Revise ja, weil sich Infrastruktur oder kleinere Anpassungen meist ohne Unterbrechung umsetzen lassen. Bei Rebuild und Replace ist ein Parallelbetrieb über Wochen oder Monate der Regelfall, mit entsprechendem Zeit- und Ressourcenaufwand für beide Systeme gleichzeitig.
Was kostet es, ein Legacy-System einfach weiterzubetreiben?
Die Kosten des Nichtstuns sind selten sofort sichtbar, wachsen aber mit jedem Jahr. Dazu zählen steigender Wartungsaufwand, wachsendes Sicherheitsrisiko und der Verlust an Anpassungsfähigkeit gegenüber neuen Geschäftsanforderungen. Bevor Unternehmen ihre Legacy Software modernisieren, lohnt sich eine Einschätzung am eigenen System, denn pauschale Zahlen helfen hier wenig.
Der nächste Schritt
torck bewertet Altsysteme nach dem 6R-Modell, bevor eine Empfehlung für Rebuild, Refactor oder Replace fällt. Unsere Entwicklungsteams in Maxhütte-Haidhof, Wien und Rabat kennen die Fallstricke aus eigenen Modernisierungsprojekten für Industrie und Handel. Vertragspartner für dieses Projekt ist die deutsche torck GmbH. Im Erstgespräch gehen wir Ihr System gemeinsam durch.
German 
English 
French