Why IBM i Still Matters: Modernizing the Platform Behind the Business
For many organizations, some of the most important systems in the business are also the systems people rarely talk about.
They process orders. They manage inventory. They support financial operations. They move data between applications. They run batch processing overnight and make sure the business is ready when employees arrive the next morning.
And in many companies, those systems run on IBM i.
That is one of the reasons I continue to believe strongly in the future of the platform. IBM i has earned its reputation for reliability and stability, but stability should not be confused with standing still.
The opportunity in front of us is not simply to preserve IBM i applications.
It is to modernize them while retaining the strengths that made the platform valuable in the first place.
Modernization Does Not Have to Mean Replacement
When modernization discussions begin, there is sometimes an assumption that a modern system must be a new system.
I don't believe that is necessarily true.
Many IBM i applications contain decades of accumulated business knowledge. The code represents countless decisions about how an organization operates, how exceptions are handled, how customers are served, and how critical processes interact.
Replacing all of that simply because an application is considered "legacy" can introduce tremendous cost and risk.
A better question is:
How do we modernize the way we build, maintain, integrate, and understand these applications?
That changes the conversation considerably.
Modernizing IBM i can include improving RPG structure, increasing the use of SQL, creating clearer service boundaries, adopting modern source control, improving automated testing, and providing developers with contemporary development environments.
None of those changes require abandoning the platform.
Modern RPG Is Still RPG
One of the biggest misconceptions about IBM i development comes from people whose picture of RPG was formed many years ago.
Modern RPG looks very different.
Free-format RPG gives developers code that is easier to read and maintain. Procedures and service programs make it possible to organize applications into reusable components. SQL provides powerful capabilities for working with Db2 for i without writing large amounts of procedural database logic.
Development environments are evolving as well.
Tools such as Visual Studio Code and Code for IBM i make it possible for IBM i developers to work in an environment that feels familiar to developers coming from other platforms.
Git-based source control introduces workflows that are already standard throughout much of the software industry.
These changes matter for existing developers, but they may matter even more for the next generation.
If we want new developers to see IBM i as a viable platform, we should give them development practices and tools that resemble what they have already learned elsewhere.
AI Creates Another Modernization Opportunity
Artificial intelligence introduces another interesting chapter in the evolution of IBM i development.
Tools such as IBM Bob have the potential to help developers understand applications, explore unfamiliar code, document systems, assist with development tasks, and accelerate modernization work.
For mature IBM i environments, this could be particularly valuable.
Many organizations have applications that have been evolving for twenty, thirty, or even forty years. The original developers may no longer be available, documentation may be incomplete, and understanding how a business process flows across programs can require significant effort.
AI-assisted development can help reduce some of that friction.
But I believe the greatest value will come when AI is combined with strong engineering practices.
AI does not eliminate the need for architecture standards, code reviews, source control, testing, security controls, or experienced developers.
It can amplify them.
That distinction will be important as IBM i organizations begin adopting AI more broadly.
The Skills Challenge May Be Bigger Than the Technology Challenge
Technology is only part of the modernization equation.
The IBM i community also faces a workforce challenge.
Many experienced RPG developers have spent decades building and supporting these systems. At the same time, organizations need to bring new engineers into the ecosystem.
That knowledge transfer cannot happen accidentally.
We need deliberate approaches to:
- teach modern RPG development practices;
- introduce developers to Db2 for i and SQL;
- explain how IBM i applications interact with the rest of the enterprise;
- create mentoring opportunities between experienced and newer engineers;
- document business knowledge that may currently exist only in people's heads;
- expose developers to Git, APIs, automation, AI-assisted development, and modern tooling.
The goal should not be to create developers who only know how things were done twenty years ago.
It should be to develop engineers who understand why IBM i works so well while also knowing how to build for its future.
Modernization Is a Journey, Not a Conversion Project
One lesson I have learned from working with IBM i systems for more than three decades is that large-scale change rarely happens all at once.
The most sustainable modernization efforts tend to be incremental.
Improve one development standard.
Modernize one module.
Replace one outdated interface.
Move one workflow into Git.
Introduce one new SQL technique.
Document one critical business process.
Train one new developer.
Then repeat.
Over time, those improvements compound.
That is why I think the future of IBM i is less about choosing between "legacy" and "modern" and more about continually moving the platform forward.
The Backbone Can Evolve
IBM i continues to quietly run critical parts of businesses around the world.
That reliability is not something we should apologize for.
It is something we should build upon.
The challenge for those of us who work with the platform is to make sure the applications running today are also positioned for tomorrow.
That means modernizing IBM i development practices, investing in the next generation of engineers, adopting tools that improve productivity, and using technologies such as AI where they genuinely make engineering better.
The backbone behind the business does not need to disappear.
It needs to evolve.
About the author
George VanEaton is a Manager, Product Development and IBM i technologist with more than 30 years of experience working with RPG, Db2 for i, application architecture, modernization, and enterprise software development. His current interests include IBM i modernization, AI-assisted software development, engineering leadership, and developing the next generation of IBM i developers.