Replacement programs for AS/400 applications fail in a recognizable way. The requirements phase produces a specification of what the business thinks the system does. Two years later the new system implements that specification correctly and the business discovers several hundred behaviors that were never written down, each of which someone depended on.
The cause is not poor project management. The cause is that the specification was never available. Thirty years of decisions about pricing, credit, allocation, and exception handling live in the programs and in the heads of a shrinking number of people, and a requirements workshop recovers a fraction of them.
That is the argument for incremental, API-first AS400 modernization services: they preserve the logic while it is being understood, rather than requiring it to be understood before anything can start.
Why the Encoded Rules Are the Asset
An AS/400 application that has run a business for three decades is a record of every decision that business made about how to operate.
Some of those decisions are obsolete and should be removed. Some implement regulation and must be preserved exactly. Some encode a commercial arrangement with a customer who still expects it. The ones that matter most are frequently the most obscure, because ordinary logic is remembered and exceptional logic is not.
Rewriting from a specification loses the third category systematically. The rules nobody could describe are the rules nobody wrote into the requirements, and they surface in production as complaints from customers whose invoices changed.
The scale of the untouched estate suggests this pattern is widespread. IBM’s material cites research from the IBM Institute for Business Value finding that 83% of executives called modernizing applications and data central to their strategy, while only 27% said they had actually modernized many of the necessary systems. Intent substantially exceeds completion, and abandoned replacement programs are part of the reason.
How AS400 Modernization Services Apply API-First in Practice
The core move is to separate the interface problem from the logic problem, and to solve the interface problem first.
Existing RPG and COBOL programs can be exposed as callable services, so a modern application, a mobile client, or an integration platform invokes the existing logic rather than reimplementing it. IBM’s own guidance describes this pattern of wrapping business logic as web services, alongside interface modernization and code refactoring, as the practical routes available.
Three consequences follow, and they are the reason the approach works.
The logic keeps running while everything around it changes. No rule is lost, because no rule is rewritten.
The estate becomes testable. A program exposed as a service can be called with defined inputs and its outputs compared against expectations, which is the foundation for every subsequent change. Green-screen-only programs are extremely difficult to test in isolation.
The business gets visible progress within a quarter. A modern interface over existing logic, or an integration that previously required a nightly file, delivers something people notice, which sustains funding for the less visible work.
Sequence the exposure by business value rather than by technical convenience. The programs worth wrapping first are the ones other systems most want to reach: customer lookup, order entry, inventory availability, pricing.
What IBM Application Modernization Services Should Deliver Per Increment
Judge each increment on whether it leaves the estate in a better position, not only on the feature it added.
- A defined service interface with documentation, versioned, so consumers can depend on it without depending on the underlying program structure.
- A regression test suite for the logic behind that interface, built from real historical inputs and outputs, which becomes permanent infrastructure.
- Extracted documentation of the business rules that program implements, including their origin where discoverable.
- A measurable business outcome, such as a process that got faster, an integration that stopped failing, or a manual step that disappeared.
- A reduction somewhere, whether dead code removed, a duplicate program retired, or a file no longer maintained.
Item two is the one that compounds. Once a body of logic has a regression suite built from real transactions, changing it becomes an ordinary engineering task rather than an act of courage. Teams that build the suite as they go find the fourth and fifth increments considerably cheaper than the first.
Item five deserves enforcement. Modernization programs tend to add without subtracting, and an estate that only grows becomes harder to modernize each year. Requiring a retirement per increment keeps the scope shrinking.
When an IBM i Modernization Company Should Recommend a Rewrite
Incremental is the default rather than a doctrine, and three situations genuinely justify replacement.
Where the underlying data model is fundamentally wrong for the current business, wrapping it preserves a constraint rather than an asset. A model that cannot represent a multi-currency subsidiary or a subscription product is not going to be fixed by an interface.
Where the business process itself is being redesigned, preserving the encoded rules preserves the old process, which defeats the purpose. This is a business decision rather than a technical one and should be made by the people who own the process.
Where a package genuinely fits, meaning the process is standard and the differentiation lies elsewhere, buying beats both rewriting and modernizing.
Even in those cases the rule extraction described earlier still pays, because a package evaluation or a redesign needs to know what the current system actually does. The knowledge work is common to every path.
An IBM i modernization company that recommends the same approach regardless of circumstance is selling a methodology. One that asks about the data model and the process redesign before recommending anything is doing the assessment.
Staffing the Program Against a Shrinking Pool
Incremental modernization runs for years, which makes the staffing question as important as the technical approach.
The team needs three capabilities that rarely sit in one person:
- Platform depth to read and expose the existing programs.
- Modern engineering practice to build the interfaces and test infrastructure.
- Business analysis to extract and validate the rules.
- Pairing across those skills works better than searching for individuals who hold all three. It also transfers knowledge in both directions.
The practical challenge is that experienced IBM i specialists are not always easy to replace or hire when a program needs them. A modernization effort that depends on bringing in several platform specialists mid-program is therefore exposed to a staffing constraint that can be difficult to resolve quickly.
Two practical responses help:
- Keep increments small. Design each increment so that a two-person pair can deliver it, limiting the number of specialists required at any one time.
- Build internal capability deliberately. Pair a platform-experienced person with a modern engineer on each increment, so the organization ends the program with more capability than it started with.
Where IBM application modernization services are bought externally, put the pairing arrangement in the contract rather than in the kickoff deck. Vendors optimize for delivery speed unless knowledge transfer is a stated deliverable, and a program that ends with all the understanding on the vendor’s side has moved the dependency rather than removed it.
Governance, Testing, and the Parts Auditors Ask About
Modernization touches systems that produce financial records, which brings obligations a pure technology project does not carry.
Establish equivalence explicitly. For each increment, run the old and new paths against the same historical inputs and reconcile the outputs, with the results retained as evidence. This is the artifact an auditor will request and the one that makes the internal argument for the next increment.
Keep the change record traceable. Which rule changed, who approved it, when it deployed, and what the reconciliation showed. A modernization program that cannot answer those four questions per change will consume weeks of the finance team’s time at year-end.
Security deserves attention as interfaces appear. Programs previously reachable only from a green screen behind the corporate network become callable services, and the authorization model has to be designed rather than inherited. Object-level authority on IBM i was frequently configured for interactive users, and exposing a program without revisiting it creates access nobody intended.
Two operational practices reduce risk during the transition. Run the new path in parallel with the old for a defined period before switching, comparing outputs continuously. And keep the ability to fall back for a stated window after each cutover, since the problems that matter surface during the first month-end rather than during testing.
Sequencing a Program That Survives a Budget Review
Incremental work has a commercial advantage worth exploiting: it produces something defensible every quarter.
Structure the program as a series of increments each with its own business case, its own outcome, and a decision point at the end. That structure survives leadership changes and budget cycles in a way that a two-year replacement plan does not, and it lets the organization stop after any increment with the value already delivered.
Budget conditions currently favor this kind of program. Gartner forecasts worldwide IT spending reaching $6.37 trillion in 2026, with IT services including application implementation and managed services exceeding $1.87 trillion. Funding for modernization is available; what fails scrutiny is a plan that asks for two years before showing anything.
Start with an increment that removes a visible operational pain, such as an integration that fails weekly or a report the business waits for. Follow with the interfaces other systems want most. Then work into the logic extraction and testability work, which is less visible and much easier to fund once the first two increments have built confidence.
Keep the documentation and regression assets in your own repository throughout. IBM i application modernization delivered as a series of vendor-held artifacts recreates the dependency the program was meant to reduce.
Where IBM i modernization is likely to run for several years, agree the standards once: how services are named and versioned, how tests are structured, and how rules are documented. Standards agreed at the start make increment seven look like increment two, which is what keeps the cost per increment from rising.
AS400 modernization services protect encoded rules by exposing existing logic through interfaces, building regression coverage as they go, and changing the estate incrementally rather than replacing it wholesale. Find a vendor that runs IBM i programs on that model, and teams weighing options can begin with an AS/400 modernization assessment. Take the program your other systems most want to reach and ask what it would take to expose it as a service this quarter.
