The AS/400 Talent Shortage: What Happens When Your RPG Developer Retires?

There's a specific kind of quiet panic that sets in when a company realizes the person who understands their AS/400 system is retiring in six months, and there's no one else who can read the RPG code underneath it.

This isn't a rare situation. It's one of the most common and least discussed risks running through manufacturing, distribution, banking, insurance, and government organizations right now. The IBM AS/400 — now more formally known as IBM i, running on Power hardware — is still quietly powering core operations at tens of thousands of mid-size and large organizations worldwide. And the generation of developers who built and maintained these systems is retiring faster than anyone is replacing them.

Why AS/400 Systems Are Still Everywhere

The AS/400 platform, first introduced in 1988 and continued today as IBM i, earned a reputation for extraordinary reliability that's hard to overstate. Systems built on it in the 1990s are, in many organizations, still running the exact core business logic that handles inventory, order processing, accounting, and manufacturing operations — sometimes with uptime records measured in years, not days.

This reliability is exactly why replacing these systems has never felt urgent. The platform works. It's stable. It processes transactions correctly, day after day, year after year. There's rarely a dramatic failure that forces the issue. Instead, there's a slow-building risk that most organizations underweight until it becomes acute: almost nobody is training new developers on it anymore.

The Skills Gap Is Real, and It's Accelerating

RPG (Report Program Generator) and the broader IBM i ecosystem — CL, DDS, native IBM i database structures — were widely taught in the 1980s and 1990s. They are close to absent from current computer science curricula. The developers who learned these skills early in their careers are now, overwhelmingly, in their late 50s, 60s, and beyond.

This creates a specific and predictable crunch: organizations that depend on AS/400 systems for core operations are watching their pool of qualified maintainers shrink every year, with very little new talent entering the pipeline to replace it. A system that has run reliably for two decades doesn't become less valuable as this happens — it becomes more fragile, because the margin for error when something does need fixing keeps narrowing.

What This Actually Looks Like Inside an Organization

A single retiring employee holds irreplaceable institutional knowledge. In many organizations, one or two long-tenured developers understand not just the code, but the years of accumulated business logic embedded in it — decisions made a decade ago that were never fully documented, workarounds for edge cases that only exist in someone's memory. When that person retires, that knowledge doesn't transfer. It disappears.

Simple changes become high-risk projects. A business requirement that would take an experienced RPG developer an afternoon becomes a multi-week undertaking when the only people who understand the codebase are gone, and whoever's left has to reverse-engineer the logic before touching it.

New hires are difficult to find and expensive to retain. The remaining pool of developers with genuine RPG and IBM i expertise commands a premium, precisely because demand is now outpacing a shrinking supply — and many of them are approaching retirement themselves.

The instinct to "just replace it" runs into a wall. Full replacement of a mature AS/400 system that's been accumulating business logic for twenty-plus years is a genuinely difficult, expensive, multi-year undertaking — which is exactly why so many organizations have avoided it for this long. The system works. Replacing it carries real risk. But maintaining it with a shrinking, aging talent pool carries a different kind of risk that compounds quietly every year.

The Real Options for Organizations in This Position

Bring in a development partner who actively maintains RPG and IBM i skills, rather than waiting for internal knowledge to run out entirely. This doesn't require replacing the system — it means having reliable, ongoing access to people who can read the existing codebase, make changes safely, and document what they learn as they go, rebuilding the institutional knowledge that's otherwise walking out the door.

Prioritize documentation as an active project, not an afterthought. If you still have someone who understands the system, the single highest-value project available right now is capturing that knowledge in usable documentation before it's gone — not eventually, but now, while there's still someone who can validate it's accurate.

Consider an integration-first modernization approach rather than full replacement. Many organizations don't actually need to replace their AS/400 core system to get real value from modernization — building a modern integration layer, a better-designed front end, or improved reporting on top of the existing system can deliver significant improvement without the risk and cost of a full platform migration.

When full modernization does make sense, plan it as a multi-year project with real knowledge transfer built in, not a rushed initiative triggered by a crisis. Organizations that wait until the last knowledgeable person is walking out the door to start planning a transition consistently pay more, in both cost and risk, than organizations that start the process proactively.

Why This Requires a Genuinely Capable Partner, Not Just Any Developer

Working effectively with an AS/400 or IBM i system requires more than general software development skill. It requires people who can actually read RPG and CL code, understand the specific database and architecture conventions of the platform, and — critically — can bridge that legacy environment with modern development practices, APIs, and integration approaches that let the system connect to the rest of a modern technology stack.

> Ontoborn works with organizations running mature legacy systems — including AS/400 and IBM i environments — providing both ongoing maintenance support and modernization pathways that don't require ripping out decades of stable, working business logic. Our approach is the same one behind our broader legacy system work: understand what's actually running, document it properly, and build a path forward that respects both the platform's reliability and the organization's real appetite for risk.

The Question Worth Asking Now

If your organization runs core operations on an AS/400 or IBM i system, the question worth asking isn't "should we replace it." It's: who currently understands this system well enough to maintain it safely, what happens when that person is no longer available, and do we have a real plan — not just an assumption that we'll figure it out when the time comes.

The organizations that handle this transition well are almost always the ones that started planning before the retirement notice arrived, not after.

At Ontoborn, we have been the long-term software partner for enterprises, universities, and growing businesses for over a decade. We do not just build and move on. We stay.

If you are looking for a partner — not just a vendor — we would like to talk.

Start a conversation →

Ontoborn Technologies is a custom software development and maintenance company trusted by enterprises, universities, and growing businesses for over a decade. We build software that lasts — and stay with you after launch.