IBM i retirement wave: what IT managers must do by 2030

IBM i skills just became the number one concern for IBM i shops, beating out security for the first time since anyone started measuring it. That is the headline from the 2026 Fortra IBM i Marketplace Survey, and if you run an IBM i shop, it is not a surprise. The IBM i developer retirement wave is here, and the clock you should be watching is not the one most articles point at. The people who keep your business running are getting older, and the pipeline behind them is thin. This is what the wave actually looks like, and what to do about it before 2030.

Two clocks, not one

The most expensive mistake an IT manager can make right now is confusing two separate countdowns.

The first clock is the platform. IBM publishes a roadmap for IBM i that currently runs to 2035 and gets updated every year. IBM i 7.6 shipped in April 2025 and is expected to stay supported for about a decade. Very few operating systems have a published support horizon that far out. The platform is healthy, IBM is still investing in it, and nobody is forcing you off it.

The second clock is your people. A large share of working RPG developers are in their 60s. Industry analysis from ASNA notes that a typical career-RPG programmer born in 1955 turned 70 in 2025, and that roughly 30% of senior RPG developers have already retired over the last 10 to 15 years. Most shops expect their most knowledgeable IBM i staff to be gone within five to ten years.

Those two clocks run at completely different speeds. The platform gives you until 2035. Your people give you until about 2030. When managers tangle these together, they make one of two errors: they panic into a rushed migration the business does not need, or they relax because “IBM i isn’t going anywhere” and do nothing while their best developer edges toward retirement. Both are wrong for the same reason. You do not have an IBM i problem. You have a people problem wearing an IBM i costume.

What the 2026 data actually says

The 2026 Fortra survey, conducted in late 2025 with around 320 respondents, found IBM i skills marked as a top concern by 69% of shops, up from 60% the year before. Security had topped that list every year since 2017. This is the first time skills knocked it off.

That shift is not abstract. It reflects what IT managers are seeing on their own teams: the person who knows why a 30-year-old order-entry program does that one strange thing every quarter-end is the same person eyeing a retirement date. RPG and IBM i still run the backend for a real slice of US manufacturing and distribution, with industry estimates in the 25% to 30% range for that sector. This is production code moving real money, not a museum exhibit.

Why small teams face the most retirement risk

Around 21% of shops report 3 to 5 IBM i developers, and that number has barely moved in a decade. The average IBM i shop runs about three programmers total.

Do the math on that. If one of three developers retires, you have not lost 33% of your headcount. You have lost 33% of everything your organization knows about systems that took 30 years to evolve. There is no redundancy. The business logic lives in three heads, and one of them is leaving. Here is what actually happens to those programs once that developer is gone. A large enterprise with 40 developers can absorb a retirement. A three-person shop cannot, and three-person shops are the norm.

This is why the small and mid-sized IBM i shop should feel more urgency than the Fortune 500, not less. The big shops have a bench. You have a cliff.

The mistake managers make first

Walk into most vendor conversations about the retirement wave and you will be sold a migration, though what a migration actually involves is rarely what the sales deck shows. Convert your RPG to Java, or .NET, or move to the cloud, and the skills problem goes away because anyone can maintain modern code.

There is a real argument there, and for some shops modernization is the right long-term call. But running it first gets the order backwards. If you migrate code your team does not fully understand, you migrate the bugs and the undocumented business rules along with it, and you do it without the one person who could have told you what that code was actually for. Migration does not capture knowledge. It assumes the knowledge already exists in a form you can hand to someone else. In most IBM i shops, it does not.

The undocumented business rules, the workarounds, the data flows that quietly keep the company running, those live in people’s heads and almost nowhere else. That is the asset at risk. Protect it first. Modernize second.

What to do before 2030, in priority order

Here is the sequence that protects the business fastest, regardless of whether you ever migrate a single line of code.

Inventory who knows what. Map your critical applications against the named individuals who understand them. Mark every system where exactly one person holds the knowledge. Those single points of failure are your real risk register, and most managers have never written this list down.
Document the business rules while the veterans are here. This is the step that cannot wait. Sit your senior developers down and capture why the code does what it does, not just what it does. The “what” you can read from the source. The “why” retires with the developer. Prioritize the single-point-of-failure systems from step one.
Modernize the toolchain so new hires can be productive. A developer hired in 2027 should not have to learn a green-screen editor from 1994. Moving your team onto VS Code with the Code for IBM i extension lowers the barrier for new people and connects you to the modern AI tooling that does not exist on older editors. We covered that shift in detail in our RDi vs VS Code comparison.
Train internally and hire deliberately. Pulling a curious Java or Python developer onto the IBM i team and pairing them with a veteran works better than searching for a unicorn who already knows RPG. Start this while the veteran is still employed, because the value is the mentorship, not the job posting.
Modernize the code last, and only where it earns its keep. Once knowledge is captured and your toolchain is current, you can decide calmly which applications justify a rewrite and which should simply be maintained. Some of that 30-year-old code will outlive all of us, and that is fine. Our guide on where to start with IBM i modernization walks through that decision.

Where AI helps with knowledge capture

The reason 2030 is workable rather than hopeless is that documenting legacy code got dramatically faster. AI tools can read RPG, CL, and COBOL and produce first-draft documentation in minutes instead of the weeks it used to take by hand. That changes the economics of step two entirely.

The honest version of this: AI is good at the mechanical layer. Point it at a program and it will summarize the logic, flag the data access, and describe the control flow. A veteran developer then reviews that draft, corrects it, and adds the context the code cannot reveal on its own. That review loop is the whole point, and it only works while the veteran is still on staff. AI plus a present expert is fast and accurate. AI alone, after the expert has retired, produces plausible documentation that nobody can verify.

If you want a head start on the prompts and workflows for this specific kind of IBM i documentation work, that is exactly what our IBM i AI Field Guide is built for. We also wrote a practical walkthrough of documenting RPG IV code with AI if you want to see the approach before committing to anything.

A simple starting checklist for each critical program: what business process does it serve, what triggers it, what are the inputs and outputs, what are the known edge cases and quarter-end or year-end behaviors, and what would break downstream if it stopped running. Capture those five things for your single-point-of-failure systems and you have already removed most of the catastrophic risk.

Bottom line

The platform is not your problem. IBM i has a clearer future than most of the tools your developers use to complain about it. Your problem is that the knowledge holding your business together is scheduled to retire, and unlike the platform, that knowledge has no support extension.

Start with the list of who knows what. Document the business rules while the people who understand them are still at their desks. Get the toolchain current so newer developers can actually work. Treat code modernization as the last step, not the first. Do that, and the retirement wave becomes a planning exercise instead of an emergency. Wait until 2029, and it becomes the most expensive lesson your company learns this decade.

Frequently Asked Questions

Is IBM i being discontinued?

No. IBM publishes a roadmap for IBM i that currently extends to 2035 and is updated annually. IBM i 7.6 shipped in April 2025 and is expected to be supported for roughly a decade. The platform is not the risk. The retirement of the developers who maintain it is.

When will most IBM i developers retire?

Most organizations expect their most knowledgeable IBM i staff to retire within five to ten years. A large share of working RPG developers are already in their 60s, and roughly 30% of senior RPG developers have retired over the last 10 to 15 years. That puts the practical deadline for capturing their knowledge around 2030.

Why is the RPG developer shortage getting worse?

RPG is taught at very few universities, so the replacement pipeline is not refilling. RPG job postings typically run 10 to 30 openings at any time versus thousands for languages like C# or Java, which makes experienced RPG developers scarce and expensive to replace from outside.

What should IT managers do first about the IBM i skills gap?

Document the undocumented business rules first, while the veterans who understand them are still employed. Modernizing the toolchain and the code matters, but neither helps if the institutional knowledge walks out the door before it is captured.