Your people are the deadline

The AS400, now IBM i, has earned its reputation. It runs for years without falling over, and for order processing, inventory, and distribution, it still does its job well. Most companies asking about AS400 modernization aren’t dealing with a failing system.

What they’re dealing with is a shrinking pool of people who can keep it running. Fewer developers learn RPG every year, and the ones who know your system are often a few years from retirement. Meanwhile, the rules that run your business, how you price, allocate, ship, and bill, live inside decades of code that in many cases nobody has written down anywhere else.

That’s the clock to watch. Sooner or later you’ll leave. What matters is how.

The options, and where each one breaks

Leave it alone. Works until the person who understands it leaves. After that, every change gets slower, riskier, and more expensive, and eventually nobody wants to touch it at all.

Put a new interface on it. The screens look modern and training gets easier. But nothing underneath changes. The business rules are still in RPG, and you still depend on the same shrinking pool of people to maintain them. It makes the system easier to use without making it any easier to keep running.

Wrap it in APIs. This is the first option that moves anything. Once other systems reach the AS400 through defined connections, the logic behind each one can be rebuilt and replaced on its own schedule. The RPG doesn’t go away immediately, but it stops being one unbreakable block.

Replace it with packaged software. The right answer if your processes are truly standard. The wrong one if the AS400 was encoding the way you compete. Buy the ordinary. Build the difference.

Rewrite everything at once. Done badly, this is where migrations fail: a hard cutover, and undocumented rules that surface after go-live. Done well, the new system is built alongside the old one, which keeps running untouched, and the two are compared side by side until everyone trusts the results. That removes most of the technical risk. What’s left is harder to manage: the full investment comes up front, and nothing reaches users until it’s done. We’ve built a system this way. The result was solid, but it took years before anyone used it day to day, and that wait was harder on everyone than the work itself. If you take this path, find ways to put pieces in people’s hands early, even if the full cutover is a long way off.

Move off in phases. Get the business rules out of the code and out of people’s heads first. Then rebuild one area at a time, moving its data into the new system as you go. During the transition, the two databases are kept in sync, and each request is routed to whichever system owns that piece. It delivers value sooner and spreads the cost, but keeping two systems consistent takes ongoing effort, and it usually costs more in total.

Speed versus cost

Most companies end up choosing between the last two. Phased costs more in total but starts paying back sooner. Building in parallel can cost less, but you carry the full investment until cutover. Neither is wrong. Which one fits depends on how long the business can wait, and how long the people who understand the current system will be around.

There’s also the cost of standing still. IBM i licensing and the specialized hardware and support around it are expensive, and a modern database on a cloud platform costs a fraction of that to run. The rebuild itself offsets some of those savings, but the gap doesn’t close.

Before: Green-screen workflow.
Before: A green-screen AS400 workflow.
After: Modernized browser-based workflow.
After: A modernized browser-based workflow. What users see changes either way. The test is whether the rules behind it moved too.

Which path fits depends on what’s inside

The right mix comes down to a few questions. How close is the knowledge to walking out the door? How much of the logic is unique to how you operate? How tangled are the dependencies between parts of the system? What can’t go down, even for an afternoon?

None of those can be answered from the outside. That’s what an Assessment is for: understanding what’s actually in the system before committing to a direction. For a broader way to think about the decision itself, see Modernize, Stabilize, or Leave It Alone.

If the person who knows the system is close to leaving, that’s your deadline, more than the platform’s age or the next hardware refresh.