modernlift.

Talk to an expert

Or email us: sales@modernlift.ai
AS/400 (IBM i) & RPG modernization

Off the green screen,
onto a modern stack.

The AS/400 — IBM i — has run order entry, distribution, and manufacturing for decades, reliably, behind a 5250 screen most of your users have learned to route around. We modernize it one slice at a time — RPG, DB2 for i, and the display files read together, parity proven before any cutover.

Book a discovery call How the slice loop works →
The stack

Rock-solid, and quietly stranded.

Few platforms have earned their reputation for reliability the way the IBM i has. The problem is rarely uptime. It is that the value is locked in. Business logic lives inside large, monolithic RPG programs where display handling, file I/O, and rules are interleaved in the same source — so the green-screen 5250 interface and the logic underneath cannot be separated without care. New channels — web, mobile, partner APIs — get bolted on as screen-scrapers rather than built properly. And the RPG specialists who know how it all fits together are retiring, with few replacements coming up behind them. The system keeps working; the ability to change it erodes year over year.

What modern looks like

An RPG estate, rebuilt for the open market.

For an RPG estate the target is concrete: RPG — III, IV, and free-format — re-expressed as domain services behind a modern API and web UI, DB2 for i moved onto a modern data layer, and the 5250 green-screen flows rebuilt as real interfaces, with the business rules they enforce preserved exactly. Which language, which cloud, which data platform — that is chosen with you in Discovery, not dictated by the source, and it can land in a regulated or air-gapped environment. What we hold constant is the shape of a system built to last.

A real UI, not a 5250 emulator
The green screen becomes a modern SPA designed around the task, not the 24x80 character grid. The workarounds your users built in spreadsheets stop being the real process.
Logic split out of the program
Rules interleaved with display and I/O inside monolithic RPG are extracted into explicit, testable domain services — readable by engineers who never wrote a line of RPG.
An API layer over DB2 for i
A cloud-native API layer fronts the data so new channels are built once and reused, instead of scraping screens program by program.
A talent-friendly stack
The result runs on a modern language and platform you can staff from the open market, not from a shrinking pool of RPG veterans.
How we do it

The slice loop, applied to the IBM i.

A slice is a single behavior — one screen, one program. Each is analyzed, rebuilt, validated in shadow against the IBM i, and promoted only on parity. A strangler facade shifts traffic gradually; the RPG retires last.

01
Analyze
AI deep-reads the RPG — fixed-format and free-format — alongside the DB2 for i schema and the 5250 display files. Monolithic programs, their internal subroutines, and the data they touch are captured as a living spec. The pass runs 10× faster than manual review: typically 12 weeks down to 2.
02
Transform
One behavior at a time — a single screen, a single program — is rebuilt on a modern target. The logic that the green screen and the database hold jointly becomes an explicit service.
03
Validate
The new slice runs against the IBM i under shadow traffic until behavior, data integrity, and the edge cases match. The parity gate stands between every slice and production.
04
Cut over
A facade in front of the IBM i shifts traffic gradually. Diverge, and it rolls back. The RPG program is decommissioned only once the modern slice is proven.
Where the advice stops
Slice-by-slice depends on being able to isolate a behavior and observe it in production. Some IBM i estates resist that: programs bound to DB2 for i through deep record-level-access coupling, older OPM code mixed in with newer ILE RPG, green-screen workflows with business rules embedded so deeply in the display path that no screen carves out cleanly. Where that is the case, the first slices take more groundwork — and we say so in Discovery, not once the work is already underway. Naming the hard cases up front is part of the method. Read the full approach →