Legacy-System ablösen
Ein Altsystem geht nicht in Rente, weil es alt ist, sondern wenn es Ihr Geschäft mehr kostet als es trägt.
Legacy-System ablösen, ohne die Produktion anzuhalten
Über Jahre gewachsene Software steuert oft genau die Prozesse, an denen der Umsatz hängt. Das macht den Austausch heikel: Wer das Rückgrat ersetzt, riskiert Stillstand. Also bleibt es stehen. Es funktioniert doch, lautet das Argument. Übersehen wird dabei, wie hoch der Wartungsaufwand inzwischen ist und wie viel Tempo jede neue Anforderung kostet.
Wir lösen Legacy-Systeme ab, während sie laufen. Zuerst rekonstruieren wir, was Ihr System fachlich tut. Dann ersetzen wir es Baustein für Baustein. Abgeschaltet wird es erst, wenn der Ersatz nachweislich dasselbe leistet.
Aus über 35 Jahren mit gewachsenen Systemen wissen wir: Der Nachweis ist der schwierige Teil, nicht der Neubau.
Less Technology. Better Business.
Warum Unternehmen ihr Altsystem mit uns ablösen
Verständnis vor Veränderung
Bevor eine Zeile ersetzt wird, rekonstruieren wir die Fachlogik Ihres Altsystems aus dem Code. Auch dann, wenn die Dokumentation fehlt.
Kein Stillstand im Betrieb
Ihr Altsystem läuft weiter, während das neue System Modul für Modul übernimmt. Jedes Ergebnis wird laufend gegen das alte gespiegelt.
Betriebskosten, die spürbar sinken
Wartung und Lizenzen der alten Plattform entfallen mit der Abschaltung. Neue Anforderungen lassen sich danach deutlich schneller umsetzen.
Herstellerneutral, ohne Bindung
Wir empfehlen die Architektur, die zu Ihrem Fall passt, nicht die zu unserer Auslastung. Nach der Analyse entscheiden Sie frei.
Ablösen oder modernisieren? Woran Sie das entscheiden
Nicht jedes Altsystem muss verschwinden. Manches lässt sich mit erneuerter Technologie weiterbetreiben, anderes trägt keine neue Anforderung mehr. Diese Entscheidung fällt vor dem Projekt, nicht mitten im Umbau. Wer sie überspringt, modernisiert am Ende ein System, das ohnehin weg soll.
| Ihre Ausgangslage | Der Weg, den wir empfehlen |
|---|---|
| Die Fachlogik trägt noch, veraltet sind Plattform und Frameworks. | Altsystem modernisieren statt ersetzen: Wir erneuern Code und Laufzeitumgebung im Rahmen einer Software-Modernisierung, das System bleibt. |
| Die Architektur lässt neue Fachanforderungen nicht mehr zu. | Schrittweise ablösen: Ein neues System übernimmt Modul für Modul, das alte wird am Ende abgeschaltet. |
| Kaum jemand versteht das System noch, automatisierte Tests fehlen. | Erst Klarheit schaffen: Der Software Health Check bewertet Code, Architektur und Risiko, bevor Sie sich festlegen. |
| Die Strukturen sind so verbaut, dass auch großes Refactoring sie nicht mehr löst. | Ersatz in einem Zug: Ohne Basis für Weiterentwicklung ist der Neubau der günstigere Weg. |
| Für das System gibt es keine Sicherheitsupdates mehr, oder neue gesetzliche Vorgaben lassen sich darin nicht abbilden. | Ablösen, und zwar mit Priorität: Beides lässt sich am Altsystem nicht dauerhaft reparieren. |
Bei produktionskritischen Systemen ist die schrittweise Ablösung unser Standardweg. Ist ein Komplettumstieg sinnvoller, sagen wir das offen, mit einer Begründung, die Sie intern weitergeben können.
Für eine reine Standortbestimmung genügt oft der Software Health Check. Soll das System bleiben und erneuert werden, sind Sie bei der Software-Modernisierung richtig. Wartung und Weiterentwicklung nach dem Go-live betreut ein eigenes Team.
Was nach der Ablösung möglich wird
Die meisten Vorhaben, die heute auf der Liste stehen, scheitern nicht am Budget, sondern an der Architektur darunter. KI-Anwendungen brauchen Zugriff auf saubere Daten, Partner brauchen dokumentierte Schnittstellen, Auswertungen brauchen ein Datenmodell, das mehr kann als das Tagesgeschäft. Ein Altsystem liefert davon nichts, und keine Schicht darüber holt das nach. Wer ablöst, schafft die Grundlage.
Bevor Sie ersetzen: verstehen, was das Altsystem wirklich tut
Ablöseprojekte scheitern selten an der neuen Technologie. Sie scheitern daran, dass niemand mehr sicher sagen kann, welche Regeln im alten System stecken.
Warum niemand mehr weiß, was im Altsystem steckt
Wie verbreitet das ist, zeigt unsere Studie zur Technologieeffizienz: 45 % der IT-Verantwortlichen nennen veraltete Dokumentation als Ursache technischer Schulden, 39 % fehlende Dokumentation. Gehen die Menschen in den Ruhestand, die das System gebaut haben, geht das Wissen mit.
Wie wir die Fachlogik zurückholen und absichern
Dieser Verlust ist heute reparabel. Mit Agentic Domain Discovery rekonstruieren wir die Fachlogik KI-gestützt aus dem Quellcode und machen sie prüfbar. Ein Versprechen ist das nicht: Je verstreuter die Logik im Code liegt, desto mehr bleibt Kopfarbeit. Was wir finden, ordnen wir mit Ihren Fachbereichen ein.
Ihr Quellcode geht dabei nicht an fremde Server. Wir betreiben die Analyse-Modelle in einer abgekapselten Trusted Zone, ohne Training auf Ihren Daten.
Parallel entsteht das Sicherheitsnetz. Wir zeichnen das heutige Systemverhalten als Referenzzustand auf und gleichen jede Änderung automatisiert dagegen ab. So merken Sie es sofort, wenn eine Regel verloren geht, und nicht erst im Monatsabschluss.
Im kostenlosen Beratungstermin ordnen wir Ihre Ausgangslage ein.
So läuft eine Ablösung im laufenden Betrieb
Legacy-Systeme lösen wir am häufigsten nach dem Strangler-Pattern ab: Neue Funktionen entstehen neben dem Altsystem und gehen einzeln in Betrieb, bis nichts mehr auf das alte zugreift. Kein Umschalttermin, an dem alles gleichzeitig gut gehen muss.
Wie das neue System innen aussieht, richtet sich nach dem Fachlichen, nicht nach dem Lehrbuch. Ob klar getrennte Bausteine wie in einer hexagonalen Architektur oder ein schlanker Neubau als maßgeschneiderte Softwarelösung: Entschieden wird das im Zielbild, mit Blick darauf, was Ihr Team später selbst betreiben kann. Bei kritischen Systemen begleitet ein Bereitschaftsteam den Umbau.
Inventarisierung und Zielbild
Wir lesen Codebasis, Datenflüsse und Schnittstellen und gehen sie an einem konkreten Vorgang durch, von der Eingabemaske bis in die Datenbank. Ob COBOL auf dem Mainframe, eine gewachsene AS/400-Anwendung oder ein monolithisches .NET-System aus den frühen 2000ern: Architekturdiagramme fehlen häufig, Dokumentation ist selten aktuell. Am Ende steht ein Schnittplan: welcher Fachbereich wann umzieht.
Erstes Modul im Parallelbetrieb
Wir beginnen mit einem Baustein, der produktiv genutzt wird, aber nicht der riskanteste ist. Alt und Neu laufen parallel, jedes Ergebnis wird gegen den aufgezeichneten Referenzzustand geprüft. Weicht etwas ab, fällt es im laufenden Abgleich auf, nicht erst nach dem Umstieg.
Modul für Modul übernehmen
Die Reihenfolge folgt Nutzen und Risiko, nicht der Systemarchitektur. Jeder übernommene Baustein bekommt automatisierte Tests, bevor der nächste beginnt. Bei großen Systemen zieht sich das über Monate bis Jahre. Dafür bleibt der Betrieb durchgehend stabil, statt an einem Wochenende auf dem Spiel zu stehen.
Altsystem abschalten
Zum Schluss greift kein Prozess mehr auf das Altsystem zu, und wir schalten es kontrolliert ab. Der Parallelbetrieb ist ein Mittel für den Übergang, kein Dauerzustand: Läuft das Alte aus Vorsicht weiter, bleibt die Ersparnis aus.
Wie lässt sich ein Legacy-System ablösen und dabei der Geschäftsbetrieb sichern? Unsere Referenzen geben Einblick in Projekte, bei denen aus gewachsenen Strukturen leistungsfähige, zukunftssichere Systeme wurden.
-
Zur ReferenzVersicherung: Enterprise Architecture ManagementBanken/Versicherungen/FSIIT-Beratung & StrategieIT ModernisierungZur ReferenzZukunftsfähige IT-Landschaft für einen Versicherungskonzern
Zur ReferenzIst-Analyse bis auf Codeebene, Zielarchitektur je Fachdomäne, Transformations-Roadmap, Methode Schnellbebauung, Aufbau des EAM-Teams
Zur ReferenzKlares Zielbild je Fachdomäne, bestimmter EAM-Reifegrad, transparenter Investitionsbedarf, tragfähige Teamstrukturen
-
Zur NOW ReferenzNOW: Nationale Organisation für den Wandel in der Mobilität: Aufbau eines Datawarehouse SystemsCloudData/DatenplattformenIT-Beratung & StrategieZur NOW ReferenzDatengrundlage für flächendeckende Ladeinfrastruktur in Deutschland
Zur NOW ReferenzCloud-Datawarehouse für Integration & Analyse vieler diverser Datenquellen (AWS)
Zur NOW ReferenzSolide Architektur, Single Point of Truth sichert datenbasierte Evaluierung des Ladesäulenbedarfs
-
Zur NETZSCH ReferenzNETZSCH: Entwicklung einer IoT-PlattformCloudData/DatenplattformenIoTZur NETZSCH ReferenzEinheitliche IoT-Plattform für 3 Geschäftsbereiche, Harmonisierung der bestehenden IoT-Lösungen
Zur NETZSCH ReferenzIoT-Geräteanbindung, Visualisierungssoftware für Datenauswertung, Cloud-Infrastruktur, Betrieb
Zur NETZSCH ReferenzSchnelles Testen in der Cloud-Infrastruktur, schnelle Integrierbarkeit von Anwendungsfällen wie Predictive Maintenance, Prozessoptimierungen etc.
-
Zur inCTRL ReferenzinCTRL Solutions: Modernisierung der IoT-Plattform für WasseraufbereitungsanlagenCloudIoTIT ModernisierungZur inCTRL ReferenzIoT- & Software-Modernisierung, Integration neuer Funktionen
Zur inCTRL ReferenzAufbau Data Warehouse, Integration von Microservices, automatisierte Qualitätssicherung, Continuous Integration & Continuous Deployment (CI/CD)
Zur inCTRL ReferenzVerbesserte Resilienz, Wartbarkeit & Weiterentwicklungsfähigkeit der Plattform
-
Zur Schöck Bauteile ReferenzSchöck Bauteile: Verbesserung des AnforderungsprozessesIT-Beratung & StrategieQuality EngineeringIT ModernisierungZur Schöck Bauteile ReferenzVerbesserte Bemessungssoftware für den Bau tragender Gebäudebauteile
Zur Schöck Bauteile ReferenzNeuer Digital Design-Ansatz, UX-Konzepte, UI-Designs, Nutzerzentrierung
Zur Schöck Bauteile ReferenzHöhere User-Zufriedenheit, bessere Software mit weniger Aufwand
-
Zur BMW Group ReferenzBMW Group: Ablösung eines produktionskritischen AltsystemsIT-Beratung & StrategieIT ModernisierungProduktionZur BMW Group ReferenzIT-Modernisierung, Ablösung eines 20 Jahre alten Legacy-Systems
Zur BMW Group ReferenzSchrittweise Migration auf moderne, flexible Architektur & Plattform
Zur BMW Group ReferenzHohe Stabilität & Ausfallsicherheit, langfristige Skalierbarkeit
-
Zur Bayernwerk ReferenzBayernwerk: Wissensmanagement über TeamsCloudIT-Beratung & StrategieIT ModernisierungZur Bayernwerk ReferenzTeams-App für Servicetechnikkräfte
Zur Bayernwerk ReferenzNutzerzentriertes, intuitives UX/UI-Design
Zur Bayernwerk ReferenzIdentifizierung & Nutzbarmachung von implizitem Wissen im Unternehmen
-
Zur DEKRA ReferenzDEKRA: Dank Co-Creation zur modernen Enterprise ArchitectureCloudIT-Beratung & StrategieIT ModernisierungZur DEKRA ReferenzBetriebliche & technische Harmonisierung der Legacy IT-Landschaft
Zur DEKRA ReferenzEnterprise Architecture als Co-Creation der Lead Architekten aller IT-Geschäftseinheiten
Zur DEKRA ReferenzEA Community weltweit für alle operativen Einheiten
-
Zur BMW Group ReferenzBMW Group: Remote Software Upgrade für FahrzeugeCloudCybersecurityIoTZur BMW Group ReferenzSoftware Upgrades ohne erforderlichen Besuch im Servicebetrieb
Zur BMW Group ReferenzBackend-System zur Over-the-Air-Kommunikation mit dem Fahrzeug, 24/7 Support
Zur BMW Group ReferenzIT-Security, mehr Komfort, On-Demand-Versorgung mit neuen Features
Worauf Sie bei einem Anbieter für die Legacy-Ablösung achten sollten
Wer ein Legacy-System ablösen will, findet viele Anbieter mit ähnlichem Versprechen. Vier Fragen trennen die, die neu bauen können, von denen, die auch das Alte verstehen:
| Frage an jeden Anbieter | Unsere Antwort |
|---|---|
| Wie rekonstruiert er die Fachlogik, wenn die Dokumentation fehlt? | KI-gestützte Code-Analyse und Referenzzustände statt Rückfragen an Menschen, die nicht mehr im Haus sind. |
| Hat er produktionskritische Systeme schon abgelöst, nicht nur Randanwendungen? | Über 800 Großsysteme und mehr als 10.000 Personenjahre im High-End-Software-Engineering. |
| Womit belegt er, dass das neue System dasselbe leistet? | Automatisierte Tests gegen einen aufgezeichneten Referenzzustand, geprüft in jeder Phase. |
| Bindet er Sie an sich oder an eine Plattform? | Herstellerneutral, mit Wissenstransfer im gemischten Team. Nach der Analyse entscheiden Sie, wer den Plan umsetzt. |
Im kostenlosen Beratungstermin klären wir, ob ablösen oder modernisieren der richtige Weg ist.
Häufige Fragen zur Ablösung von Legacy-Systemen
Was ist ein Legacy-System?
Ein Legacy-System, auch Altsystem genannt, ist eine über Jahre gewachsene Anwendung, die weiterhin wichtige Geschäftsprozesse steuert, technisch aber nicht mehr tragfähig ist. Typisch sind veraltete Frameworks, schwer wartbarer Code und fehlende Schnittstellen. Diese Altsoftware funktioniert also noch, verursacht aber steigende Kosten und bremst neue Anforderungen aus.
Was kostet es, ein Legacy-System abzulösen?
Die Kosten einer Legacy-Ablösung richten sich nach Größe, Zustand und Kritikalität des Systems, deshalb beginnen wir mit einer kalkulierbaren Analysephase. Danach kennen Sie Zielbild, Aufwand und Reihenfolge und entscheiden auf dieser Basis. Wartung, Lizenzen und Spezialwissen für die alte Plattform fallen mit der Abschaltung weg, was die Betriebskosten dauerhaft senkt.
Lassen sich auch COBOL- und Mainframe-Systeme ablösen?
Ja, und es ist der häufigste Fall in produktionskritischen Umgebungen. Die Schwierigkeit liegt selten in der Sprache, sondern darin, dass die Fachlogik über Jahrzehnte in Programme, Jobs und Datenbankprozeduren gewandert ist und niemand mehr den Überblick hat. Gleiches gilt für AS/400-Anwendungen und monolithische .NET- oder Java-Systeme, die technisch jünger, strukturell aber vergleichbar verbaut sind.
Wie lange dauert es, ein Altsystem abzulösen?
Die Dauer hängt an Systemgröße und Datenmenge: kleinere Anwendungen sind in wenigen Monaten abgelöst, produktionskritische Legacy-Systeme brauchen mehrere Jahre. Die Zahl der angebundenen Schnittstellen verschiebt den Rahmen stärker als die Codemenge. Weil Alt und Neu parallel laufen, profitieren Sie von den ersten umgezogenen Modulen lange vor dem Projektende.
Was passiert bei der Ablösung mit den Daten aus dem Altsystem?
Die Bestandsdaten ziehen mit um, und zwar geprüft: Wir gleichen Datenbestände zwischen Alt- und Neusystem ab, bevor ein Modul die Verantwortung übernimmt. Historische Daten sind dabei der aufwendigere Teil, weil sie über Jahre inkonsistent gewachsen sind. Deshalb beginnt die Bereinigung früh und nicht erst kurz vor der Umschaltung.
Mit welchen Technologien und Programmiersprachen arbeitet MaibornWolff bei der Legacy-Ablösung?
Auf eine Ausgangstechnologie sind wir nicht festgelegt: In Ablöseprojekten treffen wir COBOL, Delphi, ältere Java- und .NET-Anwendungen, C/C++, PHP oder Python an. Entscheidend ist nicht die alte Sprache, sondern das Zielbild. Wir migrieren in die Technologie, die zur künftigen Architektur passt, häufig in containerbasierte Umgebungen mit Docker und Kubernetes, auf PostgreSQL oder in Frontends mit React und Angular.
Kann auch neuere Software zum Legacy-System werden?
Ja. Legacy ist keine Frage des Alters oder der Programmiersprache, sondern des Zustands: schwer wartbarer Code, veraltete Abhängigkeiten, fehlendes Wissen im Team oder eine Architektur, die nicht mehr zu den Anforderungen passt. Auch in einer heute modernen Sprache entsteht über die Jahre wieder Legacy-Code. Eine Ablösung ist deshalb nie nur ein Sprachwechsel.
Warum MaibornWolff?
Als einer der innovativsten IT-Dienstleister mit großer Leidenschaft für KI konzentrieren wir uns vollständig auf das Projektgeschäft und individuelle Software-Entwicklung – ohne eigene Produkte. Um an der Spitze zu bleiben, investieren wir kontinuierlich in unser Team aus Digital Technology Engineers und entwickeln digitale Lösungen, die durchdacht, effizient und auf das Wesentliche reduziert sind.
Unser Grundsatz: Simplizität statt Komplexität. Wir entwickeln nur, was wirklich gebraucht wird – maßgeschneidert, nutzbringend und zuverlässig. Unsere Ergebnisse sprechen für sich. Mit über 800 Großsystemen und mehr als 10.000 Personenjahren Erfahrung im High-End-Software-Engineering zählen wir zu den wenigen, die selbst größte und komplexeste IT-Landschaften zuverlässig realisieren. Dank enger Partnerschaften mit führenden Hyperscalern betreiben unsere Kunden ihre Lösungen in den modernsten und leistungsfähigsten Umgebungen der Gegenwart.
Less Technology. Better Business.