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 

Every AI-generated rule description needs a named human reviewer with domain knowledge, and the review has to happen while the people who remember are still reachable. The value of automation here is that it lets you spend scarce expert attention on verification rather than on transcription. 

Hiring AS400 RPG Programmers Versus Buying RPG Development Services 

Organizations can still hire AS400 RPG programmers. The market for an RPG AS400 programmer is smaller than it once was, but qualified developers are still available. 

What is much harder to find is someone who already understands a specific company's application. Any new developer will need time to learn the codebase and its business rules. Good documentation can shorten that learning curve. 

There are several ways to address the gap. An organization can hire an iSeries RPG programmer and accept the ramp-up period. It can bring in an external partner for additional capacity while keeping ownership of the business rules internally. Or it can use a hybrid model in which an internal employee retains domain knowledge while external developers handle development work. 

The hybrid approach can be particularly practical because it keeps the scarce knowledge inside the organization while using external capacity where it is easier to source. 

Whichever model a company chooses, documentation should be included as a deliverable in the statement of work. That requirement separates useful RPG development services from simply adding developers to a project. The difference is important. One approach adds capacity. The other can gradually create another dependency. 

Professional AS400/IBM i RPG development service providers can make rule extraction part of the development process rather than treating it as a separate documentation exercise. That makes sense because the best time to document a program is while someone is already working inside it. 

What to Do in the Next 90 Days 

If an experienced developer is likely to retire within the next two years, there is no need to begin with a massive transformation project. 

Start by creating a live inventory of the applications and programs that actually run. From there, identify the programs that would cause the most disruption if their knowledge were lost. Have the retiring developer review AI-generated documentation for those programs instead of asking them to create every document themselves.  

Then pair that experienced developer with the person who will take over the work. Give them a real application change to work on together rather than creating a separate training exercise. 

This approach focuses limited time on the knowledge that matters most. It also gives the incoming developer practical experience with the system while the person who understands it best is still available. 

Frequently Asked Questions 

Is RPG Worth Learning in 2026? 

For developers working in IBM i application development, RPG can still be worth learning. Free-form RPG is accessible to developers with procedural programming experience, and the platform has a published roadmap. The more difficult skill to replace, however, is not knowledge of the language itself. It is knowledge of the business applications built with it.  

Should We Convert Fixed-Format RPG to Free-Form? 

When a program is already being changed, converting the relevant code to free-form can improve readability and make future maintenance easier. 

A full conversion of an entire estate is a different decision. If it does not deliver a functional improvement, it can consume significant time and budget without addressing the organization's immediate knowledge risk. In many cases, converting the programs that are already being touched is the more practical approach. 

Can Automated Tools Rewrite RPG Into Java or C#? 

Automated tools can generate code that compiles. That does not automatically make the resulting application maintainable. 

A translated application can retain the structure of the original code while losing the conventions and context that made the original understandable. Developers may then end up maintaining unfamiliar code in an unfamiliar structure. 

Automation is often more useful for analyzing and documenting an existing RPG environment than for producing the final replacement application. For many iSeries application development projects, understanding the existing system should come before deciding how to replace it. 

How Do We Keep an iSeries RPG Programmer We Already Have? 

Compensation matters, but it is not the only factor. Being the sole person responsible for a critical application can become a burden. 

Documentation and cross-training can help. Giving another person exposure to the system reduces the pressure on the existing developer while making the role more sustainable. It also protects the organization from relying on a single person for essential knowledge. 

What If Our Documentation Effort Has Already Failed Twice? 

The problem may be the scope rather than the need for documentation. Trying to document everything, without a clear deadline or a defined audience, makes the work difficult to finish. 

Focus instead on the programs that are actually being used. Connect documentation to real development work, give each document a clear reader, and assign someone to review it. Documentation is much easier to complete when people know who will use it and why. 

RPG may outlast the people who built your applications. That is the real challenge. It does not automatically call for a multi-year rewrite. A focused effort to identify and capture critical application knowledge can reduce the risk while giving the organization more choices about what comes next. 

Expert RPG development services focus on extracting that knowledge while experienced developers are still available to validate it. The immediate goal is not to preserve RPG for its own sake. It is to preserve the business knowledge that makes the application work.