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. 

It Starts with the Wrong Programs 

Older environments often contain source code that is no longer being used. An RPG AS400 programmer who inherits such an environment may assume that every program matters simply because it is still there. 

Documenting everything is rarely the best use of time. A better starting point is the code that actually runs. Job logs and program call data can help identify the active working set, which is often much smaller than the full source library. 

What to Extract, in Order 

A practical knowledge transfer effort should follow the application as it operates rather than trying to document the entire codebase at once. 

1. Live inventory: Identify which programs run, how often they run, and what triggers them. 
2. Data model in practice: Document how the data is actually used, including files written by multiple programs. Shared files often contain important business exceptions. 
3. Business rules: Describe the rules in plain language, with separate documentation for each functional area. The goal is to make the rules understandable even to a developer who has never worked with RPG. 
4. Integration points: Record every connection to other systems, including scheduled transfers and screen-scraping processes. 
5. Exceptions and workarounds: Capture the manual steps that operations teams use when the standard process does not work. These are often some of the least documented parts of an application. 
6. Deployment and change process: Document how changes are actually tested, approved, deployed, and maintained. 

The business rules deserve particular attention because they remain useful regardless of what happens to the platform. That knowledge can support continued iSeries application development, an interface modernization effort, or a future rewrite. Capturing it once gives the organization more options later. 

Using AI Assistance Without Fooling Yourself 

AI can make this work considerably faster. A language model can summarize unfamiliar code, suggest plain-language descriptions, and help engineers work through large numbers of program members. That can remove much of the repetitive work involved in the first pass. 

There is an important limitation, though. AI can describe what the code appears to do. It cannot reliably explain why a business rule exists, whether that rule is still valid, or why an exception was added years ago. 

That makes the division of work straightforward. AI can handle repetitive extraction. Engineers and subject matter experts need to own the interpretation, architecture, judgment, and review. A generated description that has not been checked by someone with the right domain knowledge is not reliable documentation. It is only an interpretation of the code. 

The Verification Rule