Der entscheidende Unterschied zu vielen anderen Sprachen ist die enge Verzahnung von Sprache, Betriebssystem und Datenbank. RPG ist keine plattformneutrale Allzwecksprache, sondern lebt im Verbund mit IBM i und der integrierten Datenbank DB2 for i. Diese Einheit aus Hardware, Betriebssystem, Datenbank und Sprache ist der Grund, warum RPG-Systeme als außerordentlich stabil, integriert und wartungsarm gelten – und zugleich der Grund, warum sie an eine bestimmte Plattform gebunden sind. Wer RPG verstehen will, muss die Plattform mitdenken.
Drei Eigenschaften prägen RPG bis heute:
Die Geschichte von RPG ist die Geschichte einer Plattform. In den 1970er- und 1980er-Jahren entwickelte IBM mit dem System/38 und später der AS/400 eine Rechnerfamilie, die konsequent auf integrierte Geschäftsverarbeitung ausgelegt war: Betriebssystem und relationale Datenbank waren von Anfang an eng verbunden, und RPG war die natürliche Anwendungssprache dieser Welt. Die AS/400 wurde in den 1990er-Jahren zu einem der erfolgreichsten Mittelstands-Serversysteme überhaupt und ist in unzähligen Unternehmen bis heute im Einsatz – heute unter dem Namen IBM i auf moderner Power-Hardware.
Dieser Namenswechsel ist für die Praxis wichtig: System/38, AS/400, iSeries, System i und schließlich IBM i bezeichnen im Kern eine durchgängige, sich weiterentwickelnde Plattformlinie. Viele Anwender sprechen umgangssprachlich weiter von der AS/400, meinen damit aber ein aktuelles IBM-i-System. Für die Einordnung von RPG bedeutet das: Die Sprache ist nicht museal, sondern läuft auf aktueller, gepflegter Hardware und Software – nur eben in einem proprietären, in sich geschlossenen Ökosystem.
Es gehört zu den häufigsten Missverständnissen, RPG pauschal als veraltete Alttechnologie abzustempeln. Richtig ist, dass die Sprache aus einer anderen Zeit stammt und ihr Ökosystem nicht die Breite moderner Allzwecksprachen hat. Falsch ist die Schlussfolgerung, RPG-Systeme seien automatisch ablösereif. In vielen Unternehmen bilden sie ein hochgradig eingespieltes, zuverlässiges Rückgrat, das jahrzehntelanges Prozesswissen abbildet. Eine überstürzte Ablösung vernichtet oft mehr Wert, als sie schafft.
Zugleich ist ehrlich einzuordnen, dass die Fachkräftefrage und die begrenzte Verfügbarkeit junger RPG-Entwickler ein reales strategisches Thema sind, auf das wir in diesem Artikel ausführlich eingehen. Die realistische Haltung liegt zwischen den Extremen: RPG ist weder ein Relikt, das man schnellstmöglich entsorgen muss, noch eine Sprache, in die man ohne Modernisierungsplan blind weiterinvestieren sollte. Die Kunst liegt in einer nüchternen Bestandsaufnahme.
Das prägendste historische Merkmal von RPG ist der sogenannte Programm-Zyklus – von vielen schlicht „der Zyklus“ genannt. In klassischem RPG musste ein Entwickler die Hauptschleife eines Programms gar nicht selbst schreiben: Die Sprache brachte einen fest eingebauten Ablauf mit, der automatisch die Eingabedatei satzweise las, die definierte Verarbeitung anwandte und Ausgaben erzeugte, bis die Datei zu Ende war. Für die typische Aufgabe – eine große Datei durchlaufen und für jeden Satz etwas tun – war das außerordentlich effizient und mit sehr wenig Code zu erreichen.
Die Kehrseite: Dieser implizite Zyklus ist für Außenstehende schwer nachzuvollziehen, weil ein wesentlicher Teil der Programmlogik nicht sichtbar im Code steht, sondern in der Sprache verankert ist. Wer heutigen prozeduralen Code gewohnt ist, empfindet zyklusbasiertes RPG oft als rätselhaft. Genau deshalb hat sich die moderne RPG-Entwicklung vom Zyklus gelöst: Man schreibt die Steuerung explizit selbst, in klar strukturierten Prozeduren – gut lesbar und für jeden Entwickler nachvollziehbar. Beide Welten koexistieren in vielen Unternehmen, was den Bestandscode heterogen macht.
Der vielleicht wichtigste konzeptionelle Sprung war die Einführung der Integrated Language Environment (ILE) mit RPG IV. ILE erlaubt es, Programme aus einzelnen Modulen und Prozeduren zusammenzusetzen, wiederverwendbare Dienstprogramme zu bilden und Funktionalität sauber zu kapseln. Damit erhielt RPG genau jene modulare Struktur, die moderne Softwareentwicklung ausmacht: kleine, testbare Bausteine statt riesiger monolithischer Programme.
Für Unternehmen ist dieser Punkt strategisch bedeutsam. Wer seinen RPG-Bestand konsequent in Richtung ILE und Prozeduren modernisiert, macht ihn nicht nur besser wartbar, sondern auch anschlussfähig: Modular gebaute RPG-Prozeduren lassen sich als Dienste kapseln und von außen – etwa aus Web-Oberflächen oder anderen Systemen – aufrufen. Modularisierung ist damit die Grundlage fast jeder sinnvollen Modernisierungsstrategie, auf die wir später zurückkommen.
Historisches RPG war spaltengebunden: Jede Codezeile hatte feste Positionen, an denen bestimmte Angaben stehen mussten – in der einen Spalte der Zeilentyp, in der nächsten ein Faktor, dann eine Operation, dann ein Ergebnisfeld. Diese starre Struktur stammt aus der Ära der Lochkarten, auf denen jede Spalte eine feste Bedeutung hatte. Für geübte RPG-Entwickler war das effizient, für alle anderen wirkt solcher Code kryptisch und ist ohne Kenntnis der Spaltenbelegung kaum zu lesen. Genau dieses Bild prägt bis heute den Ruf von RPG als schwer zugänglicher Sprache.
Der Wandel zum Free-Format ist die vielleicht wichtigste Entwicklung der jüngeren RPG-Geschichte. Im freien Format entfällt die Bindung an feste Spalten: Code wird ähnlich geschrieben wie in anderen modernen Sprachen, mit frei wählbarer Einrückung, sprechenden Anweisungen und klar erkennbarer Struktur. Aus schwer entzifferbaren Spaltenkolonnen werden gut lesbare Programme, die auch ein Entwickler ohne jahrzehntelange RPG-Erfahrung nachvollziehen kann.
Für die Praxis bedeutet das eine doppelte Realität. Neue RPG-Entwicklung erfolgt heute weitgehend im freien Format – es ist der empfohlene Stil und ein wichtiges Argument, um jüngere Entwickler für die Sprache zu gewinnen. Zugleich existiert in den meisten Unternehmen sehr viel Bestandscode noch im alten Fixed-Format. Beide Formate lassen sich mischen, und ein zentraler Teil vieler Modernisierungsprojekte besteht darin, kritische Programmteile behutsam ins freie Format zu überführen, um sie wieder wartbar zu machen. Diese Übersetzung sollte planvoll und getestet erfolgen, nicht als hektische Massenkonvertierung.
Moderne RPG-Entwicklung hat mit dem Bild aus den 1980er-Jahren wenig gemein. Zeitgemäße Programme nutzen freies Format, gliedern Logik in Prozeduren, greifen über eingebettetes SQL auf die Datenbank zu und lassen sich in einer grafischen Entwicklungsumgebung komfortabel bearbeiten. Wer heute RPG lernt, lernt eine strukturierte, prozedurale Sprache mit tiefer Datenbank-Anbindung – nicht den zyklusbasierten Report-Generator der Anfangszeit.
Wichtig für Unternehmen ist die Erkenntnis, dass Lesbarkeit und Wartbarkeit von RPG heute eine bewusste Entscheidung sind. Wer weiterhin im alten Stil programmiert, zementiert die Zugangshürden; wer konsequent auf freies Format, Prozeduren und SQL setzt, macht seinen Code auch für eine neue Generation zugänglich. Die Sprache selbst gibt beides her – die Entscheidung, wie modern der eigene RPG-Code aussieht, treffen die Verantwortlichen im Unternehmen.
Das Fundament ist das Betriebssystem IBM i, das auf IBMs Power-Servern läuft und die integrierte relationale Datenbank DB2 for i fest eingebaut mitbringt. Diese Integration ist das prägende Merkmal der Plattform: Datenbank, Sicherheit, Job-Steuerung und Anwendungslogik sind Teil eines konsistenten Ganzen, nicht lose gekoppelte Fremdprodukte. Daraus resultiert der Ruf der Plattform als außerordentlich stabil, sicher und wartungsarm – viele IBM-i-Systeme laufen mit minimalem Administrationsaufwand über Jahre zuverlässig.
Für RPG ist diese Einheit ein doppelter Faktor. Einerseits erklärt sie die enorme Effizienz: Ein RPG-Programm greift ohne Umwege direkt auf die integrierte Datenbank zu, was Massenverarbeitung sehr schnell macht. Andererseits bedeutet sie eine feste Bindung an eine proprietäre, kostenpflichtige Plattform eines einzelnen Herstellers. Diese Abhängigkeit ist ein bewusst abzuwägender strategischer Punkt, den wir in den Kapiteln zu Mittelstand und Zukunft aufgreifen.
Historisch griff RPG über die satzweise Navigation auf Dateien zu – Satz für Satz lesen, aktualisieren, schreiben. Diese Zugriffsart ist bis heute in viel Bestandscode präsent und für bestimmte Verarbeitungsmuster sehr performant. Parallel dazu hat sich jedoch SQL auch in der IBM-i-Welt als zentraler Datenbankzugang etabliert. Modernes RPG bettet SQL-Anweisungen direkt in den Programmcode ein und nutzt so die volle Ausdrucksstärke einer mengenorientierten Abfragesprache.
Diese Entwicklung ist für die Modernisierung zentral: SQL macht Datenzugriffe lesbarer, flexibler und für Entwickler aus anderen Welten sofort verständlich. Zudem öffnet es die integrierte Datenbank für Standardwerkzeuge und Auswertungen. Unternehmen, die ihren RPG-Bestand zukunftsfähig halten wollen, setzen beim Datenzugriff daher zunehmend auf eingebettetes SQL statt ausschließlich auf die klassische satzweise Navigation – ohne dass alter, funktionierender Code deshalb sofort umgebaut werden müsste.
Das Bild der IBM-i-Welt ist für viele der sogenannte „Green Screen“: die zeichenbasierte 5250-Terminal-Oberfläche, über die Anwendungen bedient und lange Zeit auch entwickelt wurden. Diese textbasierten Masken sind extrem schnell, tastaturzentriert und bei erfahrenen Anwendern beliebt, wirken auf neue Nutzer aber sperrig und altmodisch. Sie prägen bis heute den Ruf der Plattform.
Die moderne Entwicklung hat sich davon gelöst. Mit dem Rational Developer for i (RDi) steht eine grafische, komfortable Entwicklungsumgebung zur Verfügung, die zeitgemäßes Arbeiten mit Syntaxhervorhebung, Navigation und modernen Werkzeugen erlaubt – vergleichbar mit den Entwicklungsumgebungen anderer Sprachwelten. Dazu kommen weitere Werkzeuge für Datenbankverwaltung, Automatisierung und Betrieb. Auch hier gilt: Wer die modernen Werkzeuge nutzt, entwickelt RPG heute unter deutlich besseren Bedingungen, als es das Klischee vom Green Screen vermuten lässt.
Wenn ein einzelnes Feld die Bedeutung von RPG erklärt, dann ist es die zuverlässige Verarbeitung großer Mengen betriebswirtschaftlicher Datensätze. Aufträge erfassen, Bestände fortschreiben, Rechnungen erzeugen, nächtliche Abrechnungsläufe fahren – diese Aufgaben verlangen Präzision, Stabilität und hohen Durchsatz, und genau dafür wurde RPG optimiert. In Kombination mit der integrierten Datenbank und der stabilen Plattform ergibt sich ein System, das Tag für Tag riesige Transaktionsmengen ohne großes Aufheben bewältigt.
Dieser Nutzen ist selten sichtbar und selten glamourös – aber er ist geschäftskritisch. In vielen Unternehmen würde ein Ausfall des RPG-Kernsystems den Betrieb unmittelbar zum Stillstand bringen. Genau diese stille Verlässlichkeit ist der Grund, warum RPG-Systeme so lange bestehen: Sie tun ihre Arbeit, und sie tun sie gut. Wer diesen Wert nicht anerkennt, unterschätzt die Substanz, die in diesen Systemen steckt.
Ein Aspekt, der bei RPG-Systemen häufig übersehen wird, ist das über Jahrzehnte in den Code eingeflossene Fachwissen. Jede Sonderregel, jede Ausnahme, jede branchenspezifische Besonderheit ist irgendwann von jemandem verstanden und in ein Programm gegossen worden. Dieses angesammelte Prozesswissen ist ein realer, schwer zu beziffernder Vermögenswert – und zugleich das größte Risiko bei einer Ablösung, weil es nirgendwo sonst vollständig dokumentiert ist.
Für Unternehmen bedeutet das: Ein RPG-Kernsystem ist nicht einfach Technik, sondern die codifizierte Betriebslogik des Unternehmens. Bei jeder Überlegung zu Modernisierung oder Ablösung muss dieses Wissen ernst genommen werden. Wer es unterschätzt, riskiert bei einer Neuentwicklung, mühsam erarbeitete Feinheiten zu verlieren und Fehler zu wiederholen, die vor Jahrzehnten bereits gelöst wurden.
Die Modernisierung von RPG verläuft auf mehreren Ebenen gleichzeitig. Auf der Sprachebene steht der Übergang zum freien Format und zu prozeduralem, modularem Code. Auf der Datenebene tritt eingebettetes SQL neben die klassische satzweise Navigation. Auf der Oberflächenebene lösen sich moderne Anwendungen vom zeichenbasierten Green Screen und präsentieren sich über Web-Oberflächen. Und auf der Integrationsebene öffnen sich RPG-Systeme über Schnittstellen für den Datenaustausch mit der übrigen IT-Welt.
Der sichtbarste Modernisierungsschritt betrifft die Benutzeroberfläche. Klassische RPG-Anwendungen werden über zeichenbasierte 5250-Masken bedient – die vielzitierte „grüne Maske“ –, schnell und effizient für geübte Anwender, aber sperrig für neue Mitarbeiter und ungeeignet für Kunden oder Partner, die von außen zugreifen sollen. Ein zentrales Ziel vieler Projekte ist es daher, diese Oberflächen durch zeitgemäße, browserbasierte Web-Oberflächen zu ersetzen, ohne die dahinterliegende, bewährte Geschäftslogik neu schreiben zu müssen.
Der entscheidende Gedanke dabei ist die Trennung von Oberfläche und Logik. Wenn die kaufmännische Verarbeitung sauber in RPG-Prozeduren gekapselt ist, kann eine moderne Web-Oberfläche diese Logik aufrufen, ohne dass am stabilen Kern etwas geändert werden muss. Das reduziert Risiko und Aufwand erheblich: Man modernisiert das, was der Anwender sieht, und bewahrt das, was seit Jahren zuverlässig funktioniert. Genau diese Strategie steht im Zentrum vieler erfolgreicher IBM-i-Modernisierungen.
Noch weiter reicht die Öffnung über Schnittstellen und Web-Services. Moderne Systemlandschaften bestehen aus vielen Komponenten, die miteinander sprechen müssen: Webshops, Kundenportale, mobile Anwendungen, Cloud-Dienste. Ein RPG-Kernsystem, das seine Funktionen über definierte Schnittstellen (APIs) bereitstellt, wird vom isolierten Silo zum integrierten Herzstück einer modernen Architektur. Bestellungen aus dem Webshop landen direkt im Kernsystem, Bestände werden in Echtzeit zurückgemeldet, und andere Systeme greifen kontrolliert auf die zentrale Datenbasis zu.
Diese Integrationsfähigkeit ist für den Mittelstand strategisch bedeutsam, weil sie den Investitionsschutz mit Zukunftsfähigkeit verbindet. Das bewährte RPG-System bleibt der verlässliche Kern, wird aber anschlussfähig für neue Geschäftsmodelle und digitale Kanäle. Voraussetzung ist auch hier eine saubere Modularisierung: Nur klar gekapselte Logik lässt sich sinnvoll als Schnittstelle nach außen anbieten. Die Modernisierung der Sprache und die Öffnung des Systems greifen damit unmittelbar ineinander.
RPG und COBOL werden häufig in einem Atemzug genannt, weil beide klassische kaufmännische Sprachen mit langer Geschichte sind und beide große Bestände geschäftskritischer Anwendungen tragen. Der entscheidende Unterschied liegt in der Plattformwelt: COBOL ist eng mit der Großrechner-Welt (Mainframe) und deren Ökosystem verbunden, während RPG das Kind der IBM-i-Plattform ist. Beide teilen den Fokus auf zuverlässige Massenverarbeitung, leben aber in unterschiedlichen technischen Umgebungen mit eigenen Werkzeugen, Datenbanken und Kulturen.
Für Unternehmen ist die Unterscheidung praktisch relevant, weil sich Fachkräfte, Werkzeuge und Modernisierungswege unterscheiden. Ein COBOL-Entwickler ist nicht automatisch ein RPG-Entwickler und umgekehrt. Wer eine Sprache im Haus hat, sollte deren spezifisches Ökosystem verstehen, statt Erkenntnisse pauschal zu übertragen. Gemeinsam ist beiden Welten allerdings die zentrale strategische Herausforderung: eine alternde Entwicklergeneration und die Frage nach dem Nachwuchs.
Im Verhältnis zu Java und SQL steht RPG weniger in Konkurrenz als in einer sinnvollen Arbeitsteilung. SQL ist heute in der IBM-i-Welt der etablierte Weg des Datenzugriffs und wird direkt in RPG eingebettet – RPG liefert die Ablauf- und Geschäftslogik, SQL den flexiblen, mengenorientierten Zugriff auf die Datenbank. Diese Kombination ist der moderne Standard und verbindet die Stärken beider Sprachen, statt sie gegeneinander auszuspielen.
Java wiederum kommt dort ins Spiel, wo plattformneutrale Komponenten, moderne Web-Oberflächen oder die Integration mit anderen Systemen gefragt sind. In vielen modernisierten IBM-i-Landschaften übernimmt RPG weiterhin die stabile kaufmännische Kernverarbeitung, während Java oder andere moderne Sprachen die Oberflächen, Schnittstellen und Integrationsschichten bilden. Diese hybride Architektur – bewährter RPG-Kern, moderne Peripherie – ist in der Praxis häufig der wirtschaftlich sinnvollste Weg. Die Sprachen ergänzen sich, jede in ihrer Stärke.
Die IBM-i-Plattform hat gerade im gehobenen Mittelstand eine große, stille Verbreitung. Zahlreiche Handels-, Fertigungs-, Logistik- und Versicherungsunternehmen im deutschsprachigen Raum betreiben ihre operativen Kernsysteme seit Jahrzehnten auf dieser Plattform – häufig als Herzstück, ohne das kein Auftrag erfasst und keine Rechnung geschrieben würde. Konkrete Verbreitungszahlen schwanken je nach Quelle und Branche; unstrittig ist, dass RPG im Mittelstand weit mehr als eine Rand-Technologie ist.
Bemerkenswert ist die Diskrepanz zwischen Wahrnehmung und Wirklichkeit. Während in der öffentlichen Debatte moderne Sprachen dominieren, arbeiten im Hintergrund vieler erfolgreicher Mittelständler weiterhin RPG-Systeme zuverlässig ihre Transaktionen ab. Diese Unsichtbarkeit ist zugleich ein Risiko: Weil die Systeme so klaglos funktionieren, gerät leicht in Vergessenheit, wie kritisch sie sind – und wie abhängig das Unternehmen von wenigen Menschen ist, die sie noch verstehen.
Das mit Abstand wichtigste strategische Thema rund um RPG ist die Verfügbarkeit von Fachkräften. Viele erfahrene RPG-Entwickler sind seit Jahrzehnten im Beruf und nähern sich dem Ruhestand, während nur wenige junge Entwickler nachrücken – RPG wird an Hochschulen kaum gelehrt und hat außerhalb der IBM-i-Welt geringe Sichtbarkeit. Daraus entsteht für viele Unternehmen ein reales Risiko: Das Wissen über geschäftskritische Systeme hängt an einer schrumpfenden Zahl von Personen.
Dieses Risiko lässt sich nicht wegdiskutieren, aber es lässt sich gestalten. Mögliche Wege sind der gezielte Wissenstransfer von erfahrenen auf jüngere Mitarbeiter, die Modernisierung des Codes hin zu freiem Format, das für Nachwuchskräfte zugänglicher ist, die Zusammenarbeit mit spezialisierten Dienstleistern sowie eine bewusste Entscheidung, welche Systeme langfristig auf RPG bleiben und welche schrittweise abgelöst werden. Entscheidend ist, das Thema aktiv anzugehen, bevor der Ruhestand eines Schlüsselmitarbeiters es akut werden lässt.
Eng mit der Fachkräftefrage verbunden ist die Sicherung des in den Systemen steckenden Wissens. In vielen gewachsenen RPG-Landschaften ist die Dokumentation lückenhaft, und entscheidende Zusammenhänge existieren nur in den Köpfen einzelner. Wenn diese Personen das Unternehmen verlassen, droht der Verlust von Wissen, das für Betrieb und Weiterentwicklung unverzichtbar ist. Eine strukturierte Bestandsaufnahme – welche Programme existieren, was sie tun, wie sie zusammenhängen – ist daher oft der erste sinnvolle Schritt.
Die Gegenmaßnahme ist pragmatische Governance: den Bestand inventarisieren, kritische Programme dokumentieren, Verantwortlichkeiten klären und den Code in einen wartbaren Zustand überführen. Gerade im Mittelstand, wo Wissen häufig an einzelnen Personen hängt, ist diese Disziplin die beste Versicherung gegen teure Abhängigkeiten. Sie schafft zugleich die Grundlage für jede fundierte Entscheidung darüber, ob und wie modernisiert oder abgelöst werden soll.
Im Kern stehen Unternehmen vor drei Grundoptionen. Der erste Weg ist Bewahren und behutsam öffnen: Das RPG-Kernsystem bleibt, wird aber modernisiert – freies Format, SQL, Web-Oberflächen und Schnittstellen. Dieser Weg schont die Investition, sichert das Prozesswissen und ist meist der risikoärmste. Der zweite Weg ist die schrittweise Ablösung: Einzelne Funktionsbereiche werden nach und nach durch moderne Systeme ersetzt, während der Kern zunächst weiterläuft. Der dritte Weg ist die vollständige Ablösung durch eine Standardsoftware oder Neuentwicklung – der größte Umbau mit dem höchsten Risiko, aber auch der klarste Schnitt.
Welcher Weg der richtige ist, hängt von vielen Faktoren ab: Zustand und Kritikalität des Bestands, verfügbarem Wissen, Fachkräftesituation, Budget und strategischer Ausrichtung. In unserer Erfahrung wird die Komplettablösung häufig überschätzt und der Weg des behutsamen Modernisierens unterschätzt. Ein funktionierendes, gepflegtes RPG-System einfach wegzuwerfen, weil es alt ist, vernichtet oft Werte, ohne einen entsprechenden Nutzen zu schaffen. Umgekehrt ist blindes Weiterlaufenlassen ohne Modernisierung ein schleichendes Risiko.
Die Verlockung eines kompletten Neubaus ist groß: ein sauberes, modernes System ohne die Altlasten von Jahrzehnten. In der Praxis scheitern solche Großprojekte jedoch häufig oder werden deutlich teurer und langwieriger als geplant – vor allem, weil das in den Altsystemen steckende Prozesswissen unterschätzt wird. Jede Sonderregel, die im RPG-Code abgebildet ist, muss im neuen System korrekt nachgebildet werden, und genau hier liegen die versteckten Kosten und Risiken.
Deshalb plädieren wir in den meisten Fällen für einen evolutionären statt revolutionären Ansatz: den bewährten Kern erhalten, ihn modernisieren und öffnen, und Ablösungen – wenn überhaupt – schrittweise und beherrschbar vollziehen. Dieser Weg hält das Unternehmen jederzeit handlungsfähig, verteilt Risiko und Aufwand über die Zeit und bewahrt das wertvolle Prozesswissen. Am Ende steht oft eine hybride Landschaft mit stabilem RPG-Kern und moderner Peripherie – kein Kompromiss, sondern eine bewusste, wirtschaftlich sinnvolle Architektur.
IBM entwickelt die Plattform IBM i und die Sprache RPG weiter und bekennt sich zu langfristiger Unterstützung und Abwärtskompatibilität. Das gibt Unternehmen Planungssicherheit: RPG-Systeme werden nicht über Nacht funktionsunfähig, und Investitionen in ihre Modernisierung sind nicht vergeblich. Der konkrete Umfang und die Roadmap der Herstellerunterstützung sollten jedoch stets am aktuellen Stand geprüft werden, da sich Produktstrategien über die Zeit ändern können.
Zugleich bleibt die strukturelle Herausforderung bestehen: die begrenzte Fachkräftebasis und die proprietäre Plattformbindung. Eine seriöse Zukunftsplanung wiegt daher den hohen Wert und die Stabilität des Bestands gegen diese langfristigen Risiken ab. Für die meisten Unternehmen mit gesunder IBM-i-Landschaft lautet die realistische Antwort nicht Ausstieg um jeden Preis, sondern bewusste Pflege, Modernisierung und ein klarer, dokumentierter Plan für den Fall, dass sich die Rahmenbedingungen ändern.
