Retten oder neu bauen? Die Migrations-Frage

Ob CCM-Plattform, COBOL-Mainframe oder SAP-ERP: Kaum eine Frage sorgt in IT-Abteilungen für mehr Unsicherheit als die nach Rettung oder Neubau eines Altsystems. Der Beitrag zeigt ein Bewertungsraster von Avision sowie Praxisbeispiele von Delta Software, Papyrus, Natuvion und SNP.

Der Migrations-Blues: Wenn Altsysteme Unternehmen ausbremsen

Wer lange genug im Enterprise-Umfeld unterwegs ist, kennt das ungute Gefühl, das der Begriff Softwaremigration auslöst. Der Grund liegt selten am fehlenden Willen zur Erneuerung, sondern an der Komplexität gewachsener Systeme, in denen über Jahrzehnte fachliches Wissen verbaut wurde, das kaum noch dokumentiert ist. Das Problem zeigt sich in mindestens drei unterschiedlichen Baustellen gleichzeitig: in der Kundenkommunikation, wo CCM-Plattformen wie IBM ASF/DCF oder Quadient/DOPiX abgekündigt werden, auf dem Mainframe, wo COBOL- und PL/I-Anwendungen seit Jahrzehnten geschäftskritische Logik tragen, und in der SAP-Landschaft, wo der Umstieg von ECC auf S/4HANA ansteht. Allen drei Baustellen gemeinsam ist eine Frage, die selten strukturiert beantwortet wird: Lohnt sich die Rettung des Bestehenden noch, oder ist der Punkt erreicht, an dem ein Neubau die klügere Wahl ist?

Das Problem ist kein Randthema. Nach Zahlen, die McKinsey zugeschrieben werden, betreiben rund 70 Prozent der Fortune-500-Unternehmen weiterhin Software, die älter als zwei Jahrzehnte ist. Der Erhalt dieser Systeme ist teuer: Das U.S. Government Accountability Office beziffert den Anteil des IT-Budgets, den US-Bundesbehörden allein für die Pflege von Altsystemen aufwenden, auf etwa 80 Prozent. Forrester wiederum geht davon aus, dass Unternehmen im Schnitt fast 20 Prozent ihres IT-Budgets für die Verwaltung technischer Schulden statt für neue Fähigkeiten ausgeben, und dass sich die Kosten für den Betrieb einer Plattform nach Ablauf des Herstellersupports etwa alle vier Jahre verdoppeln können. In den USA sollen technische Schulden laut einer Accenture-Analyse jährlich 2,41 Billionen US-Dollar kosten, ihre Beseitigung würde rund 1,52 Billionen US-Dollar erfordern.

Hinzu kommt ein struktureller Fachkräftemangel: Spezialisten für jahrzehntealte Formate und Programmiersprachen wie COBOL gehen in den Ruhestand, während neue Talente selten Erfahrung mit den betroffenen Systemen mitbringen. Wer hier auf veralteten Systemen verharrt, riskiert nicht nur steigende Kosten, sondern auch einen wachsenden Wettbewerbsnachteil.

Sieben Kriterien: Retten oder neu bauen?

Häufig wird die Entscheidung zwischen Modernisierung und Neubau entweder aus dem Bauch heraus oder viel zu spät getroffen, dann nämlich, wenn der Leidensdruck schon zu groß ist. Ein strukturiertes Bewertungsraster fehlt in der Praxis meist. Avision, ein auf Software Revival spezialisierter IT-Dienstleister aus Oberhaching bei München, plädiert deshalb für eine nüchterne Bestandsaufnahme, bevor überhaupt über Technologie gesprochen wird. „Unternehmen müssen nicht immer gleich alles über Bord werfen. Oft ist es klüger, das Gute zu behalten, das Schlechte zu verbessern und nur das Überflüssige zu entfernen“, sagt Nadine Riederer, CEO von Avision. Aus der Erfahrung zahlreicher Legacy-Bewertungen hat das Unternehmen sieben Kriterien destilliert, an denen IT-Verantwortliche selbst erkennen können, ob sich Refactoring und Modernisierung noch lohnen, oder ob eine Neuentwicklung sinnvoller ist:

Der Clou an diesem Bewertungsraster: Nicht jedes „Ja“ bei diesen Punkten bedeutet automatisch das Aus für ein System. Die Antwort ist selten binär, sondern eine differenzierte Einschätzung, bei der Teile eines Systems durchaus rettbar sind, während andere Komponenten ersetzt werden sollten. Avision positioniert sich hier ausdrücklich als unabhängiger Partner, der Unternehmen genau bei dieser „Stecker ziehen oder nicht“-Entscheidung berät, ohne von vornherein für die eine oder andere Richtung Partei zu ergreifen.

Migrationswege im Überblick: Fünf, sechs oder sieben Strategien

Für die strukturierte Bewertung von Migrationsprojekten hat sich in der IT ein Rahmenwerk etabliert, das ursprünglich von Gartner-Analyst Richard Watson im Jahr 2010 formuliert wurde. Die sogenannten fünf R sind Rehost, Refactor, Revise, Rebuild und Replace. Amazon Web Services hat dieses Modell später um die Strategien Retire und Retain erweitert, sodass heute häufig von sechs oder sieben Migrationswegen die Rede ist. Das Prinzip dahinter gilt für Softwareanwendungen ebenso wie für Dokumentenlogik in CCM-Systemen oder COBOL-Code auf dem Mainframe: Nicht jede Anwendung muss auf demselben Weg migriert werden, und die Wahl der Strategie entscheidet maßgeblich über Kosten, Risiko und Zeitrahmen eines Projekts.

Drei Baustellen, ein Prinzip: Dokumente, Mainframes, ERP

Wie das abstrakte Bewertungsraster in der Praxis wirkt, zeigt sich an drei sehr unterschiedlichen Technologiefeldern, in denen Unternehmen aktuell zwischen Rettung und Neubau entscheiden müssen.

Kundenkommunikation: Der Sonderfall CCM

CCM-Systeme erzeugen täglich Millionen individualisierter Dokumente für Web, E-Mail, Print und mobile Kanäle. Mit der Einstellung langjähriger Kernsysteme wie IBM ASF/DCF oder Quadient/DOPiX sowie der Verlagerung von Lösungen wie Assentis in die Cloud sind Versicherungen, Banken und viele weitere Branchen aus Compliancegründen gezwungen, auf neue Plattformen umzusteigen. Ein Anbieter, der sich seit drei Jahrzehnten explizit gegen erzwungene, disruptive Upgrades positioniert, ist Papyrus Software: Die Plattform entkoppelt Dokumentenlogik von der zugrunde liegenden Betriebssystem- und Cloud-Architektur und kombiniert für die Migration von Fremdsystemen einen KI-gestützten Dokumenten-Konverter mit einem automatisierten Test Center für den Pixel-für-Pixel-Abgleich.

Nach Angaben von Papyrus Software werden so über 80 Prozent der Konvertierungen automatisiert, in Marketingmaterialien ist sogar von bis zu 95 Prozent die Rede, wobei diese Spitzenwerte als Herstellerangabe zu verstehen sind. Wettbewerber wie IBM (hybrider Umstieg über Cloud Pak for Business Automation), OpenText (formalisiertes Accelerated Modernization Program für Exstream), Quadient (eigenes Migrationsgeschäft mit InspireXpress für DOPiX-Kunden), Smart Communications (cloudnatives Migration Studio, das auch von Papyrus wegmigriert), Messagepoint (semantische Content-Konsolidierung statt reiner Formatkonvertierung) und Compart (Kapselung des Altsystems über die Output-Management-Schicht DocBridge) verfolgen dabei jeweils eigene Varianten desselben Grundmusters aus Bestandsaufnahme, Pilotprojekt und schrittweisem Rollout.

Mainframe-Anwendungen: COBOL und PL/I mit Delta ADS weiterentwickeln

Eine ganz andere Ausgangslage herrscht bei klassischen Backend-Anwendungen auf dem Mainframe. Hier hilft keine Dokumentenkonvertierung, sondern die Entscheidung, ob COBOL- und PL/I-Code weiterentwickelt oder vollständig abgelöst wird. Delta Software Technology verfolgt seit fast 50 Jahren einen generativen Ansatz: Mit dem Werkzeug Delta ADS werden betriebliche Backend-Anwendungen in COBOL und PL/I nicht manuell programmiert, sondern aus höherwertigen Spezifikationen generiert. Nach Anbieterangaben sind auf diese Weise über zwei Milliarden Zeilen produktiven Codes entstanden, in Branchen von Banken über Versicherungen bis zu öffentlichen Verwaltungen.

Mit Delta IDS bindet der Anbieter diese generative Entwicklung in moderne Entwicklungsumgebungen wie Eclipse oder Microsoft Visual Studio ein, sodass Teams nicht mehr zwischen Mainframe-Terminal und moderner IDE wechseln müssen. Ein dokumentiertes Praxisbeispiel aus dem DACH-Raum ist die Bedag Informatik AG, der IT-Dienstleister des Kantons Bern: Das Unternehmen kombiniert die Entwicklung in C# und Delta ADS in einem einheitlichen .NET-Framework unter Microsoft Visual Studio, statt Mainframe- und moderne Entwicklung getrennt zu betreiben. Dass das Thema Substanz hat, zeigte sich Mitte Juni 2026, als Delta Software Technology zum Webinar „Delta ADS – Refresh & Connect“ einlud und dort aktuelle Neuerungen rund um Delta ADS 6 sowie die Einbindung in moderne Entwicklungsumgebungen vorstellte.

Einen anderen, KI-zentrierten Weg verfolgt Rocket Software, ein auf Mainframe-Modernisierung spezialisierter Anbieter mit eigener COBOL- und PL/I-Rocket-Enterprise-Suite für Re-Platforming auf verschiedene Zielumgebungen inklusive Cloud. Eine von Rocket Software in Auftrag gegebene, im Juli 2026 veröffentlichte Studie von Hanover Research unter IT-Führungskräften aus Banken und Finanzdienstleistern in den USA, Großbritannien, Frankreich, Deutschland und den Niederlanden zeigt, wie eng Modernisierung und Wissensverlust-Risiko zusammenhängen: 94 Prozent der befragten Führungskräfte stufen den KI-gestützten IT-Betrieb als hohe oder höchste Priorität ein, 81 Prozent bezeichnen die Qualifikationslücke bei Mainframe-Systemen als sehr oder extrem groß, und 87 Prozent erwarten, dass KI diese Lücke innerhalb der nächsten zwei Jahre erheblich oder drastisch verkleinert.

Mit dem Diagnose-Assistenten Rocket EVA bietet der Anbieter zudem ein Werkzeug für agentenbasierte KI-Unterstützung im z/OS-Betrieb, das Systemstatus und Abhängigkeiten in natürlicher Sprache erklärt, ohne dass Bedienende tiefes Plattformwissen mitbringen müssen, ein direkter Hebel gegen das von Avision beschriebene Wissensverlust-Risiko. Der Fall zeigt: Auch ein Mainframe-Werkzeug mit 50 Jahren auf dem Buckel kann modern bleiben, solange es sich weiterentwickelt statt nur zu überleben, ein Prinzip, das sich unmittelbar auf die Avision-Kriterien Wissensverlust-Risiko und technologische Isolation übertragen lässt.

SAP-Landschaften: Greenfield, Brownfield oder der Hybridweg

Auch beim Umstieg von SAP ECC auf S/4HANA stellt sich die Frage nach Rettung oder Neubau, hier meist unter den Begriffen Greenfield und Brownfield. Beim Greenfield-Ansatz wird eine komplett neue S/4HANA-Umgebung aufgesetzt und die Geschäftsprozesse konsequent an die SAP-Standardprozesse angepasst, ein sauberer digitaler Kern, der jedoch eine aufwendige Neuimplementierung samt Datenmigration erfordert. Der Brownfield-Ansatz führt dagegen ein technisches Upgrade des bestehenden Systems durch: geringeres Risiko und kürzere Projektlaufzeit, allerdings wandern historisch gewachsene Anpassungen und Datenaltlasten unverändert mit in die neue Umgebung. Zwischen beiden Polen hat sich ein Hybridmodell etabliert, das SAP selbst als Selective Data Transition bezeichnet und das am Markt häufig unter der von SNP geprägten Marke Bluefield firmiert.

Anbieter wie SNP mit dem Werkzeug CrystalBridge oder das ebenfalls auf SAP-Transformationen spezialisierte Unternehmen Natuvion ermöglichen damit eine selektive Migration: Unternehmen übernehmen nur die Daten und Prozesse, die tatsächlich benötigt werden, und nutzen den Umstieg gleichzeitig, um veraltete Prozesse zu bereinigen, statt sie unverändert mitzuschleppen. Nach Angaben von SNP wurden auf diese Weise bereits mehr als 12.500 Projekte umgesetzt, unter anderem beim Umstieg von Airbus Commercial Aircraft auf eine zentrale S/4HANA-Plattform sowie, ebenfalls dokumentiert, bei der SAP-Modernisierung der Würth IT GmbH. Für die Praxis heißt das: Wer bei SAP zwischen Greenfield und Brownfield schwankt, sollte den Hybridweg zumindest als dritte Option auf die Bewertungsliste setzen, insbesondere wenn Wissensverlust-Risiko und Grad der Verwobenheit hoch sind, ein kompletter Neuanfang aber wirtschaftlich nicht vertretbar ist. Die folgende schematische Übersicht ordnet die drei Ansätze anhand der von SNP und Natuvion beschriebenen Eigenschaften ein:

Was sagen die Analysten?

• Gartner hat mit dem 5R-Modell den analytischen Grundstein für strukturierte Migrationsentscheidungen gelegt und bewertet Anbieter kontinuierlich im eigenen Peer-Insights-Programm.

• Forrester fokussiert stärker auf die finanzielle Dimension und zeigt mit seinen Berechnungen zur technischen Schuld, dass Nichtstun keine kostenneutrale Option ist, sondern sich die Belastung mit der Zeit exponentiell verschärft.

• BARC, das im Bereich Business Intelligence eng mit der Eckerson Group zusammenarbeitet, liefert mit seinem Trend Monitor wichtige Evidenz dafür, dass Datenqualität inzwischen als größeres Hindernis wahrgenommen wird als reine Technologiefragen: Im BARC Data, BI and Analytics Trend Monitor 2026 nennen 45 Prozent der befragten Unternehmen Datenqualität als größtes Hindernis, mehr als doppelt so viele wie noch 2024, eine Erkenntnis, die sich unmittelbar auf Migrationsprojekte in CCM, Mainframe und SAP übertragen lässt.

• KuppingerCole wiederum beleuchtet die sicherheits- und identitätsbezogene Seite von Migrationen und weist etwa darauf hin, dass SAP Identity Management im Dezember 2027 das Ende des Mainstream-Supports erreicht, was branchenweit neue Migrationswellen bei Identitäts- und Zugriffssystemen auslöst.

Die Botschaft aller vier Analystenhäuser läuft auf einen gemeinsamen Nenner hinaus: Migration ist kein rein technisches Projekt, sondern eine Frage von Kosten, Datenqualität, Sicherheit und Geschwindigkeit zugleich, und wer diese vier Dimensionen getrennt betrachtet, unterschätzt das Risiko.

Migrationsaufwand und Budgetbelastung im Bild

Die folgenden beiden Grafiken fassen zentrale Kennzahlen aus dem CCM-Beispiel dieses Beitrags zusammen, exemplarisch für die Größenordnungen, die auch bei Mainframe- und SAP-Migrationen typisch sind. Bild 2 stellt die typische Projektlaufzeit einer klassischen, manuellen 1:1-Migration der Laufzeit einer KI-gestützten Migration mit integriertem Test Center gegenüber. Bild 3 ordnet drei Kennzahlen aus unterschiedlichen Quellen ein: den Anteil des IT-Budgets, den Forrester für technische Schulden veranschlagt, den Anteil, den US-Bundesbehörden laut GAO für die reine Pflege von Altsystemen aufwenden, sowie den Automatisierungsgrad, den KI-gestützte Konverter wie bei Papyrus Software beim Umzug von Dokumentenbeständen erreichen können.

Praktische Checkliste: So gelingt der Umstieg

Unabhängig davon, ob ein Unternehmen ein CCM-System, eine Mainframe-Anwendung oder eine SAP-Landschaft modernisiert, haben sich in der Praxis wiederkehrende Schritte bewährt. Am Anfang steht eine ehrliche Bestandsaufnahme entlang der sieben Avision-Kriterien: Welche Systeme sind im Einsatz, was kosten sie tatsächlich, und welche Anforderungen können sie nicht mehr erfüllen?

Darauf folgt ein belastbarer Business Case, der die Gesamtbetriebskosten des Verbleibs den Kosten einer Migration gegenüberstellt. Anschließend gilt es, für jede Anwendung oder Dokumentenklasse die passende Strategie aus dem Rehost-bis-Retain-Spektrum auszuwählen, statt pauschal auf einen Weg zu setzen, oder bei SAP zwischen Greenfield, Brownfield und Hybridansatz zu wählen.

Ein Pilotprojekt mit klar definierten Erfolgskriterien reduziert das Risiko, bevor die Migration in die Fläche geht. Automatisierte Testverfahren, wie sie etwa im Papyrus Test Center, bei Delta ADS oder in den Datenvalidierungswerkzeugen von SNP und Natuvion zum Einsatz kommen, schaffen dabei die nötige Kontrolle über die Konsistenz der Ergebnisse. Nicht zuletzt entscheidet das Change Management über Erfolg oder Misserfolg: Technologie allein löst selten ein Migrationsprojekt, die betroffenen Fachbereiche müssen frühzeitig eingebunden werden.

Fazit: Strukturierte Entscheidung statt Bauchgefühl

Der Migrations-Blues ist kein Naturgesetz, sondern die Folge aufgeschobener Entscheidungen. Ob CCM-Plattform, COBOL-Mainframe oder SAP-ERP: Unternehmen, die ihre Altsysteme strukturiert anhand von Kriterien wie denen von Avision bewerten, die passende Migrationsstrategie aus dem Rehost-bis-Retain-Spektrum wählen und moderne, KI-gestützte Werkzeuge für die eigentliche Konvertierung nutzen, können Projektlaufzeiten von Jahren auf Monate verkürzen und gleichzeitig das Risiko für den Geschäftsbetrieb deutlich senken.

Der Mehrwert liegt damit nicht allein in geringeren Kosten, sondern vor allem in der zurückgewonnenen Handlungsfähigkeit: Wer einmal sauber migriert hat, kann künftige Anforderungen, von neuen Kanälen bis zu regulatorischen Änderungen, deutlich schneller umsetzen. Weiterführende Einordnungen zu IT-Strategie und Migration finden Leserinnen und Leser fortlaufend auf it-daily.net.

Q&A: Häufige Fragen zur Migration von Altsystemen