Modernization

IBM i Modernization Does Not Mean Rewriting RPG

Modernizing IBM i should not start with replacing everything that works. It should start with improving how the platform is developed, integrated, secured, deployed, and supported.

Published July 4, 2026

IBM i modernization is often misunderstood. For many teams, the word modernization immediately sounds like replacing RPG, removing green screens, moving everything away from the platform, or starting over with a completely new technology stack.

That is not where modernization has to begin.

In many organizations, the real business logic is already working. It is stable, trusted, and deeply connected to how the business runs every day.

The RPG programs, CL processes, Db2 for i tables, data queues, batch jobs, reports, menus, and integrations may not look modern from the outside, but they often represent years of tested business rules.

The problem is usually not that IBM i cannot support the business.
The problem is that the engineering practices around it have not evolved enough.

Modernization should respect what already works

A strong IBM i modernization strategy does not begin by asking:

How do we replace RPG?

It should begin by asking:

What is working, what is slowing us down, and what needs to become easier to integrate, secure, monitor, and change?

That is a very different conversation.

RPG does not automatically make an application outdated.
Green screens do not automatically mean the business process is wrong.
A long-running IBM i application can still be valuable, reliable, and deeply optimized for the business.

But the way teams build, deploy, expose, and support those applications may need to change.

The real modernization opportunities

Modernization can happen in layers.

It may start with exposing existing RPG or CL programs through APIs instead of rewriting them.

It may involve moving source to Git, using VS Code, organizing builds with tools like TOBi, or creating a safer promotion process between development, test, and production.

It may involve better use of SQL and Db2 for i instead of relying only on record-level access everywhere.

It may involve monitoring message queues, job logs, audit journals, QHST, QSYSOPR, and application-specific lifecycle records in a more centralized way.

It may involve securing sensitive data at rest, masking data based on user authority, or building better audit visibility around who accessed what.

None of these require throwing away the platform.

They require building better engineering practices around it.

APIs are not the same as rewriting

One of the most practical modernization steps is API enablement.

Many IBM i applications already have valuable business logic inside RPG, SQLRPGLE, CL, or stored procedures. Instead of duplicating that logic somewhere else, teams can expose it carefully through a modern API layer.

But the important part is not just creating an endpoint.

The important part is deciding:

• Which programs should be exposed?
• How should parameters be defined?
• How should input validation work?
• How should errors be returned?
• How should authority be controlled?
• How should calls be logged and monitored?
• How should long-running jobs be handled?

That is where modernization becomes engineering, not just wrapping old logic with a new interface.

DevOps on IBM i has to respect IBM i

Another common mistake is trying to copy DevOps practices from other platforms without adapting them to IBM i.

IBM i has its own realities:

• Libraries
• Objects
• Source members
• Compile order
• Job descriptions
• Library lists
• Activation groups
• Service programs
• Binding directories
• Environment-specific configuration

A good IBM i DevOps process needs to respect those realities.

Git is valuable.
Automated builds are valuable.
Branch protection is valuable.
Deployment automation is valuable.

But those practices must be designed around how IBM i actually works.

Modernization should make delivery safer, not more fragile.

Security and monitoring are modernization too

Modernization is not only about user interfaces and APIs.

For IBM i teams, security and operations are just as important.

Many systems already contain rich operational and security information through audit journals, message queues, job logs, system history, database journals, and application logs.

The challenge is turning that information into something useful, searchable, alertable, and understandable.

A modern IBM i environment should make it easier to answer questions like:

• Which critical messages occurred overnight?
• Which jobs went into message wait?
• Which users accessed sensitive data?
• Which objects changed?
• Which integrations failed?
• Which API calls need attention?
• Which journal entries matter to the business?

The goal is not to erase the past

The goal of IBM i modernization should not be to erase the past.

The goal is to preserve the business value that already exists while improving the way teams build, integrate, secure, monitor, and support the platform.

RPG can continue to matter.
Db2 for i can continue to matter.
CL can continue to matter.
Green screens can continue to matter where they still serve the business.

But the ecosystem around them can become more modern, more automated, more secure, and easier to connect with the rest of the enterprise.

That is the real opportunity.

IBM i does not need to be treated like an old system waiting to be replaced.
It can be treated like a strong platform entering its next era.