RPG Development Services: Solving the Maintainer Knowledge Gap

The usual argument is that RPG is a dying language, and the best option is to move away from it. That misses the real problem. In many organizations, the immediate risk is not the language itself. It is the loss of the people who understand how the application actually works. Turning that problem into a rewrite project can make matters worse because a rewrite still depends on the knowledge that is already disappearing. Anyone considering RPG development services first needs to decide whether they are trying to modernize the application or preserve the knowledge behind it. 

RPG itself is not necessarily the constraint. Modern free-form RPG is readable to developers with experience in procedural languages, IBM continues to invest in the platform, and the language runs on an operating system that received a major release in 2025. The bigger concern is the people who know which of the thousands of programs are still important, which ones can be ignored, and why a particular business rule contains an exception that nobody else remembers. 

The Platform Is Not the Constraint on iSeries Application Development 

This distinction matters because it changes what an organization should do next. IBM made IBM i 7.6 generally available in April 2025 for Power10 and Power11 hardware. According to IBM’s documentation, the release included multifactor authentication in the operating system and enhancements to Db2 for i. IBM has also set September 30, 2026, as the end of standard support for IBM i 7.4. That is a support deadline, not an indication that the platform is going away. 

For organizations budgeting for RPG development services, the picture is therefore fairly clear. The platform has a roadmap, and the language remains usable. The greater risk sits in the application itself and in the knowledge held by the people who built and maintained it. 

Why Knowledge Transfer Usually Fails 

It Gets Scheduled as Shadowing 

A developer with decades of experience is paired with a new team member for a few weeks. The new person gets a tour of the system and learns where things are located. What is harder to capture is the reasoning behind the code. 

That knowledge usually appears when something unexpected happens. A production issue, an unusual transaction, or an old business exception reveals why a particular piece of code exists. A scheduled shadowing session rarely captures that kind of knowledge. 

It Has No Deliverable 

If the only goal is for someone to "know the system," there is no reliable way to determine whether the transfer worked. By the time the experienced developer leaves, it may be too late to find out what was missed. 

The output should be something that another person can actually use. That could be a documented business rule, a data flow, a runbook, or an annotated program. These artifacts can be reviewed while the original developer is still available to answer questions and correct mistakes.