AS/400 Talent Shortage & Risk
The AS/400 skills shortage is the gap between a shrinking pool of RPG and IBM i developers — aging, retiring, and not being replaced because the platform is taught almost nowhere — and the business-critical systems that still depend on them. In Fortra's 2026 IBM i Marketplace Survey, 69% of organizations named IBM i skills a top concern (Fortra, 2026). The real risk is not the platform's age; it is key-person dependency on undocumented business rules that leave when the last expert retires. The mitigation is to capture that knowledge from the code as living specs before it walks out the door.
Part 1 made the case that the AS/400 is not dying — IBM still supports it, and the hardware underneath it is current. So if the platform is healthy, where does the urgency come from? From the people. The single most important fact about AS/400 modernization is that the workforce who built and maintain these systems is retiring, and almost nobody is being trained to replace them. This part is about that skills cliff: what it looks like, what it actually costs, and why the right response is to capture knowledge rather than to panic-migrate.
The shape of the shortage
The AS/400 skills problem has three reinforcing parts, and each makes the others worse.
The workforce is aging. The RPG developers who built these systems in the 1980s, 90s and 2000s are now late-career or already retired. This is not a vague worry — it is the dominant theme of the platform’s own community surveys. In Fortra’s 2026 IBM i Marketplace Survey, 69% of organizations named IBM i skills as a top concern, up from 60% the prior year and now the single highest-ranked concern on the platform, ahead of cybersecurity (Fortra, 2026). When the people running a platform say their biggest worry is having anyone left who can run it, that is the signal.
The pipeline barely exists. RPG and IBM i are taught at a handful of universities and almost nowhere in mainstream computer-science curricula. New graduates learn Python, JavaScript and Java; they do not learn RPG, and most have never heard of it. So while the existing workforce ages out, very few new entrants replace them. The pool does not just shrink — its average age climbs.
Demand has not gone away. The systems these developers maintain are still running the order, the invoice, the ledger and the inventory. The work did not disappear when the workforce started retiring; it concentrated onto fewer and fewer people. In the same survey, 62% of organizations named application modernization a top concern (Fortra, 2026) — the recognition that the systems themselves, not just the staffing, need to change.
The pattern mirrors the broader legacy workforce. On the mainframe side, IBM (reported via Fujitsu, 2020) put the average COBOL developer’s age near 58 with roughly 10% of that workforce retiring each year — a different language and platform, but the same demographic curve and the same lesson: the people who hold the undocumented rules are leaving on a schedule.
Why this is a business risk, not an IT inconvenience
It is tempting to file “we’re short on RPG people” under staffing problems and move on. That underrates it badly, because the risk is not really about headcount — it is about knowledge concentration.
Key-person dependency. In many shops, one or two people understand how the core system actually works. They know which programs are safe to touch, where the landmines are, why a particular calculation is the way it is. That knowledge exists nowhere else — not in documentation, not in comments, not in anyone else’s head. When that person retires, the organization does not just lose a developer; it loses the map.
Change becomes slow and risky. With the experts gone, every change to the system — a new tax rule, a pricing change, a regulatory requirement, a fix for a production bug — becomes a research project. Someone has to figure out what the code does before they can safely change it, and the people who could have told them in five minutes are no longer there. Small changes that used to take a day take weeks, or get outsourced at a premium to contractors who also don’t know your specific rules.
The undocumented rules are the business. This is the heart of it. Decades of RPG accumulate behavior that was never written down — the rounding convention in the invoice total, the special handling for a customer class set up in 1997, the order in which a batch job must run or the month-end close breaks. These are not bugs. They are the business logic, and they are load-bearing. Lose the people who know them and they do not vanish quietly; they surface as “regressions” the first time someone changes the wrong thing. The tribal-knowledge series covers this dynamic in general; on the AS/400 it is acute, because the knowledge is held by the fewest people and recorded in the least-read language.
The traps
Faced with the skills cliff, organizations reach for two responses that feel decisive but tend to make things worse.
Trap 1: hire your way out. The instinct is to recruit more RPG developers or retrain internal staff. It is worth doing at the margin, but it is not a strategy. You are hiring from a pool that shrinks every year, competing with every other IBM i shop, and even a strong new hire arrives knowing RPG in general but not your system’s specific undocumented rules. Hiring buys time; it does not capture knowledge, and it does not address the agility problem at all.
Trap 2: panic-migrate with a big-bang rewrite. The opposite instinct is to declare the platform a liability and fund a rush rewrite or a rip-and-replace ERP swap to “get off RPG” before the last expert leaves. This is the most dangerous response, because it concentrates all the risk into a single cutover and tries to rediscover the undocumented rules at the same time, under time pressure, with the experts already half out the door. It is the archetype of the programs behind the 70% transformation-failure rate (BCG, 2023). Urgency is real; a rushed big-bang is how urgency turns into an outage.
The response that works: capture, then modernize
The durable answer treats the skills cliff as a knowledge-capture problem first and a technology problem second — and crucially, it works with your retiring experts rather than racing to finish before they leave.
Capture the knowledge as living specs. Instead of relying on what people remember to document, read the actual RPG, CL, DB2 for i definitions and display files and derive the behavior from the source — the program call graph, the data flows, the batch dependencies, the business rules and edge cases — written down as specifications tied back to the code. Because they are generated from the system rather than maintained by hand alongside it, they describe what the code truly does, and they do not drift. This is the antidote to documentation decay covered in the tribal-knowledge series.
Do it while the experts are still here. The capture is far more reliable when the people who know the system can review and confirm it. They turn an ambiguous piece of logic into a confirmed rule in minutes; after they retire, the same question takes weeks of reverse-engineering and may still be wrong. This is exactly why the work is a race against the calendar — not because the platform is failing, but because the confirmation gets dramatically cheaper while the experts are available.
Where AI changes the economics. The bottleneck in capturing AS/400 knowledge has always been that reading decades of RPG is slow, manual and dependent on the few people who can still do it. AI-accelerated discovery changes that bottleneck: it deep-reads the RPG, CL and DB2 schema together and drafts the behavior as reviewable specs, taking a pass that would run many weeks down to a fraction of that. The gain is at analysis time — it makes the reading fast so the experts spend their scarce remaining time confirming rather than excavating. It does not replace their judgment, and it does not make a cutover safe; senior engineers own the architecture and the parity gates. AI is how we read the system faster, never a product that decides what the rules are.
What the skills cliff does and doesn’t decide
Capturing knowledge is valuable even if you never migrate. If a workload is stable and you simply want to de-risk the key-person dependency, living specs alone reduce the risk substantially — you can then maintain the system more safely, hire more flexibly, and decide on modernization later from a position of knowledge rather than fear. The skills cliff makes capture urgent for almost every AS/400 shop; it does not make migration urgent for every workload. Separating those two decisions is one of the most useful things this series can offer, and Part 8 returns to it directly.
Where this leads
The skills cliff sets the clock and points to knowledge capture as the first move. But for the workloads that should modernize, the central technical question is what to do with the RPG itself — the language that holds most of the business logic and most of the difficulty. Part 3, RPG Modernization Approaches, lays out the real options for modernizing RPG — from refacing and free-format conversion to full transformation into a modern language — what each one actually achieves, and how to avoid the most common disappointment: ending up with RPG rewritten in another language and none of the maintainability you were after.
Frequently asked questions
- Why can't we just hire more RPG developers?
- Because the pipeline barely exists. RPG and IBM i are taught at very few universities, so almost no new developers enter the field, while the existing workforce ages toward retirement. You are hiring from a pool that shrinks every year, against every other IBM i shop trying to do the same. Contractors fill gaps but command a premium and rarely carry your system's specific undocumented rules. Hiring is a partial, expensive, and temporary answer; capturing the knowledge as living specs is the durable one.
- What is the actual risk if our last RPG developer retires?
- The immediate risk is operational: when something breaks or a regulation changes, no one on staff can safely modify the code, so small changes become slow, risky, and outsourced. The deeper risk is knowledge loss — decades of business rules that live only in that person's head and in code nobody else can read. Once they are gone, those rules can only be recovered by reverse-engineering the RPG, which is far slower and more error-prone after the fact than capturing it while the expert is still available to confirm it.
- Isn't documenting the system enough to solve this?
- Traditional documentation helps but decays — it is written once, drifts out of sync with the code, and is rarely complete. The durable answer is living specifications generated from and tied back to the actual RPG, DB2 and CL, reviewed by the people who still understand the system while they are still here. That captures behavior the code truly exhibits rather than what someone remembered to write down, and it stays accurate because it is derived from the source rather than maintained by hand alongside it.