RPG Modernization Approaches

Part 2 established that the urgent first move is capturing what the system knows before the experts retire. For the workloads that warrant modernization, the next question is the one most charged with confusion and bad advice: what do you actually do with the RPG? This part lays out the real options — and there are more of them than the usual “keep it or rewrite it in Java” binary suggests. Getting the choice right starts with understanding what kind of RPG you are actually looking at.

The layers of RPG you will find

“RPG” is not one language. It is a family of dialects layered over forty years, and most AS/400 estates contain several at once. Naming them prevents a lot of confused planning:

• RPG II — the oldest dialect still in the wild, built around a fixed program cycle and rigid column positions inherited from punch cards. Dense and alien to modern eyes.
• RPG III / RPG/400 — added structured operations and subroutines; still fixed-format and tied to the program cycle, but more approachable than RPG II.
• RPG IV (ILE RPG) — introduced in 1994, brought the Integrated Language Environment: modular procedures, prototyped calls, service programs, and far better data handling. This is the foundation modern RPG builds on.
• Free-format RPG — IBM added free-format calculation specs in 2001 and fully free-format RPG in 2013 (IBM), removing the column dependency entirely. Modern free-format ILE RPG reads much like a conventional structured language and is the form a new developer can actually learn quickly.

The practical reality: a single core application often has RPG II programs calling RPG III programs calling ILE RPG, with CL stitching it together. Modernizing the RPG means meeting each layer where it is — not pretending it is all one thing.

The spectrum of approaches

RPG modernization is best understood as a spectrum from “change the least” to “change the most”, a specialization of the general 7 Rs of modernization. Each point on it is a legitimate choice for some workload; the error is applying one wholesale.

1. Reface — modernize the interface, leave the code

The shallowest option changes nothing about the RPG logic and only replaces the 5250 green screen with a web or desktop UI, often by transforming display files automatically. It is fast and low-risk, and it solves the “it looks ancient” problem. But it solves only that — the RPG, the skills dependency, and the agility constraints are untouched. Refacing is covered in depth in Part 6; here it is enough to say it is a UI move, not a code-modernization move, and it is frequently mis-sold as the latter.

2. Convert fixed-format to free-format ILE RPG

This keeps the logic on IBM i but makes it dramatically more maintainable. Fixed-format RPG II/III is converted to free-format ILE RPG — the same behavior, expressed in a form modern developers can read and that a new hire can actually learn. This directly attacks the skills problem from Part 2: readable code is hireable-for code. It does not move you off the platform and does not, by itself, fix the program structure — but it is one of the highest-value, lowest-risk moves available, and a sound first step even when an eventual off-platform migration is the goal, because readable code is far easier to transform later.

3. Restructure into modular ILE procedures

A deeper in-place modernization breaks monolithic programs — single RPG programs of thousands of lines doing everything — into modular ILE procedures and service programs with defined interfaces. This is genuine refactoring: the business logic stays in RPG and stays on IBM i, but it becomes testable, reusable, and callable. Crucially, well-structured ILE service programs can be exposed as APIs, which is what lets a modern web or mobile front end reach the proven logic without a rewrite. For many shops committed to IBM i, the combination of free-format conversion plus modularization plus API enablement is the modernization — and it is far cheaper and safer than leaving the platform.

4. Transform off the platform into a modern language

The deepest option transforms the RPG into a modern off-platform language — Java, C#, or similar — as real source the team maintains going forward, typically as part of moving the whole workload to a modern, cloud-portable stack. This is the right path when the goal is platform independence, a unified technology stack, or an architecture change the AS/400 cannot accommodate. It is also where the most common and most expensive disappointment lives, which is the subject of Part 4.

The “RPG written in Java” trap

Because it is the option buyers most often ask about, it deserves naming here. Automated RPG-to-Java (or RPG-to-C#) conversion tools can move code quickly, and the demos are persuasive. But unattended, they tend to produce a literal translation: the monolithic program shape, the global data, the procedural control flow, all preserved and re-expressed in Java syntax. The result compiles and runs, and it is genuinely off RPG — but it carries every legacy structure and none of the maintainability, testability or idiom you were modernizing for. You have spent a migration budget to arrive at “RPG written in Java”, which is often harder to maintain than the original because it is now legacy code in a language that pretends to be modern.

This does not mean conversion tools are useless — far from it. It means conversion is an accelerator, not an end state. Used well, the machine drafts the translation and senior engineers reshape the output into real domain services, with every slice proven at parity against the running AS/400. The output is judged by whether it is genuinely maintainable, not by whether it compiles. The general dynamic — that tool-driven conversion under human review beats both manual rewriting and unattended automation — is covered across the AI-in-modernization series; on RPG it is especially sharp because so few people can review the result.

How to choose — match the approach to the goal

There is no single correct strategy, and anyone who leads with one before understanding your estate is selling a product, not solving your problem. The choice follows from two questions:

• Are you staying on IBM i or leaving it? If the platform is fine and the problems are maintainability, skills and connectivity, the in-place path — free-format conversion, modularization, API enablement — keeps your proven logic where it runs and is cheaper and lower-risk. If you need cloud portability, a unified stack, or an architecture the platform cannot support, transformation off the platform is warranted. Part 7 and Part 8 tackle this decision head-on.
• What is each program’s pressure? A stable program nobody is changing may need only refacing or nothing at all. A program blocking new channels needs API enablement at least. A program at the center of an architecture change needs transformation. A real estate gets a mix, assigned program by program after discovery — never one approach applied across the board.

Most disappointments in RPG modernization come not from picking the wrong tool but from picking one tool for everything.

Where this leads

This part mapped the full spectrum and drew the key line between modernizing RPG in place and moving it off the platform. For the workloads on the off-platform side of that line — the ones headed for a unified, cloud-portable stack — the question gets specific: how do you actually transform RPG into modern Java (or C#) without ending up with the literal-translation trap, and without losing the enforced business rules in the process? Part 4, RPG to Java Migration, is the deep dive on that path — what real transformation looks like, where it goes wrong, and how parity validation keeps it honest.