Legacy-System modernisieren: 7 Strategien im Vergleich

„Wir müssen unser Legacy-System modernisieren" ist ein Satz, der in vielen Unternehmen jahrelang gesagt und nicht umgesetzt wird. Der Grund ist selten Trägheit. Es ist die Kombination aus einem System, das täglich Geld verdient, einer Dokumentation, die nicht existiert, und einem Budget, das sich schwer rechtfertigen lässt, solange alles noch läuft.

Dieser Leitfaden ordnet die Entscheidung. Er beschreibt, woran man ein echtes Modernisierungsproblem erkennt, welche sieben Strategien zur Auswahl stehen, wie man die passende auswählt und wie sich der Aufwand gegen die Kosten des Nichtstuns rechnen lässt. Wenn Sie die Entscheidung bereits getroffen haben und wissen wollen, wie das Ablöseprojekt konkret abläuft, springen Sie direkt zu Altsystem ablösen.

Wann Sie ein Legacy-System modernisieren sollten: acht Merkmale

Ein System ist nicht deshalb Legacy, weil es alt ist. Es ist Legacy, wenn es das Geschäft einschränkt, obwohl es fachlich noch funktioniert. Diese acht Merkmale sind belastbare Indikatoren – wer drei oder mehr davon bejaht, hat ein Modernisierungsproblem, unabhängig vom Alter der Software:

• Änderungen dauern unverhältnismäßig lang. Eine Anpassung, die fachlich klein ist, kostet Wochen, weil niemand die Nebenwirkungen abschätzen kann.
• Es gibt keine automatisierten Tests. Jede Änderung wird von Hand geprüft – oder gar nicht.
• Das Wissen hängt an einzelnen Personen. Wenn eine Person das System als Einzige versteht und in fünf Jahren in Rente geht, ist das ein Termin, kein Risiko.
• Die Plattform erhält keine Sicherheitsupdates mehr. Betriebssystem, Datenbank, Framework oder Laufzeitumgebung sind abgekündigt.
• Integration ist nicht vorgesehen. Daten kommen nur über Exporte, Zwischendateien oder manuelles Abtippen heraus.
• Es gibt keinen Remote-Zugriff oder er ist nur über fragile Umwege möglich.
• Compliance-Anforderungen lassen sich nicht erfüllen – etwa Protokollierung von Zugriffen, Löschkonzepte oder rollenbasierte Rechte.
• Der Betrieb kostet überproportional. Spezialhardware, teure Altlizenzen, Wartungsverträge mit stark steigenden Sätzen.

Ein Punkt allein rechtfertigt selten ein Projekt. Drei oder mehr bedeuten fast immer, dass die Frage nicht mehr lautet „ob", sondern „wann und wie teuer".

Die Kosten des Nichtstuns

Der schwierigste Teil eines Modernisierungsvorhabens ist nicht die Technik, sondern der Geschäftsfall. Er misslingt regelmäßig, weil nur die Projektkosten auf einer Seite stehen und ein diffuses „ist dann besser" auf der anderen. Rechnen Sie stattdessen gegen den Ist-Zustand:

• Wartung und Betrieb des Altsystems pro Jahr, inklusive Lizenzen, Spezialhardware und externer Unterstützung.
• Verlorene Entwicklungszeit: Wie viele Personentage pro Jahr gehen für Umgehungslösungen, manuelle Abgleiche und Nacharbeiten drauf?
• Manuelle Arbeit in den Fachabteilungen, die eine moderne Lösung automatisieren würde – oft der größte einzelne Posten und derjenige, den die IT nicht sieht.
• Verzögerte Vorhaben: Welche Produkte, Preismodelle oder Kundenanforderungen scheitern heute an der Systemgrenze?
• Risikokosten: erwarteter Schaden eines Ausfalls oder eines Sicherheitsvorfalls, multipliziert mit der Eintrittswahrscheinlichkeit.
• Personalrisiko: Was kostet es, für eine abgekündigte Technologie noch Fachleute zu finden? Der Markt ist ohnehin eng – der Bitkom zählte für 2025 rund 109.000 unbesetzte IT-Stellen in Deutschland; für Nischentechnologien verschärft sich das erheblich.

Wenn diese Summe über drei bis fünf Jahre die Projektkosten nicht erreicht, ist „Retain" – bewusst nichts tun – die richtige Entscheidung. Sie ist eine legitime Strategie, keine Niederlage.

Die sieben Strategien: Ihre Optionen im Vergleich

Für die Entscheidung, was mit einer einzelnen Anwendung geschieht, hat sich ein Raster mit sieben Optionen durchgesetzt, die sogenannten 7 Rs. AWS beschreibt sie in seiner Migrationsleitlinie als Retire, Retain, Rehost, Relocate, Repurchase, Replatform sowie Refactor beziehungsweise Re-architect. Der praktische Wert liegt weniger in der Vollständigkeit als darin, dass Sie für jede Anwendung eine bewusste Entscheidung treffen – statt pauschal „alles neu" zu beschließen.

Strategie	Was passiert	Aufwand	Risiko	Sinnvoll wenn
Retire (Abschalten)	System wird stillgelegt, Daten archiviert	sehr gering	gering	kaum noch genutzt, Funktion anderswo abgedeckt
Retain (Behalten)	bewusst nichts ändern, erneut bewerten	keiner	steigend	Geschäftsfall trägt nicht, andere Vorhaben sind dringender
Rehost (Lift and Shift)	gleiche Anwendung, neue Infrastruktur	gering	gering	Hardware läuft aus, Software selbst ist tragfähig
Relocate	Verlagerung der Plattform ohne Architekturänderung	gering	gering	Rechenzentrumswechsel, virtualisierte Landschaft
Repurchase (Standardsoftware)	Eigenentwicklung durch fertiges Produkt ersetzen	mittel	mittel	Prozess ist Standard, kein Wettbewerbsvorteil
Replatform	Kern bleibt, einzelne Bausteine werden ersetzt (z. B. Datenbank)	mittel	mittel	ein konkreter Engpass, sonst gesundes System
Refactor / Re-architect	Architektur wird grundlegend erneuert	hoch	hoch	System blockiert das Geschäft dauerhaft

Zwei Beobachtungen aus der Praxis. Erstens wird Retire massiv unterschätzt: In fast jeder gewachsenen Landschaft gibt es Anwendungen, die niemand mehr wirklich braucht – deren Abschaltung ist die günstigste Modernisierung überhaupt. Zweitens wird Refactor massiv überschätzt: AWS selbst empfiehlt für große Migrationen ausdrücklich, zunächst zu rehosten, zu verlagern oder zu replatformen und erst danach zu modernisieren, weil das Umbauen während der Migration die komplexeste und teuerste Variante ist.

Modernisieren oder ablösen? Die Vorentscheidung

Praktisch läuft die Wahl auf eine von drei Grundrichtungen hinaus. Die folgenden Fragen führen zuverlässiger zur richtigen Antwort als eine Technologiediskussion:

Bildet das System einen Prozess ab, der Sie vom Wettbewerb unterscheidet? Wenn ja, kommt Standardsoftware kaum infrage – Sie würden Ihren Vorteil gegen den Branchendurchschnitt tauschen. Wenn nein (Buchhaltung, Zeiterfassung, Standard-Warenwirtschaft), ist Repurchase fast immer die wirtschaftlichste Option.

Ist der Quellcode verfügbar und verständlich? Ohne Quellcode oder ohne jemanden, der ihn erklären kann, scheidet Refactoring faktisch aus. Dann bleiben Neubau auf Basis rekonstruierter Fachlichkeit oder Standardsoftware.

Ist ein einzelner Engpass identifizierbar? Wenn das Problem konkret benennbar ist – die Datenbank, die Benutzeroberfläche, das Fehlen einer Schnittstelle –, ist Replatform deutlich günstiger und risikoärmer als ein Neubau. Der Fehler, den wir am häufigsten sehen, ist ein Komplettneubau als Antwort auf ein Teilproblem.

Wie hoch ist der Stillstandspreis? Bei einem System, das den Kernbetrieb trägt, verbietet sich ein Stichtagswechsel häufig von selbst. Dann bleibt nur die schrittweise Ablösung.

Schrittweise statt Big Bang: das Strangler-Fig-Muster

Der Neubau eines Altsystems „am Stück" ist der Klassiker unter den gescheiterten IT-Projekten: Über Monate entsteht etwas Neues, das das Alte noch nicht ersetzen kann, während das Alte weiter gepflegt werden muss. Martin Fowler beschreibt unter dem Namen Strangler Fig ein Gegenmuster: Das neue System wächst am alten, übernimmt Funktionsbereich für Funktionsbereich, und das Altsystem wird nach und nach entbehrlich. Vier Aktivitäten kennzeichnen das Vorgehen – gewünschtes Ergebnis klären, das Problem in kleinere Teile zerlegen, diese Teile erfolgreich liefern und die organisatorischen Anpassungen ermöglichen.

Der praktische Nutzen liegt nicht in der Metapher, sondern in drei Effekten: Das Risiko verteilt sich auf kleine Schritte, es gibt schon nach Wochen sichtbaren Nutzen statt nach Jahren, und das Team lernt am echten System, statt Annahmen zu treffen. Der Preis dafür ist eine Übergangszeit, in der zwei Systeme parallel laufen und Daten konsistent gehalten werden müssen. Wie das konkret aufgesetzt wird, beschreibt der Ratgeber Altsystem ablösen.

Was Modernisierung kostet

Belastbare Pauschalpreise gibt es nicht, wohl aber Größenordnungen für die Vorbereitung – und die ist der Teil, den Sie zuerst beauftragen sollten:

Schritt	Aufwand	Ergebnis
Bestandsaufnahme & Portfolio-Bewertung	5–15 PT	Liste der Anwendungen mit Strategieempfehlung je Anwendung
Technische Analyse eines Systems	5–20 PT	Architektur, Abhängigkeiten, Datenmodell, Risiken
Fachliche Rekonstruktion	10–40 PT	dokumentierte Regeln und Sonderfälle
Zielbild & Migrationsplan	10–25 PT	Schnitt der Schritte, Reihenfolge, Aufwandsschätzung

Bei Agenturtagessätzen von typischerweise 700 bis 1.200 € im deutschsprachigen Raum landen Sie damit für eine solide Entscheidungsgrundlage im niedrigen bis mittleren fünfstelligen Bereich. Das ist gut angelegtes Geld: Es ist der einzige Weg, eine Aufwandsschätzung für das eigentliche Vorhaben zu bekommen, die etwas wert ist. Beauftragen Sie diese Vorstudie ausdrücklich als eigenständige, bezahlte Leistung – und lassen Sie sich das Ergebnis so übergeben, dass Sie damit auch bei einem anderen Anbieter ausschreiben können.

Wer so ein Projekt umsetzt

Modernisierungsprojekte brauchen ein anderes Profil als Neuentwicklungen. Achten Sie auf drei Dinge: Erfahrung mit der Ausgangstechnologie (nicht nur mit der Zieltechnologie), nachweisbare Migrationsprojekte mit Datenübernahme und die Bereitschaft, eine Bestandsanalyse als eigenständige Leistung anzubieten, statt sofort ein Neubauangebot zu legen. Wer im Erstgespräch ohne Blick ins System eine Aufwandsschätzung nennt, schätzt nicht, sondern verkauft.

Passende Anbieter finden Sie im Verzeichnis unter Softwareentwicklung, IT-Beratung und Cloud & DevOps. Wie Sie daraus eine Shortlist machen, steht in Von der Longlist zur Shortlist.

Typische Fehler

• Technologie vor Fachlichkeit entscheiden. Die Frage „welches Framework" ist die letzte, nicht die erste.
• Alles gleichzeitig modernisieren. Portfolio bewerten, priorisieren, dann in Wellen vorgehen.
• Die Fachabteilung nicht einbinden. Sie kennt die Sonderfälle, die im Code stehen und in keiner Dokumentation.
• Funktionsgleichheit als Ziel setzen. Ein Nachbau aller Funktionen inklusive der über zwanzig Jahre gewachsenen Ausnahmen ist teuer und selten sinnvoll – prüfen Sie jede Funktion auf tatsächliche Nutzung.
• Den Parallelbetrieb unterschätzen. Zwei Systeme gleichzeitig zu betreiben und Daten konsistent zu halten, ist ein eigenes Arbeitspaket mit eigenem Budget.
• Ohne Ausstiegsklauseln beauftragen. Bei mehrjährigen Vorhaben brauchen Sie Zugriff auf Quellcode, Dokumentation und Daten zu jedem Zeitpunkt (siehe Vendor-Lock-in vermeiden).

Kurz gefasst

Ein Legacy-System zu modernisieren beginnt nicht mit Technologie, sondern mit einer Bestandsaufnahme und einer Entscheidung je Anwendung. Nutzen Sie das Raster der sieben Strategien und prüfen Sie ausdrücklich auch Abschalten und bewusstes Behalten. Rechnen Sie den Geschäftsfall gegen die Kosten des Nichtstuns, nicht gegen null. Wählen Sie den Komplettneubau nur, wenn ein konkreter Engpass ihn nicht erklärt – und wenn Sie ablösen, dann schrittweise. Investieren Sie zuerst in eine bezahlte Vorstudie: Sie ist die einzige Grundlage für eine belastbare Aufwandsschätzung.

Häufige Fragen

Ab wann gilt ein System als Legacy?

Nicht nach Alter, sondern nach Wirkung. Sobald Änderungen unverhältnismäßig teuer werden, Wissen an einzelnen Personen hängt, keine Sicherheitsupdates mehr kommen oder Integration nur über Umwege möglich ist, liegt ein Legacy-Problem vor. Ein zwanzig Jahre altes System mit Tests, Dokumentation und gepflegter Plattform ist kein Legacy-System – ein fünf Jahre altes ohne all das durchaus.

Modernisieren oder komplett neu bauen?

Neu bauen nur, wenn kein einzelner Engpass das Problem erklärt, der Quellcode fehlt oder unverständlich ist, oder die Architektur die Weiterentwicklung dauerhaft blockiert. In allen anderen Fällen ist ein gezielter Eingriff – Datenbank tauschen, Oberfläche erneuern, Schnittstelle ergänzen – günstiger und deutlich risikoärmer. Rechnen Sie beide Varianten durch, statt sie zu behaupten.

Was kostet eine Legacy-Modernisierung?

Seriös lässt sich das erst nach einer Bestandsanalyse sagen. Für die Analyse selbst sind 20 bis 60 Personentage realistisch, je nach Größe der Landschaft. Das Vorhaben danach reicht von wenigen Personentagen bei einem Rehost bis zu mehrjährigen Programmen bei einer Neuarchitektur. Wer ohne Analyse eine Zahl nennt, rät.

Wie lange dauert so ein Projekt?

Rehost und Relocate: Wochen bis wenige Monate. Replatform: drei bis neun Monate. Repurchase mit Datenmigration und Prozessanpassung: sechs bis achtzehn Monate. Vollständige Neuarchitektur eines geschäftskritischen Systems: zwei bis vier Jahre, sinnvollerweise in Teilschritten mit eigenem Nutzen.

Was tun, wenn niemand mehr weiß, wie das System funktioniert?

Fachlichkeit rekonstruieren, bevor irgendetwas gebaut wird: aus dem Verhalten des laufenden Systems, aus Datenbeständen, aus Interviews mit Anwenderinnen und Anwendern und – wenn vorhanden – aus dem Quellcode. Das ist ein eigener Arbeitsschritt von zehn bis vierzig Personentagen. Ihn zu überspringen ist der zuverlässigste Weg in ein gescheitertes Ablöseprojekt.

Ist ein Umzug in die Cloud schon eine Modernisierung?

Nein. Ein reiner Umzug (Rehost) verlagert dieselbe Anwendung auf andere Infrastruktur. Das kann sinnvoll sein – auslaufende Hardware, Rechenzentrumsschließung –, löst aber keines der fachlichen Probleme und senkt die Betriebskosten nicht automatisch. Nutzen entsteht erst, wenn im zweiten Schritt Bausteine ersetzt oder die Architektur angepasst werden.

Wie überzeugt man die Geschäftsführung von einem Modernisierungsbudget?

Nicht mit technischen Argumenten, sondern mit einer Gegenüberstellung: jährliche Kosten des Ist-Zustands inklusive manueller Arbeit und blockierter Vorhaben gegen die Projektkosten, über fünf Jahre gerechnet. Ergänzen Sie zwei bis drei konkrete Vorhaben, die heute an der Systemgrenze scheitern, und benennen Sie das Personalrisiko mit Datum – etwa den Renteneintritt der Person, die das System als Einzige versteht.

Weiterführende Ratgeber

• Altsystem ablösen – die Durchführung, wenn die Strategieentscheidung gefallen ist
• Access-Datenbank ablösen – der häufigste konkrete Anlassfall im Mittelstand
• Individualsoftware oder Standardsoftware? – die Make-or-Buy-Entscheidung hinter „Repurchase"
• Den richtigen Technologie-Stack wählen – wenn die Zieltechnologie ansteht
• Systemintegration & Schnittstellen – Altsysteme anbinden statt ersetzen
• Was kostet eine Cloud-Migration? – Preisrahmen für Rehost und Replatform

Anbieter im Verzeichnis: Softwareentwicklung, IT-Beratung, Cloud & DevOps.