The conversation around IBM i/AS400 modernization often starts with a conclusion. The platform is considered outdated, skilled resources are difficult to find, and the future is assumed to lie elsewhere. From there, the discussion quickly moves to a replacement plan.    

Some of those concerns may be valid. The problem is that the replacement plan is often priced around where the organization wants to go, without fully considering what it would lose by leaving the existing platform.     

That does not mean organizations should leave IBM i unchanged. AS400 modernization is not about postponing a difficult decision. It is about recognizing that modernizing AS400 and replacing AS400 are two different decisions, with different costs, risks, and business cases. Treating them as the same decision can lead an organization toward the more expensive option before it has properly assessed the alternatives.     

AS400 Modernization Offers Three Options, Not Two 

Upgrade, Modernize, Replace 

Upgrading moves you to a supported release and changes nothing about how the application works, which is why it is rarely what IBM application modernization services quote for. Modernizing keeps the application and changes how it is reached, extended, and maintained: interfaces, APIs, database access, development practice. Replacing rebuilds the business logic on another platform. Three budgets, three risk profiles, three sets of things that can go wrong. 

Most iSeries modernization proposals present a binary. Once you separate the three, the sequencing question becomes obvious, because upgrading is a prerequisite for either of the others and modernizing is reversible in a way that replacing is not.  

What the Replacement Case Leaves Out 

The Integrated Stack 

One reason IBM i can be difficult to compare with another platform is that several capabilities are already integrated into the environment. 

Db2 for i is part of the operating system. The same applies to the security model, job scheduler, and object-level authority structure. On another platform, these capabilities may become separate products, each with its own administration, licensing, and maintenance requirements. 

That does not mean moving away from IBM i is the wrong choice. It means these differences need to be included in the comparison. A business case that focuses only on the destination can miss some of the costs of getting there. 

The Specification You Do Not Have 

A rewrite requires a clear specification. In many IBM i environments, much of that specification already exists inside decades of RPG code. 

Before a replacement application can be built, teams need to extract those business rules, validate them, and turn them into something the new system can use. That can be difficult when the people who originally understood the application are no longer available. 

This is often where rewrite projects lose time. The coding itself may not be the hardest part. Understanding what the existing application does is.  

Operational Cost After the Move 

IBM i environments can be inexpensive to operate. They may run for long periods with limited intervention and relatively small operations teams. 

That operating model has value. Once the application moves to another platform, some of that value disappears. The new environment may require different skills, tools, administration, and support. 

Those costs should be part of the comparison from the beginning. Looking only at license costs does not give a complete picture.  

The Second Migration 

The destination also needs closer examination. 

IBM i requires IBM Power hardware, so it does not simply move onto standard cloud compute. Microsoft documents an option for keeping IBM i workloads intact by running Power capacity inside Azure data centers. That is different from rewriting the application for another platform. 

The distinction matters because an organization may discover that it has more than one way to move toward its cloud strategy. Finding that out after the replacement business case has already been approved limits the choices available. 

The Platform Is Not Standing Still 

The argument for replacement often assumes that IBM i has no meaningful future. That claim needs to be separated from the much more straightforward requirement to keep the platform current. 

IBM made IBM i 7.6 generally available in April 2025 on Power10 and Power11. Its enhancement notes include native multifactor authentication and database changes that require the new release. IBM has also set September 30, 2026, as the end of standard support for IBM i 7.4, with paid Service Extension available after that. 

The takeaway is not that IBM i can be left untouched. Release currency remains an ongoing responsibility. But that is different from saying the platform itself is being abandoned. 

How to Decide Whether to Modernize AS400 or Replace It 

The decision becomes easier when it starts with evidence rather than assumptions. Four questions are particularly useful. 

1. What can the business not do today? 

Be specific. Then determine whether the problem comes from a limitation in the platform or from the way the application was designed. In many cases, the application is the constraint rather than IBM i itself. 

2. What actually runs? 

Build a live inventory using job and call data. The applications and programs that appear in source code are not necessarily the ones still being used. Knowing what runs can change the cost and effort involved in any modernization or replacement plan.  

3. Who understands the system, and for how long? 

Knowledge is a constraint regardless of which path you choose. That makes it important to capture business rules and application knowledge early. 

4. What does the commercial software you depend on support? 

Third-party dependencies can change the decision. If a critical software vendor has ended support for IBM i, the organization may have a fixed timeline that it cannot control.    

When these questions are answered properly, an IBM application modernization services engagement often leads to a sequence rather than a single choice: bring the platform up to date, capture the business rules, modernize the access layer, and then reassess the longer-term direction. 

An iSeries modernization engagement that starts with a recommendation instead of an inventory is making a recommendation about a system that has not yet been properly understood.  

When Replacement Is Right  

Replacement can be the right decision. A credible modernization strategy should be clear about when that is the case. 

• Application Fit: If the business has changed so much that the existing application needs to be redesigned rather than modified, a rewrite may make more sense. In that situation, the platform decision follows the need to redesign the application. 

• Dependency: If a critical software package has ended IBM i support, the organization may no longer control the timeline. 

• Scale: If IBM i now supports only a small number of peripheral applications, continuing to maintain the platform and its specialized skills may no longer be practical. Consolidation can be reasonable even when it involves a significant one-time investment. 

The important point is that replacement should follow from the business and technical evidence. It should not be the default simply because the platform is older.  

Frequently Asked Questions 

Is AS400 Modernization Just a Screen Refresh? 

No. A screen refresh is only the most visible part of modernization. 

A broader iSeries modernization services engagement can include exposing existing functions through APIs, improving database access, moving code toward free-form development where changes are being made, and establishing current development and deployment practices. 

The user interface is easy to see, but it is not necessarily the most important part of the modernization effort. 

How Long Does a Rewrite Take? 

The amount of code is only part of the equation. A bigger factor is how well the business logic is understood and documented.  

When rules have already been extracted and validated, the work is easier to plan. When they have not, the early stages of the project become an exercise in discovering requirements. 

That is why estimates given before an application inventory exists should be treated carefully. The team may not yet know what it is actually being asked to rebuild. 

Can We Modernize and Migrate Later? 

Yes. In many cases, this is the lower-risk sequence. 

API enablement, business rule extraction, and interface modernization can make a later migration easier because they help create the specification a replacement project would need. 

If the organization eventually decides to leave IBM i, much of this work can still be useful. 

What Should an IBM i Modernization Company Deliver First? 

The first deliverables should help the organization understand what it has and what needs attention. 

That means a live application inventory, a documented set of business rules for important functions, and a plan for keeping the IBM i release current, including dates and costs. 

These deliverables remain useful regardless of whether the eventual decision is to modernize, migrate, or replace.   

Does Staying on IBM i Create an Audit Problem? 

Not necessarily. 

IBM i provides a granular authority model, and the 2025 release added native multifactor authentication. Before replacing or modernizing AS400 for audit reasons, organizations should identify the actual source of the audit concerns.   

Problems often come from accumulated user profiles, excessive permissions, or outdated change processes. These issues can be addressed without necessarily changing platforms. 

The strongest case for modernizing rather than replacing is unglamorous: you keep a working, supported system and spend your budget on the parts that are holding the business back. Trusted AS400 modernization services start with the inventory, because the evidence usually narrows the decision considerably.