Die 6 R's der Legacy-Modernisierung im Detail
Rehost (Lift & Shift)
Beim Rehost wird die Anwendung auf eine neue Infrastruktur (z. B. Cloud, Linux-Server) verlagert – ohne nennenswerte Code-Änderungen. Die gleiche Software läuft auf neuer Hardware oder in einer neuen Runtime; Datenbanken und Schnittstellen werden angepasst. Ziel ist die Reduktion von Infrastrukturkosten (z. B. Mainframe-Mieten) und die Nutzung moderner Betriebsmodelle (Skalierung, Backup). Die fachliche Logik und technischen Schulden bleiben erhalten; Rehost eignet sich, wenn die Infrastruktur das Hauptproblem ist und der Code kurzfristig tragfähig bleiben soll. Typischer Zeitrahmen: wenige Monate bis ein Jahr.
Refactor
Beim Refactor wird der Code modernisiert – Struktur, Lesbarkeit und Architektur werden verbessert, die fachliche Logik bleibt erhalten. Es können moderne Sprachen, Frameworks oder Datenbanken zum Einsatz kommen; die Änderungen erfolgen schrittweise (z. B. Modul für Modul). Refactor eignet sich, wenn der Code grundsätzlich erweiterbar ist und Sie langfristig Wartbarkeit, Testbarkeit und Integration verbessern wollen, ohne alles neu zu bauen. Typischer Zeitrahmen: Monate bis mehrere Jahre, abhängig vom Umfang.
Rearchitect
Beim Rearchitect wird die Architektur der Anwendung grundlegend überarbeitet – z. B. von Monolith zu Microservices, von fest gekoppelten Modulen zu klaren Schnittstellen und Diensten. Die fachlichen Anforderungen bleiben, aber die technische Struktur wird an neue Anforderungen (Skalierbarkeit, unabhängige Deployments, moderne Integration) angepasst. Rearchitect eignet sich, wenn die bestehende Architektur Innovation und Wartung blockiert, aber die fachliche Logik weitgehend stimmt. Der Aufwand liegt zwischen Refactor und Rebuild.
Rebuild
Beim Rebuild wird die Anwendung neu gebaut – auf Basis der bestehenden Anforderungen und des bekannten Verhaltens, aber mit neuem Code und in der Regel moderner Architektur. Im Unterschied zum vollständigen Replace bleibt das System unter Ihrer Kontrolle (kein Kauf einer Standardsoftware). Rebuild eignet sich, wenn Refactor oder Rearchitect unwirtschaftlich wären (z. B. zu verflochten, zu undokumentiert) und Sie die volle Kontrolle über Technologie und Roadmap behalten wollen. Typischer Zeitrahmen: ein bis mehrere Jahre bei großen Systemen.
Replace
Beim Replace wird das Altsystem durch eine andere Lösung ersetzt – typischerweise durch den Kauf oder die Einführung einer Standardsoftware (z. B. ERP, CRM, Branchenlösung) oder durch Outsourcing der Funktion. Die Anforderungen werden in der neuen Lösung abgebildet; das alte System wird abgeschaltet. Replace eignet sich, wenn der Markt eine passende Lösung bietet, die Total Cost of Ownership günstiger ist und Sie keine strategische Notwendigkeit für eine Eigenentwicklung haben. Risiken: Abhängigkeit vom Anbieter, Migrationsaufwand, Anpassung der Prozesse.
Retire
Beim Retire wird das System bewusst abgeschaltet – weil die Funktionen nicht mehr benötigt werden, in andere Systeme verlagert wurden oder der Nutzen den Betrieb nicht mehr rechtfertigt. Vor dem Retire müssen Daten und Prozesse sauber migriert oder archiviert werden; danach entfallen Kosten und Risiken des Altsystems. Retire eignet sich, wenn die Anwendung nur noch gering genutzt wird, durch andere Lösungen ersetzt werden kann oder die Geschäftsprozesse sich so geändert haben, dass die Funktion obsolet ist. Oft kombiniert mit Replace oder Konsolidierung auf eine Plattform.
| Strategie | Beschreibung |
|---|---|
| Rehost | Anwendung auf neuer Infrastruktur (z. B. Cloud, Linux) betreiben – wenig bis keine Code-Änderung, „Lift & Shift“. |
| Refactor | Code modernisieren, Struktur und Architektur verbessern, Logik erhalten – schrittweise möglich. |
| Rearchitect | Architektur grundlegend überarbeiten (z. B. Monolith → Microservices), Anforderungen bleiben. |
| Rebuild | Anwendung neu entwickeln auf Basis der bestehenden Anforderungen – neuer Code, moderne Architektur. |
| Replace | Altsystem durch Standardsoftware oder andere Lösung ersetzen und abschalten. |
| Retire | System abschalten, Funktionen verlagern oder bewusst weglassen. |
Wann welche Strategie sinnvoll ist (Entscheidungsmatrix)
Die Wahl der Strategie hängt von Risiko, Nutzen, Budget und Zeit ab. Konkrete Beispiele pro Strategie:
- Rehost – Beispiel: Ein Kreditinstitut mit COBOL-Kernbank auf Mainframe will zuerst die hohen Mietkosten reduzieren. Rehost auf Linux/Java-Runtime: gleicher Code, neue Infrastruktur, Entlastung in wenigen Monaten. Danach kann schrittweise refaktoriert werden.
- Refactor – Beispiel: Eine Verwaltung hat ein VB6-Fachverfahren mit klarer Modulstruktur. Modul für Modul wird in .NET Core überführt, Schnittstellen bleiben definiert. Nach zwei Jahren läuft das System modern und wartbar ohne Big-Bang.
- Rearchitect – Beispiel: Ein E-Commerce-Monolith blockiert unabhängige Releases und Skalierung. Bestehende Module werden in Dienste aufgeteilt (z. B. Bestellung, Katalog, Zahlung), APIs definiert – gleiche Logik, neue Architektur.
- Rebuild – Beispiel: Ein Versicherer hat ein undokumentiertes Policensystem; Refactor wäre teurer als Neubau. Anforderungen werden extrahiert, neue Anwendung in Java/Cloud entwickelt, Altsystem parallel betrieben bis zur Ablösung.
- Replace – Beispiel: Ein Mittelständler nutzt eine veraltete Eigenentwicklung für CRM und Vertrieb. Statt Rebuild wird ein Standard-CRM (z. B. Odoo, Salesforce) eingeführt, Daten migriert, Altsystem abgeschaltet.
- Retire – Beispiel: Ein alter Report-Generator wird nur noch von einer Abteilung genutzt; die Auswertungen lassen sich aus dem neuen ERP erzeugen. Nach Migration der letzten Reports wird das System abgeschaltet.
Wir beraten Sie dazu passend zu Ihrer Ausgangslage. Mehr unter Legacy-Modernisierung, VB6-Ablösung, COBOL-Modernisierung.
Die größten Risiken veralteter Software
- Sicherheitslücken: Alte Systeme erhalten oft keine Patches mehr und sind anfällig für Angriffe.
- Fachkräftemangel: Immer weniger Entwickler beherrschen COBOL, VB6 oder veraltete Frameworks – Wartung wird teurer und riskanter.
- Fehlende Integration: Moderne APIs, Cloud-Dienste und Schnittstellen sind schwer oder nur mit hohem Aufwand anbindbar.
- Hohe Wartungskosten: Spezialisten, Nischen-Infrastruktur und Workarounds treiben die Kosten.
- Betriebsrisiken: Ausfälle, Compliance-Probleme (z. B. DSGVO) und Abhängigkeit von wenigen Personen.
Je länger die Modernisierung verschoben wird, desto höher werden Aufwand und Risiko.
Cloud-Migration als Modernisierungsstrategie
Die Verlagerung von Altsystemen in die Cloud (Rehost oder Replatform) kann ein erster Schritt sein: bessere Skalierbarkeit, geringere Infrastrukturkosten, modernere Betriebsmodelle. Oft wird danach schrittweise refaktoriert oder teilweise neu entwickelt. Wichtig: Datenhoheit, Compliance und Latenz im Blick behalten – nicht jede Legacy-Anwendung gehört in die Public Cloud.
Häufige Fragen zur Legacy-Modernisierung (FAQ)
- Refactor oder Rewrite?
Refactor, wenn die fachliche Logik stimmt und der Code strukturierbar ist. Rewrite, wenn die Basis zu fragil oder die Architektur nicht zukunftsfähig ist. - Kann schrittweise modernisiert werden?
Ja. Strangler-Fig-Pattern und parallele Betriebsphasen ermöglichen schrittweise Ablösung ohne Big-Bang. - Was kostet eine Legacy-Modernisierung?
Abhängig von Strategie und Umfang: Rehost oft wenige Monate, Refactor Monate bis Jahre, Rewrite oft ein bis mehrere Jahre. Wir schätzen nach Bestandsaufnahme. - Muss der Betrieb unterbrochen werden?
Nein. Mit parallelen Systemen und schrittweiser Umstellung bleibt der Betrieb lauffähig.