RPG-Modernisierung: Wege raus aus der IBM-i-Abhängigkeit
Eine RPG-Modernisierung steht in vielen Unternehmen seit Jahren auf der Liste. Ganz oben. Und trotzdem passiert nichts.
Der Grund ist meistens derselbe. Das System läuft. Es läuft sogar außergewöhnlich stabil. Die Auftragsabwicklung funktioniert seit 1994 ohne nennenswerte Ausfälle. Warum also etwas anfassen, das keinen Ärger macht?
Weil das Problem nicht die Software ist. Das Problem sind die Menschen, die sie verstehen.
RPG steht für "Report Program Generator". Die Sprache stammt aus den späten 1950er Jahren und läuft heute fast ausschließlich auf IBM i, dem Betriebssystem der früheren AS/400. Wer RPG beherrscht, ist im Schnitt über 55 Jahre alt. Nachwuchs gibt es kaum. Genau das macht die Abhängigkeit gefährlich.
Dieser Artikel erklärt, welche Risiken konkret entstehen und welche drei Wege aus der Situation herausführen.
Warum RPG-Modernisierung jetzt auf die Agenda gehört
Zuerst eine Klarstellung. RPG ist keine schlechte Sprache, und IBM i ist keine schlechte Plattform. Im Gegenteil.
IBM i ist eines der zuverlässigsten Betriebssysteme, die je gebaut wurden. Integrierte Datenbank, integrierte Sicherheit, Rückwärtskompatibilität über Jahrzehnte. Programme aus den 1990er Jahren laufen auf aktueller Hardware ohne Anpassung. Das schafft sonst kaum jemand.
IBM entwickelt die Plattform aktiv weiter. IBM i 7.6 erschien 2025, moderne RPG-Varianten unterstützen freie Syntax, und die Roadmap reicht weit in die 2030er Jahre. Die Plattform stirbt also nicht.
Das Risiko liegt woanders.
Das Personalproblem ist das eigentliche Risiko
Fragen Sie sich einmal ehrlich: Wie viele Menschen in Ihrem Unternehmen können den RPG-Code ändern? Bei den meisten Mittelständlern lautet die Antwort: einer. Manchmal zwei.
Wenn diese Person in Rente geht, kündigt oder länger ausfällt, steht die Weiterentwicklung still. Nicht die Software fällt aus. Die Fähigkeit, sie anzupassen, fällt aus.
Das ist eine klassische Form von technischen Schulden. Sie zeigt sich nicht im Betrieb, sondern erst bei der nächsten Änderung.
Fehlende Schnittstellen bremsen das Geschäft
Alte RPG-Anwendungen arbeiten oft mit 5250-Bildschirmmasken, den grünen Terminaloberflächen. Diese Programme mischen Anzeige, Geschäftslogik und Datenzugriff in derselben Quelldatei.
Für ein Kundenportal, eine mobile App oder eine Anbindung an einen Onlineshop brauchen Sie aber eine API, also eine definierte Schnittstelle zwischen Systemen. Aus verwobenem RPG-Code lässt sich so etwas nicht einfach herausziehen.
Die Folge kennen viele. Jede Digitalisierungsidee scheitert an derselben Stelle.
Dokumentation existiert selten
Über dreißig Jahre wächst Code. Anforderungen ändern sich, Entwickler wechseln, Kommentare veralten. Was tatsächlich passiert, weiß am Ende nur das Programm selbst.
Fehlendes Wissen macht jede Änderung teuer und riskant. Das gilt für Legacy Software generell, bei RPG-Systemen aber besonders stark.
Was passiert, wenn Sie nichts tun
Nichtstun ist eine Entscheidung. Sie hat Folgen, nur zeitversetzt.
Änderungen werden immer teurer. Externe RPG-Entwickler sind rar und entsprechend hochpreisig. Die Tagessätze steigen seit Jahren.
Das Geschäft wartet auf die IT. Neue Vertriebswege, EDI-Anbindungen, Self-Service-Portale: alles verschiebt sich, weil das Kernsystem nicht mitspielt.
Compliance wird zum Thema. Neue gesetzliche Anforderungen, etwa zur E-Rechnung oder zur Datenverarbeitung, müssen im System abgebildet werden. Ohne Entwickler geht das nicht.
Der Notfall entscheidet für Sie. Wenn der letzte RPG-Kenner ausfällt, wird aus einem geplanten Projekt eine Hauruck-Aktion. Diese Variante ist immer die teuerste.
Drei Wege aus der IBM-i-Abhängigkeit
Es gibt nicht den einen richtigen Weg. Es gibt drei, und sie unterscheiden sich stark in Aufwand, Kosten und Risiko.
Weg 1: Modernisierung auf der Plattform
Sie bleiben auf IBM i, modernisieren aber den Code und die Oberfläche.
Konkret bedeutet das mehrere Schritte. Alter RPG-Code in fester Spaltensyntax wird nach Free-Form-RPG überführt, einer modernen Schreibweise, die sich wie eine gewöhnliche Programmiersprache liest. Geschäftslogik wird aus den Bildschirmprogrammen herausgelöst und in Serviceprogramme gepackt. Diese Services werden per REST-API nach außen geöffnet. Die grünen Masken ersetzt eine Weboberfläche.
Vorteile: Sie behalten die stabile Plattform, die Daten bleiben, wo sie sind, und Sie können in kleinen Schritten vorgehen. Das Risiko ist von allen drei Wegen am geringsten.
Nachteile: Das Personalproblem verschwindet nicht vollständig. Sie brauchen weiterhin RPG-Kenntnisse, wenn auch weniger.
Passt, wenn: die Geschäftslogik gut ist, das System zentral bleibt und vor allem Schnittstellen und Oberfläche fehlen.
Weg 2: Migration nach Java
Der RPG-Code wird in eine verbreitete Sprache überführt, meist Java, seltener C# oder Kotlin.
Es gibt Werkzeuge, die RPG automatisiert nach Java übersetzen. Seien Sie hier vorsichtig. Automatisch erzeugter Java-Code aus RPG sieht aus wie RPG in Java-Schreibweise. Er ist lauffähig, aber schwer zu pflegen. Sie tauschen ein Wartungsproblem gegen ein anderes.
Sinnvoller ist die fachliche Neuimplementierung der Kernprozesse, unterstützt durch automatisierte Analyse des Altsystems. Das dauert länger, liefert aber Code, den jeder Java-Entwickler lesen kann.
Vorteile: Der Arbeitsmarkt öffnet sich. Java-Entwickler finden Sie überall. Moderne Werkzeuge, Tests und Bibliotheken stehen zur Verfügung.
Nachteile: Hoher Aufwand, hohe Kosten, echtes Projektrisiko. Die IBM-i-Datenbank Db2 for i lässt sich mitnehmen oder ablösen, beides will geplant sein.
Passt, wenn: das Unternehmen ohnehin Java-Kompetenz aufbaut oder die IBM-i-Lizenzkosten drücken.
Weg 3: Schrittweise Ablösung
Sie ersetzen das System nicht auf einen Schlag, sondern Funktion für Funktion. Das Vorgehen ist als Strangler Fig Pattern bekannt.
Vor das Altsystem wird eine Fassade gesetzt, die Anfragen verteilt. Neue Funktionen entstehen außerhalb, etwa als Webanwendung oder Cloud-Service. Alte Funktionen wandern nach und nach hinüber. Das RPG-System schrumpft, bis es abgeschaltet werden kann.
Wie das konkret abläuft, beschreibt unser Artikel zum Strangler Fig Pattern in der Praxis.
Vorteile: Kein Big Bang. Jeder Schritt liefert Nutzen. Sie können jederzeit anhalten oder das Tempo ändern.
Nachteile: Über längere Zeit laufen zwei Systeme parallel. Das kostet Geld und erfordert Disziplin bei der Datenhaltung.
Passt, wenn: das System groß ist, ein Stillstand nicht infrage kommt und das Budget über mehrere Jahre verteilt werden soll.
Wie Sie den richtigen Weg finden
Bevor Sie sich entscheiden, brauchen Sie Fakten. Drei Fragen führen weiter.
Wie viel Code liegt tatsächlich vor? Zählen Sie Programme, Serviceprogramme und Dateien. Prüfen Sie, welche davon in den letzten drei Jahren überhaupt aufgerufen wurden. Erfahrungsgemäß ist ein erheblicher Teil tot.
Wo sitzt die Geschäftslogik? Steckt sie in den Bildschirmprogrammen oder bereits in getrennten Modulen? Das entscheidet über den Aufwand von Weg 1.
Was soll das System in fünf Jahren können? Wenn die Antwort "im Wesentlichen dasselbe" lautet, ist eine Modernisierung auf der Plattform meist die wirtschaftlichste Wahl. Wenn neue Kanäle, Standorte oder Produkte anstehen, lohnt der größere Umbau.
Eine strukturierte Bestandsaufnahme dauert wenige Wochen und kostet einen Bruchteil des Projekts. Wie so eine Analyse abläuft, zeigt unser Beitrag zur strukturierten Ablösung veralteter Software. Warum IBM-i-Systeme dabei einen eigenen Blick verdienen, lesen Sie im Artikel zur AS/400-Wartung.
Fazit
RPG-Modernisierung ist kein Aufräumen aus Prinzip. Es geht darum, die Handlungsfähigkeit zurückzugewinnen.
Die Plattform IBM i ist stabil und hat Zukunft. Ihr Zugriff auf das eigene System ist es oft nicht. Wer weiterhin von einer einzigen Person abhängt, trägt ein Risiko, das mit jedem Jahr wächst.
Alle drei Wege funktionieren. Entscheidend ist, dass Sie einen davon bewusst wählen, statt zu warten, bis der Notfall die Wahl trifft.
Sie wissen nicht, wo Ihr System steht? Wir schauen es uns an und sagen Ihnen ehrlich, welcher Weg passt. Sprechen Sie uns an. Das Erstgespräch ist kostenlos.
