Why IBM i Isn't the Legacy Problem You Think

IBM i is often treated as the modernization problem.  

Executives hear “AS/400,” “RPG,” or “legacy platform” and assume the answer is replacement. But the platform itself is rarely the entire constraint.  

The bigger issues are often aging integrations, undocumented business logic, fragmented data, and shrinking pools of specialized skills.  

IBM continues to support IBM i and invest in modernization capabilities, including modern RPG, SQL, APIs, and development tooling. The question is therefore not simply whether IBM i is old. It is whether the environment around it is preventing the business from changing fast enough.  

 Is IBM i Really the Problem?  

A platform can be decades old and still reliably run critical transactions. 

 What makes an IBM i environment difficult to modernize is often everything surrounding the core: 

• Batch-dependent integrations 

• File-based data exchanges 

• Undocumented business rules 

• Point-to-point interfaces 

• Manual reconciliation 

• Dependence on a few experienced RPG developers  

The distinction matters. The platform may be stable while the architecture around it has aged.  

Where Does the Real Bottleneck Sit?  

If launching a new digital service requires weeks of custom integration with IBM i, the integration layer may be the problem.  

If every application change depends on one developer who understands decades-old code, the skills model is the problem.  

If critical customer data remains locked in batch processes, data access is the problem.  

Replacing the core does not automatically fix any of these.  

Why Isn't Rip-and-Replace Always the Answer?  

A wholesale migration can replace old technology without eliminating old complexity.  

Consider an application containing hundreds of undocumented business rules. Rewriting it in a modern language does not make those rules disappear. Unless the organization understands which rules are essential, obsolete, or historical workarounds, the new application simply reproduces the same complexity.  

Migration also introduces risks around data conversion, functional parity, integrations, security, and operational continuity.  

Replacement can absolutely be the right choice. But it should be driven by a clear business case, not by the age of the platform.  

What Does IBM i Modernization Look Like Without Replacing the Core?  

Modernization can happen incrementally.  

Modernize the Integration Layer  

APIs and reusable services can expose IBM i capabilities to cloud applications, SaaS platforms, mobile experiences, and analytics tools without forcing every new system to understand the underlying core.  

IBM i can continue running the transaction while modern integration makes that transaction accessible.  

Modernize Applications Selectively  

Not every RPG application needs a rewrite. Modern RPG, SQL, modularization, refactoring, and better development practices can improve maintainability while preserving proven business logic.  

The goal is to modernize the capability, not simply translate old code into a new language.  

Modernize Data Access  

Organizations do not necessarily need to move every record off Db2 for i. A better approach is to establish governed access based on who needs the data, what they need, and how quickly they need it.  

How Big Is the IBM i Skills Problem?  

Skills may be a greater immediate risk than the platform itself.  

When experienced RPG developers retire, organizations can lose knowledge about business rules, dependencies, exception handling, and operational processes that was never formally documented.  

That makes modernization an opportunity to capture knowledge while expanding the skills around IBM i.  

Modern IBM i teams increasingly need expertise in SQL, APIs, cloud integration, automation, DevOps, security, and modern development practices, alongside RPG.  

What Should Managed Services Actually Do?  

AS400 managed services should do more than keep an aging environment running.  

A strong model should improve monitoring, documentation, automation, knowledge transfer, and operational resilience while the organization modernizes.  

The objective is to reduce dependency over time, not simply outsource it.  

When Should IBM i Actually Be Replaced?  

Replacement makes sense when the platform or its dependencies genuinely prevent the business from meeting its requirements.  

That could include: 

• Unsupported or obsolete software 

• Security or compliance limitations 

• Severe scalability constraints 

• Unmanageable operating costs 

• Inability to support required integrations 

• A business strategy fundamentally incompatible with the existing architecture 

 The decision should answer one question: 

 What measurable business outcome will replacement deliver that modernization cannot?  

If the answer is unclear, ripping out the core may be premature.  

What Should Executives Ask Before Modernizing IBM i?  

Instead of asking when the organization can get rid of IBM i, ask:  

What is IBM i preventing us from doing today?  

Then examine the surrounding environment.  

Where are integrations slowing change? Which applications depend on undocumented knowledge? Where is data inaccessible? Which processes remain manual? Which workloads genuinely need modernization?  

From there, organizations can classify workloads into four categories:  

• Stabilize: Improve security, monitoring, support, and operations. 

• Connect: Modernize APIs, integrations, and data access. 

• Refactor: Improve applications creating the greatest maintenance burden. 

• Replace: Migrate workloads where there is a clear business and technical case.  

This creates a modernization roadmap based on value and risk rather than technology fashion.  

 Where Do AS400 Services Fit? 

 Organizations looking for IBM AS400 services increasingly need more than traditional maintenance.  

They need partners that understand the existing environment while knowing how to modernize what surrounds it.  

That means combining IBM i and RPG expertise with integration, APIs, cloud connectivity, data modernization, automation, security, and managed operations. 

 The right partner should not begin with:  

“How quickly can we remove IBM i?”  

It should begin with:  

“What should stay, what should change, and what should eventually go?”  

The Real Legacy Problem Is Often Around IBM i  

IBM i is not automatically a business liability because it is old.  

The real risk is allowing aging integrations, undocumented logic, inaccessible data, and skills gaps to become permanent constraints.  

Modernization does not have to mean replacing everything.  

Sometimes the smarter strategy is to preserve the stable core, modernize the interfaces around it, improve data access, capture institutional knowledge, and replace only what genuinely needs to go.  

That is a more nuanced approach to AS400 services and IBM i services: not defending the past, but making better decisions about what the business actually needs to change.