Dieser Service umfasst die Entwicklung einer Migrationsstrategie, die Auswahl der geeigneten Architektur sowie die Definition der einzusetzenden Tools und des schrittweisen Vorgehens. Die Beratung erfolgt vor Beginn der eigentlichen Migration.
Im Rahmen dieses Services wird die bestehende Mainframe-Infrastruktur analysiert, einschließlich Mainframe-Version, Workload, Umfang des COBOL- und PL/I-Codes, JCL-Jobs, Datenbankabhängigkeiten und Anwendungsintegrationen. Die Ergebnisse werden schriftlich dokumentiert.
Bei dieser Strategie werden COBOL-, PL/I- und Assembler-Anwendungen in moderne Laufzeitumgebungen überführt. Dies erfolgt durch automatisierte Konvertierung, manuelle Überarbeitung des Codes bei geschäftskritischen Anwendungen sowie den Ersatz mainframebasierter APIs. Vor dem Go-live wird das Ergebnis mit dem ursprünglichen System validiert.
Hier werden Mainframe-Anwendungen auf AWS, Azure oder Google Cloud migriert. Die Cloud-Architektur wird je nach der Komplexität, Integrationsgrad und geschäftlicher Relevanz des Anwendungsportfolios festgelegt.
Bei diesem Ansatz werden RPG-, CL- und COBOL-Anwendungen von IBM AS/400- und IBM iSeries-Plattformen migriert. Die Migration umfasst Codekonvertierung, Migration der DB2 for i-Datenbank, Ersatz des Job-Schedulers sowie die Anpassung bestehender Integrationen.
Dieser Service setzt die Migration von COBOL- und FORTRAN-Anwendungen auf Unisys MCP- und OS 2200-Plattformen voraus. Dabei werden Dateisysteme, Transaktionsverarbeitung und plattformspezifische Jobsteuerungssprachen entsprechend angepasst und migriert.
VSAM-Datensätze, IMS-hierarchische Datenbanken und DB2-Datenbanken werden in moderne relationale und nicht-relationale Datenbanksysteme überführt, darunter PostgreSQL, Microsoft SQL Server und Amazon Aurora.
Batch-Jobs werden auf Plattformen wie Apache Airflow, AWS Batch, Azure Batch oder Kubernetes-basierte Scheduler migriert. Die bestehende Logik wird auf die Zielplattform übertragen und dort implementiert.
Mainframe-Anwendungen werden schrittweise modernisiert, indem RESTful APIs integriert, ausgewählte Batch-Jobs auf verteilte Plattformen verlagert und Batch-Prozesse in ereignisgesteuerte Prozesse transformiert werden.
Monolithische COBOL-Anwendungen werden in Microservices-basierte Architekturen überführt. VSAM- und IMS-Datenbanken werden durch cloudbasierte Datenbanken ersetzt, und eine ereignisgesteuerte Kommunikation zwischen den migrierten Microservices wird etabliert.
Die Validierung stellt die funktionale Gleichwertigkeit zwischen Quell- und Zielsystem sicher. Dazu gehören Output-Vergleiche, Lasttests und Regressionstests in jeder Migrationsphase. Für regulierte Branchen werden entsprechende Validierungsdokumente erstellt.
Nach der Migration wird das System kontinuierlich überwacht, Leistungsprobleme werden behoben und kontinuierliche DBA-Services bereitgestellt, darunter Wartung, Backup-Kontrolle, Replikationsmonitoring sowie Incident-Support im Rahmen eines Retainer-Modells.
Die Geschäftslogik befindet sich in großen, kaum dokumentierten COBOL-Anwendungen ohne klare Teststrategie. Entwickler vermeiden Änderungen, da Nebenwirkungen schwer vorhersehbar sind. Selbst kleinere Fehlerkorrekturen benötigen unverhältnismäßig viel Zeit.
Das IBM-Preismodell basiert auf MIPS. Dadurch steigen die Softwarekosten, obwohl sich die Workloads kaum verändern, insbesondere nach Hardware-Upgrades. Wenn man ein Sub-Capacity-Preismodell verwendet, besteht bei Änderungen der Workload ein zusätzliches Risiko.
Geschäftslogik, Batch-Prozesse und Datenflüsse sind nur einem kleinen, erfahrenen Team bekannt. Eine aktuelle und vollständige Dokumentation der Systemarchitektur und Prozesse fehlt.
Jedes neue System, das mit dem Mainframe verbunden werden soll, benötigt eine eigene Integrationsschicht. Der Aufwand und die Kosten für diese Integrationen bremsen die Einführung neuer Tools im Unternehmen.
Das traditionelle Batch-Fenster im Hintergrund reicht nicht mehr für die Anforderungen an Echtzeit-Daten. Die Architektur lässt sich schwer ändern, weil die Batch-Schicht fest im System verankert ist.
Für Compliance- und Reporting-Zwecke müssen Daten manuell aus Mainframe-Datenspeichern exportiert werden, etwa aus VSAM-Dateien oder IMS-Datenbanken, da moderne BI- und Reporting-Tools nicht direkt auf diese Daten zugreifen können.
IBM z/OS Mainframe-Anwendungen
IBM AS/400 / iSeries (RPG- und COBOL-basiert)
Unisys MCP- und OS 2200-Umgebungen
Legacy-monolithische Anwendungen (z. B. COBOL und PL/I)
Mainframe-Batchverarbeitung und JCL-Job-Scheduler
VSAM- und IMS-hierarchische Datenbanken
Legacy-Anwendungen und zugehörige Infrastruktur (z.B. legacy ERPs)
Core-Banking- und Zahlungsabwicklungs-Anwendungen
Legacy-Gesundheitssysteme
On-Premise-Transaktionssysteme (OLTP)
Data-Warehouse- und Reporting-Anwendungen auf Mainframes
Bei diesem Ansatz wird der Mainframe-Workload in eine Cloud- oder verteilte Infrastruktur migriert, ohne dass der Anwendungscode geändert wird. Mithilfe von Mainframe-Emulationssoftware läuft der bestehende COBOL- und PL/I-Code auf Standardhardware.
Bei diesem Ansatz wird der Mainframe-Workload auf eine moderne Plattform wie Java, .NET oder cloudbasierte Systeme migriert. Dabei sind nur minimale Codeänderungen nötig, um mainframe-spezifische APIs und Datenzugriffe zu ersetzen.
Bei diesem Ansatz wird der bestehende Code der Mainframe-Anwendung neu geschrieben und an moderne Architekturprinzipien angepasst. Der bisher prozedurale COBOL-Code wird durch objektorientierten Code ersetzt.
Ein Teil des Workloads wird vom Mainframe migriert, während der andere Teil auf dem Mainframe verbleibt. APIs und Message Queues sorgen für die Integration beider Systeme und minimieren die Mainframe-Kosten, während dieser schrittweise abgeschaltet wird.
Die häufigsten Mainframe-Anwendungen sind zentrale Bankensysteme, Zahlungsabwicklungssysteme und Systeme für versicherungsmathematische Berechnungen. Diese Anwendungen verarbeiten Transaktionen, bei denen Datenverlust oder Abweichungen zwischen Quell- und Zielsystem nicht akzeptabel sind. Es werden parallele Betriebszeiten durchgeführt, gefolgt von einem Abgleich der Ergebnisse auf Transaktionsebene vor der Systemumstellung.
Anwendungen für Anspruchsbearbeitung, Rechnungsstellung für medizinische Leistungen und klinisches Datenmanagement auf Mainframe-Plattformen verarbeiten personenbezogene Gesundheitsinformationen (PHI) und müssen HIPAA-konform sein. Die Validierung der Datenverarbeitung auf der Zielplattform erfolgt im Rahmen der Compliance-Prüfung.
Anwendungen für Lagerverwaltung, Auftragsbearbeitung und Treueprogramme, ursprünglich auf Mainframe-Computern implementiert, werden auf Cloud-Plattformen migriert, die erhöhte Lasten während Spitzenzeiten problemlos bewältigen können.
Telekommunikationsanwendungen wie Abrechnung, Mediation und Teilnehmerverwaltung laufen oft auf Mainframes und verarbeiten täglich Millionen von Datensätzen. Batch-Zeitfenster und Systemverfügbarkeit werden bei der Migrationsplanung berücksichtigt.
Anwendungen für Produktionsplanung, Materialbedarfsplanung und Supply-Chain-Management, die zuvor auf AS/400- und z/OS-Systemen betrieben wurden, werden migriert. Dabei bleibt die Geschäftslogik, die oft in RPG- und COBOL-Programmen eingebettet ist, vollständig erhalten.
Anwendungen für Frachtmanagement, Routenoptimierung und Zollabwicklung, die ursprünglich auf Mainframes betrieben wurden, werden auf verteilte Plattformen migriert, die besser mit modernen Logistik-APIs kompatibel sind.
Regierungsbehörden und Institutionen des öffentlichen Sektors haben einige alte Mainframe-Systeme, die kritische Anwendungen für Bürger betreiben. Migrationspläne berücksichtigen interne Abstimmungsprozesse, lange Validierungszeiträume und branchenspezifische Vorschriften zur Datenverarbeitung.
