AS/400 (IBM i) Migration & RPG Modernization

Let’s start with what’s true: the AS/400 — IBM i, in its modern name — is one of the most dependable platforms ever built, IBM still supports and updates it, and the RPG applications running on it have processed the business correctly for decades. This is not a “your system is broken” story, and we won’t pretend otherwise. The reason to modernize off IBM i is not that the platform is failing. It’s that the people who can maintain it are retiring, the platform is expensive to stay locked into, and a green-screen RPG estate is increasingly hard to connect to everything else the business now runs on.

Where IBM i actually stands

There’s no support cliff to point at, so the honest framing replaces a date with three pressures that build over time:

Pressure	What it looks like	Why it matters
Platform support	Actively supported and updated by IBM	Not the problem — the platform itself is fine
Skills	RPG/IBM i workforce nearing retirement, few new entrants	The system becomes unmaintainable from the inside out
Cost & lock-in	Proprietary hardware, IBM i licensing	A fixed tax that’s hard to renegotiate or escape
Integration	Green-screen RPG, limited modern API surface	Hard to connect to cloud, mobile, and modern data

The skills pressure is the one with momentum behind it: a widely-cited industry analysis of the IBM i community projects the average RPG developer approaching 80 by 2030, surveys already put a large share at or past retirement age, and few universities still teach the language. That’s not a date IBM sets — it’s a demographic one the market sets, and it doesn’t reverse.

What the real risk is — and isn’t

Because there’s no EOL date, it’s worth being precise about where the exposure actually lives.

• The skills cliff is the headline. Each year there are fewer engineers who can read and change the RPG, the knowledge of what the code does leaves with them, and routine changes get slower, riskier, and more expensive to contract out. A stable system you can no longer safely modify is a different kind of liability than an unpatched one — but a liability all the same.
• Lock-in is a standing cost. Proprietary hardware and IBM i licensing are a fixed line in the budget that’s difficult to renegotiate and impossible to compete away while you’re on the platform.
• Integration is the agility tax. Connecting green-screen RPG and its data to modern cloud services, mobile front ends, and analytics is consistently harder than it should be, which slows down everything the rest of the business wants to build.
• What it is not is a security-patch emergency or a compliance finding driven by an unsupported runtime. IBM patches the platform. Conflating IBM i with an out-of-support Windows or SQL Server would be dishonest, and we won’t.

The migration options

There is no single right move; there’s a right move for your estate, and it turns on how much of the value is durable business logic versus green-screen plumbing.

• Stay and invest in skills. Keep the system, train or contract RPG talent, and accept the cost and integration limits. A defensible choice for a stable, low-change system — but it’s a bet against a demographic trend, and it doesn’t get easier with time.
• Refactor the RPG on-platform. Move from fixed-format toward free-format RPG and better-structured code, keeping IBM i underneath. Reduces the worst of the maintainability problem without addressing lock-in or integration; a reasonable interim step.
• Re-platform the application off IBM i. Rebuild the application on a modern stack, preserving the durable business logic and discarding the green-screen UI and platform-specific plumbing. The transformative path — it addresses skills, lock-in, and integration together — and the one that turns a frozen RPG estate back into a system the business can change.

The decision turns on the split between business logic and green-screen plumbing, just as it does with other UI-heavy legacy stacks. Separating the RPG that encodes genuine rules from the code that only exists to drive the 5250 screen is the core of the work.

How we modernize off it

We treat an IBM i estate the way we treat any legacy system: not one risky big-bang rewrite of decades of RPG, but a sequence of small, reversible steps.

A strangler facade sits in front of the application so the legacy IBM i system and the modernized path run side by side. A program, a transaction, a related cluster of screens moves at a time, and before any of it carries live traffic, we prove it behaves identically to the legacy: same outputs, same state, validated against real behavior. AI-accelerated discovery reads the RPG, the data structures, and the job flows end to end and captures what they actually do — including the undocumented rules buried in code whose authors have long since retired — under senior-engineer review. Traffic shifts only on green, rollback stays a flag away, and the legacy programs are retired only once nothing depends on them.

The case for staying put

This is the section where we have to be most careful, because it would be easy to oversell. IBM i is supported, reliable, and for some organizations the right place to stay for years yet — particularly a stable, low-change system where the team is intact and the integration limits aren’t biting. If “it still works and we can maintain it” is genuinely true for you, modernization can wait, and an on-platform RPG refactor may be all you need. The case to re-platform gets compelling when the skills risk is real and near, when the lock-in cost is material, or when the inability to integrate is actively holding the business back. We’d rather scope that honestly than sell a migration against a deadline that doesn’t exist.

Where to start

The first step is small and bounded: understand the estate before committing to a path. A discovery call scopes how much RPG is in play, how durable the business logic is, how exposed you are to the skills cliff and the lock-in cost, and whether the right move is to stay, refactor on-platform, or re-platform off it — on evidence, not a sales pitch. Reach the team at sales@modernlift.ai.