Modernization

IBM Just Published Its Blueprint for Modernizing IBM i — Here’s What Actually Matters

IBM's new Modernizing IBM i Applications Redbook lays out a broad roadmap for modern IBM i development. Here are the practical takeaways for RPG, SQL, APIs, Git, DevOps, Node.js, security, testing, AI, and more.

Saurabh Arora

IBM i Solution Architect | Technical Lead | Modernization & Integration Specialist

Published September 1, 20269 min read

IBM has released a major new Redbooks publication focused entirely on modernizing IBM i applications.

And if there is one message that comes through clearly, it is this:

Modernizing IBM i does not mean rewriting everything.

That may sound obvious to some, but it is an important distinction.

For years, modernization discussions around IBM i have often been reduced to questions such as:

• Should we replace RPG?
• Should we move away from green screens?
• Should we rewrite the application in Java, .NET, or something else?
• Should we move everything off IBM i?

IBM’s latest guidance takes a much broader — and much more practical — view.

Modernization can happen across the entire application stack: architecture, RPG, Db2, interfaces, integration, development tools, source control, testing, security, deployment, open source, AI, and performance.

More importantly, IBM describes modernization as an iterative process, not a one-time transformation project.

Existing applications do not need to be discarded simply because newer technologies are available.

That is perhaps the most important takeaway from the entire publication.

1. Stop Starting With “We Need to Modernize”

One of the strongest ideas in the Redbook appears very early.

Instead of starting with:

How do we modernize our IBM i application?

start with:

What problem are we trying to solve?

That changes the conversation completely.

Maybe the real problem is:

• deployments take too long
• the application is difficult to integrate
• developers are afraid to change certain programs
• business logic is duplicated everywhere
• the database cannot easily be consumed outside the application
• new developers struggle to understand the code
• users need mobile access
• testing is mostly manual
• security controls need improvement
• too much knowledge exists with only one or two people

Those are modernization problems.

And they will not all have the same solution.

IBM’s guidance is clear that modernization should be driven by a real business or technical problem rather than by the desire to adopt newer technology for its own sake.

That means a successful IBM i modernization project might start with Git.

Or SQL.

Or an API.

Or refactoring one RPG program.

Or replacing one DDS physical file.

It does not necessarily start with a massive rewrite.

2. Modernization Is Bigger Than the User Interface

For many organizations, modernization historically meant one thing:

Replace the green screen.

A modern interface can certainly improve usability, reduce training requirements, and make applications available on mobile and web platforms.

But changing the interface does not automatically modernize the application underneath it.

You can put a modern web interface in front of a difficult-to-maintain architecture and still have a difficult-to-maintain architecture.

IBM’s Redbook treats modernization as something that can occur at every layer — from the database and business logic all the way to integration, tooling, security, deployment, and the user interface.

That distinction matters.

A truly modern IBM i application may combine:

Modern UI
    ↓
REST APIs
    ↓
Reusable business services
    ↓
Modern RPG / Node.js / SQL
    ↓
Db2 for i

The green screen is only one part of the picture.

3. RPG Is Not the Problem

One conclusion we take from the Redbook is that RPG itself is not the modernization problem.

IBM’s guidance does not frame modernization as automatically replacing RPG. Instead, it shows how existing IBM i applications can evolve through modern RPG techniques, modularity, SQL, APIs, open source, and modern development practices.

Modern RPG looks very different from RPG written decades ago.

Today we have:

Fully free-form RPG
Procedures
Modules
Service programs
Embedded SQL
Modern development environments
Git
Automated builds
APIs
Testing

The bigger modernization opportunity is often architectural.

Consider an application containing thousands of lines of code in a single RPG program.

That program might:

Validate input
Read files
Apply business rules
Calculate prices
Write orders
Send messages
Call external services
Format a screen

Instead of rewriting the entire application in another language, one practical modernization approach could be to separate responsibilities. For example:

Order Entry
    ↓
Validation Service
    ↓
Pricing Service
    ↓
Order Service
    ↓
Integration Service

Those services may still be written in RPG.

But now they can potentially be reused by:

5250
Web applications
Mobile applications
REST APIs
Batch programs
Partner integrations

That is modernization.

4. Your Database Is Part of the Application

Database modernization is one of the most important — and sometimes overlooked — parts of the Redbook.

Many IBM i applications still depend heavily on DDS physical and logical files.

Modern Db2 for i development allows us to take advantage of SQL DDL and database capabilities that can move responsibilities traditionally handled only by application code closer to the data itself.

This is much more than replacing:

CRTPF

with:

CREATE TABLE

Modern Db2 allows us to define rules directly in the database using capabilities such as:

PRIMARY KEY
FOREIGN KEY
UNIQUE
CHECK
IDENTITY

Along with features including:

Temporal tables
Row and Column Access Control
JSON
XML
Stored procedures
Functions
Views
Triggers
Commitment control
Journaling

One particularly important idea is data integrity.

If validation exists only inside an RPG program, another application can potentially update the database directly and bypass those rules.

Putting appropriate integrity rules into Db2 protects the data regardless of which application performs the update.

That leads to an important modernization principle:

The application should not be the only thing protecting the database.

5. SQL Is Becoming a Core IBM i Development Skill

Modern IBM i development increasingly requires strong SQL skills.

Not simply:

SELECT *
FROM MYFILE;

but understanding how to use Db2 as an application platform.

For an IBM i developer, that broader SQL skill set can include capabilities such as:

Set-based processing
SQL services
Views
Stored procedures
Functions
MERGE
Common table expressions
Window functions
JSON
Database constraints
Modern indexing
Performance analysis

Not every item in that list is presented by the Redbook as a standalone recommendation; rather, these are practical examples of the wider SQL and Db2 skill set that supports the direction IBM describes.

There is an important mindset shift here.

Traditional RPG applications often process data one record at a time:

READ
process record
READ
process record
READ
process record
...

Modern SQL encourages us to ask:

Can Db2 perform this operation as a set instead?

Sometimes the difference can be dramatic — not only in code size, but also in maintainability and performance.

This is why SQL is no longer simply a database skill for IBM i developers.

It is an application-development skill.

6. APIs Are Becoming Part of the Architecture

Modern applications rarely exist in isolation.

IBM i applications increasingly need to communicate with:

CRM platforms
E-commerce systems
Mobile applications
Cloud services
Payment providers
Partner systems
Analytics platforms
AI services

REST APIs and web services have become important mechanisms for exposing IBM i business functionality to other platforms.

But there is an important architectural difference between:

adding an API

and:

designing application services that can be exposed through APIs

Imagine an RPG program where pricing logic is deeply tied to a display file.

Exposing that program directly as an API may work, but it does not necessarily make the architecture modern.

A more reusable architecture might look like this. This is an Era of i example of how the Redbook’s modularity and service-oriented ideas can be applied:

5250 Application ───┐
                    │
Web Application ────┼──→ Pricing Service → Db2
                    │
REST API ───────────┘

Now the business capability is reusable.

The API becomes one interface to the business logic rather than the business logic itself.

That distinction becomes increasingly important as IBM i applications interact with more systems.

7. Open Source Belongs on IBM i

Another major theme in the Redbook is the use of open-source technologies alongside traditional IBM i languages.

That includes technologies such as:

Node.js
Python
PHP
Java

This does not mean RPG disappears.

It means IBM i developers can choose the right tool for the right problem.

You might have:

RPG
→ core business processing

SQL
→ data access and transformation

Node.js
→ REST APIs and web applications

Python
→ automation, data processing, or AI workloads

All working with the same IBM i platform.

For organizations with decades of proven RPG business logic, this is particularly powerful.

You do not necessarily need to rewrite that logic.

You can build around it.

8. Git and DevOps Are No Longer “Open Systems Things”

This is an area where IBM i development continues to change rapidly.

Source control, Git, DevOps, CI/CD, automated testing, and automated deployment are increasingly part of the IBM i modernization conversation.

For many IBM i shops, the traditional lifecycle may still look something like:

Edit source member
    ↓
Compile
    ↓
Test
    ↓
Move object

A modern workflow begins to look more like:

Change source
    ↓
Commit to Git
    ↓
Code review
    ↓
Automated build
    ↓
Automated tests
    ↓
Controlled deployment

But simply putting RPG source into Git is not the end goal.

There are additional questions:

• How do branches map to DEV, UAT, and PROD?
• How are objects compiled?
• How are dependencies handled?
• How do we prevent direct production changes?
• How do we build only changed objects?
• How do we roll back?
• How do we validate a build before promotion?

That is where IBM i DevOps becomes interesting.

Git is only the starting point.

9. Security Has to Be Designed In

As IBM i applications become more connected, security becomes even more important.

Modernization introduces new capabilities:

REST APIs
SSH
Git
Node.js
Open source packages
Web applications
External integrations

But each new capability also expands the security surface.

Modern IBM i development therefore needs to think about:

Least privilege
Authentication
Authorization
Encryption
Auditability
API security
Database security
IFS permissions
Dependency security
Secrets management

The goal should not be:

Build it first. Secure it later.

This is consistent with IBM’s Secure by Design direction: security should be considered as part of the modernization design itself, not added only after the application is built.

10. Testing Needs to Become Normal

One of the quieter but extremely important areas IBM covers is automated testing.

Many IBM i environments still depend heavily on manual testing.

A developer changes a program.

Someone runs through a few transactions.

If everything looks right, the change moves forward.

That process becomes increasingly risky as systems grow more interconnected.

Modern application architectures benefit from being testable.

And testability itself encourages better design.

Consider this tightly coupled structure:

Screen
 ↓
Business logic
 ↓
Database

Everything happens inside one program.

Compare that with:

UI
 ↓
Business procedure
 ↓
Data service

Now individual pieces can potentially be tested independently.

Eventually, the development lifecycle can evolve toward:

Git push
    ↓
Compile
    ↓
Unit tests
    ↓
Integration tests
    ↓
Deploy

That is a significant change for many IBM i teams — but one that can dramatically increase confidence in application changes.

11. AI Is Entering the IBM i Development Lifecycle

IBM also dedicates significant attention to artificial intelligence and IBM Bob.

The Redbook discusses AI-assisted development in areas such as:

Code understanding
Documentation
Code generation
Testing
Code review
Modernization analysis
Developer productivity

Beyond the Redbook’s discussion of AI-assisted development, there is also a broader architectural question worth exploring at Era of i:

How should AI assistants safely interact with IBM i capabilities?

One possible pattern we may explore in future articles is:

AI Assistant
     ↓
Controlled, narrowly defined tools
     ↓
IBM i
     ↓
Db2 / RPG / system services

That diagram is our architectural interpretation, not a prescribed IBM Redbook design.

If AI is allowed to interact with IBM i, security and governance become critical. Unrestricted access to SQL, CL commands, files, programs, or system configuration would create obvious risk.

The more useful question is therefore not simply whether AI can interact with IBM i, but how those capabilities can be exposed safely, narrowly, and audibly. That is a topic we expect to explore further at Era of i.

So What Does a “Modern IBM i Developer” Look Like?

Perhaps the biggest takeaway from IBM’s Redbook is that the IBM i developer role itself is evolving.

It is no longer enough to think only in terms of one programming language.

A modern IBM i developer increasingly works across:

RPG
+
SQL
+
APIs
+
Git
+
Automation
+
Security
+
Open source

You do not have to become an expert in everything overnight.

And that is really the point.

Modernization is not a destination.

It is a series of improvements.

Maybe today you move one project into Git.

Tomorrow you replace an RPG record-processing loop with set-based SQL.

Next month you expose a reusable business procedure through an API.

Later you introduce automated testing.

Eventually you build a Node.js application that calls existing RPG services.

Each step improves the application without throwing away the investment that already exists.

Where Era of i Goes From Here

IBM’s new modernization Redbook provides an excellent blueprint for where IBM i development is heading.

But a modernization guide of this scale can also leave you with another question:

Where do I actually begin?

That is where we want Era of i to help.

Over the coming months, we are going to take many of these modernization concepts and break them into small, practical lessons that you can understand, run, experiment with, and apply on a real IBM i.

We will explore topics including:

IBM i: The SQL Way
Modern RPG architecture
Node.js on IBM i
Git and DevOps
REST APIs
Testing
Security
Performance
AI and IBM Bob

Not modernization as a massive transformation project.

Modernization one practical step at a time.

Because the future of IBM i does not require abandoning everything that came before it.

It requires making the incredibly valuable applications already running on the platform easier to understand, integrate, maintain, test, secure, and extend.

IBM tells us what modern IBM i can look like.

At Era of i, we want to show how to actually build it.

Reference

IBM Redbooks — Modernizing IBM i Applications (MD260020)
https://www.redbooks.ibm.com/docs/pdfs/MD260020.pdf