5 Signs Your AS/400 System Is Overdue for Modernization
Nobody wakes up one morning and decides their AS/400 needs modernizing. It's a slower realization — a string of small frictions that eventually add up to a real business risk. If you're on the fence about whether now is the time, these five patterns are the ones we see most often in the systems we're eventually called in to fix.
"The system still works" and "the system is safe to keep running" are not the same claim.
1. Every change request comes with a side of anxiety
When a two-line change to an RPG program requires a full regression test of three unrelated modules "just to be safe," that's not caution — it's a sign the system's dependencies are no longer understood by anyone on the team. Healthy systems let you make small changes with small, predictable blast radii. If your team schedules "extra time for surprises" on every AS/400 ticket, the surprises are the system telling you something.
2. The people who understand the system are retiring
Every AS/400 shop has one or two people who can read the oldest RPG II programs like a second language. When those people retire or leave, they don't just take tenure — they take undocumented business logic that exists nowhere else. This is the single most common trigger for an emergency modernization engagement: a key person leaves, and the organization discovers how much tribal knowledge was never written down.
3. Integration requires a workaround, every time
Modern supply chain, CRM, and analytics tools expect to talk to systems over APIs. If every new integration to your AS/400 core requires a custom flat-file export, an overnight batch job, or a screen-scraping tool bolted onto a 5250 session, you're paying an integration tax on every new initiative your business wants to pursue. That tax compounds — the tenth integration is not cheaper than the first, because there's no reusable interface layer to build on.
4. Reporting takes days, not minutes
If getting an accurate, current answer to "how much inventory do we have across all warehouses right now" requires a batch report that runs overnight, your business is making decisions on yesterday's data by default. Modern planning and supply chain tools assume near-real-time visibility. A core system that can only report in batch cycles becomes the ceiling on how fast the rest of the business can move.
5. New hires can't get productive on the platform
RPG and CL are not skills most computer science graduates arrive with. If onboarding a new developer to your AS/400 environment takes months instead of weeks, your hiring pool is shrinking every year while your existing team ages. This isn't a knock on the platform — IBM i is still a genuinely reliable, high-performance system — it's a statement about how much of the surrounding tooling and interface layer hasn't kept pace.
What this means in practice
None of these five signs mean you need to rip out your AS/400 core and start over — that's rarely the right call, and it's rarely necessary. What they usually mean is that the system needs a modernization layer: API access to core business logic, better documentation of what's actually running in production, and a phased plan to reduce the specific risks above without a disruptive rewrite. That's the approach we take with every AS/400 modernization engagement.
If two or more of these sound familiar, it's worth a conversation before the next retirement, integration request, or reporting deadline forces the issue. See how Hoorbit approaches AS/400 modernization.