// DEEP DIVE | LEGACY INTEGRATION
IBM i (AS/400) Modernisierung: Legacy-Integration statt Innovation-Theater
AS/400 Modernisierung bedeutet nicht automatisch Migration. Die meisten Digitalisierungsprojekte scheitern genau am Versuch, funktionierende Kerne komplett zu ersetzen. Wir gehen einen anderen Weg: Wir nutzen Ihre stabile IBM i als Fundament und machen sie via API sprechfähig für die KI-Ära. Bewährter RPG-Code bleibt, wo er ist, moderne Schnittstellen kommen dazu.
DAS PROBLEM
67 Prozent der Migrationen scheitern, weil sie nicht nötig waren
In jedem IBM i Bestand steckt jahrzehntealter RPG-Code, der komplexe Business-Logik abbildet. Preiskalkulationen, Provisionsmodelle, Sondervereinbarungen mit Schlüsselkunden, Material-Konfigurationen. Vieles davon ist nirgends sauber dokumentiert, weil die Logik mit dem Unternehmen gewachsen ist. Wer das in Python neu schreibt, baut Fehler ein, die niemand sieht, bis ein Kunde sich beschwert.
Trotzdem dominiert in vielen Boards die Erzählung: "Die AS/400 muss weg, das ist Steinzeit." Dahinter steckt selten ein geschäftliches Argument, häufig nur Mode. Die IBM i ist in Sachen Transaktionssicherheit, Uptime und DB2-Performance unschlagbar. Was fehlt ist nicht Stabilität, sondern Konnektivität.
Wir nennen das Innovation-Theater: viel Bewegung, viel Budget, am Ende läuft die alte Maschine immer noch im Keller und macht den Umsatz. Die ehrliche Frage ist nicht, ob man die IBM i ablöst, sondern wie man sie an die moderne Welt anbindet, ohne sie anzufassen.
Warum scheitern Migrationen von AS/400 Systemen so oft?
Weil in jahrzehntealtem RPG-Code komplexe Business-Logik steckt, die kaum dokumentiert ist. Ein Rip-and-Replace führt oft zu Datenverlust und Betriebsstillstand. Die pragmatische Lösung ist daher nicht die Ablösung, sondern die Integration via API-Wrapper. Bewährte ILE RPG Service Programs werden zu REST-Endpunkten, der DB2 for i öffnet sich via SQL für KI-Modelle, geschlossene Anwendungen ohne Source Code werden über 5250 Terminal Emulation per RPA bedient. Die Maschine im Keller bleibt, die Schnittstellen nach außen werden modern.
Drei Wege auf die IBM i, je nach Ausgangslage
/ UNSER ANSATZ
01
Schritt 01
RPG zu REST API (Der Wrapper)
Sie haben die Preiskalkulation, Bonusberechnung oder Material-Konfiguration schon in RPG programmiert. Sie funktioniert seit Jahren fehlerfrei. Statt sie in Python neu zu schreiben und Fehler einzubauen, bauen wir einen Wrapper um die bestehenden ILE RPG Service Programs. Der Webshop oder das KI-Modell fragt via JSON an, die AS/400 rechnet wie immer, und antwortet über eine moderne REST-Schnittstelle. Aus jahrzehntealter Logik wird ein Microservice.
02
Schritt 02
DB2 SQL-Zugriff für KI-Modelle
KI-Modelle brauchen Daten in Form, die sie verarbeiten können. Wir richten performante SQL-Views auf Ihre physischen Files (PF/LF) ein, damit ein KI-Agent Lagerbestände, Kundenhistorien oder offene Posten in Echtzeit abfragen kann. Ohne dass jemand den Green Screen öffnen muss. Die SQL-Views sind read-only, Schreibzugriffe laufen weiter über die bestehenden RPG-Programme.
03
Schritt 03
5250 Terminal Emulation als Fallback
Wenn kein Source Code mehr verfügbar ist (typisch bei Third-Party-Anwendungen, deren Hersteller seit Jahren verschwunden ist), greifen wir auf 5250 Emulation per RPA zurück. Ein Bot emuliert den User am Terminal, liest definierte Bildschirmpositionen aus und tippt Eingaben. Nicht elegant, aber extrem wirksam und in Tagen umsetzbar, wo sonst eine sechsstellige Neuentwicklung notwendig wäre.
04
Schritt 04
Sicherheit und Berechtigungskonzept
Wir nutzen ausschließlich die nativen IBM i Berechtigungsobjekte. Ein dedizierter Integration User bekommt nur die Object Authorities, die er für die definierten Use Cases braucht. Keine globalen Berechtigungen, keine Modifikationen am bestehenden Profil-Konzept. Jede Aktion ist im IBM i Journal nachvollziehbar.
Ihr stabilster Server muss nicht der dümmste sein
Die IBM i ist in Sachen Transaktionssicherheit, Datenintegrität und Uptime unschlagbar. Das Problem ist nicht die Maschine, sondern die Isolation. Wir brechen das Silo auf, ohne das Fundament zu beschädigen. Ihr RPG-Programmierer pflegt weiter den Core, wir bauen die Schnittstellen drumherum. Zwei Welten, getrennte Verantwortung, gemeinsamer Wert.
67 %
Scheiterrate bei kompletten AS/400 Migrationen
Branchen-Realität: 67 Prozent der Unternehmen scheitern bei der Integration von KI, weil sie versuchen, Legacy-Systeme zu umgehen statt sie einzubinden. Ihre IBM i läuft seit 20 Jahren fehlerfrei und macht den Umsatz. Warum sollten Sie dieses Asset wegwerfen? Mit dem Integration-Ansatz steht die erste API in 4 bis 8 Wochen, das System bleibt produktiv, die Migrations-Risiko-Diskussion wird obsolet.
Der Unterschied in Zahlen
Faktor
Komplett-Ablösung (Risiko)
API-Integration (Xanevo)
Time-to-Value
2 bis 5 Jahre
4 bis 8 Wochen
Risiko
67 Prozent Scheiterrate
Minimal, System läuft weiter
Kosten
7-stellig (Consulting und Lizenz)
5-stellig (Implementierung)
Business Logic
Neu gebaut, ungetestet
Bewährter RPG-Code bleibt
Betriebsstillstand
Cut-Over-Wochenenden, hohes Risiko
Kein Stillstand, parallel betrieben
Drei Fragen, die IBM i Verantwortliche stellen
Nein. Ihre RPG-Programmierer pflegen weiter den Core, wo sie ihre Stärken haben. Wir bauen die Schnittstellen mit unseren eigenen Skills (Python, REST, SQL). Zwei Welten, klare Verantwortungstrennung. Das ist gerade in Zeiten knapper RPG-Ressourcen ein Vorteil: Sie binden Ihr internes Wissen nicht in Neu-Entwicklung, sondern halten es auf der Logik-Ebene.
Ja. Wir nutzen ausschließlich die nativen IBM i Berechtigungsobjekte (Object Authorities, Authorization Lists). Der Integration User bekommt nur die Rechte, die für die definierten Use Cases nötig sind. Keine globalen Privilegien, keine Änderungen an bestehenden Profilen. Jede Aktion landet im IBM i Journal mit User-ID und Zeitstempel.
Ja. Das Prinzip des Wrappers ist identisch: Bestehende Business-Logik bleibt unangetastet, eine REST-Schicht macht sie nach außen sprechfähig. Wir haben Erfahrung mit COBOL auf Mainframe-Systemen (z/OS) und mit hybriden Landschaften, in denen IBM i, Mainframe und moderne Cloud-Anwendungen koexistieren müssen.
Verwandte Deep Dives
SAP Integration
Side-by-Side-Anbindung an SAP R/3 und S/4HANA über BAPI, IDoc und OData. Andere Welt, gleiches Prinzip: Core unangetastet, Schnittstellen modern.
Microsoft Dynamics
Custom Connectors für NAV, Business Central, AX und Dynamics 365 dort, wo Power Automate aufhört.
// XANEVO | IBM i / AS/400
Prüfen wir Ihre Integrations-Optionen.
Welche IBM i Version ist im Einsatz, welche RPG- oder COBOL-Programme sind kritisch, wo gibt es noch Source Code? Wir prüfen Ihre Schnittstellen-Optionen, identifizieren die schnellsten Wege zur API-Fähigkeit und liefern eine konkrete Empfehlung. Ohne Verkaufsdruck, ohne Migrations-Agenda.