The real risk in IBM i modernization isn't the code; it’s pretending that rewriting decades of core business logic won't shake the organization. Disruption doesn't mean a project is failing; it means reality is catching up with your infrastructure. The executive challenge isn't avoiding friction altogether, but engineering controlled friction so daily operations never stall. 
 
Gartner's data backs this up: 

According to research by Gartner, fewer than 30% of "big-bang" legacy migrations finish on time and within budget, whereas incremental, phased modernization approaches (like the Strangler Fig pattern discussed below) yield an 84% completion rate. 

When organizations modernize their environments without preparing people for what might break or providing alternatives, things can go wrong fast. 

Modernization Without Disrupting Business

You don't tamper with code that still runs the payroll. Instead, insulate it: wrap the legacy core in an API layer, siphon off low-risk peripheral workloads like notifications and reporting, and leave billing and inventory untouched until the perimeter is stable.  

Take a system that handles billing, operations, and finance. Teams are reluctant to tamper with code that still runs the business. So you add APIs to connect new tools without changing the old business logic. 

In practice, this means putting an API layer in front of the old application, moving reporting and analytics first, and then replacing one business function at a time while the core system keeps running. Things like customer notifications, approval workflows, and integrations are often safer places to start than billing or inventory. 

A Mini Case Study - When Modernization Brings Business to a Halt

A large distributor of kitchenware and household goods supplied retailers across the eastern United States. Its operations were highly automated and closely integrated with its customers. 

Every night, the distributor received sales data from retailers, showing what each store had sold. Using stock levels, minimum order quantities, and the retailer’s selling prices, it automatically generated replenishment orders, printed and applied price stickers to every item, packed the goods, and delivered them directly to stores. 

Then the distributor built a new distribution center with more automation and new computer systems. When it switched over to the new setup, the system failed. 

Three weeks of silent inventory errors killed a multi-million-dollar supply chain. It wasn't an infrastructure failure; it was cutover arrogance. They assumed day-one parity because the demo worked. 
 
The key to modernization is to run the old and new components side by side for a full business cycle and compare the results before switching over. If something goes wrong, you can switch back quickly without disrupting daily operations. 

The Strangler Fig Approach

Strangler figs start growing in a nook of a host tree. As they grow, they draw nutrients from the host and send roots down to the ground while reaching for sunlight. Eventually, they become self-sustaining. The original tree may die, leaving the fig standing in its place, often shaped like the tree it replaced. 

Replacing old software without breaking it is often terrifying. 

In the past, companies often went for a “big bang” rewrite. They would spend years building a new system separately, then try to switch everyone over in one go. The problem? Legacy software carries decades of business rules, fixes, and exceptions that may never have been documented. Rebuilding everything from scratch means trying to get all of that right at once. Miss something, and things break.  
 
The Strangler Fig pattern takes a different approach. Instead of replacing everything at once, engineers do it in stages. 

• Put a routing layer in place: An API gateway or similar layer sits in front of the old system and directs requests to it. For users, nothing changes yet.

• Replace one piece at a time: The team picks a manageable function, such as customer billing, and builds a modern version alongside the existing one.

• Redirect requests: Once the new feature is tested and ready, the routing layer sends billing requests to the new service. Everything else continues to run on the old system. 
  The hard part isn't routing traffic - it's syncing legacy DB2 and modern PostgreSQL in real time without data drift.

• Repeat until the old system is no longer needed: The team gradually moves more functions to the new architecture, reducing the old system’s workload over time. \

Eventually, the old system has nothing left to do. Once all traffic has moved to the new services and the team has verified that nothing still depends on the original system, it can be retired. 

The advantage is straightforward. You modernize without forcing the entire business to switch over at once. Daily operations can continue while the underlying system changes. 

Conclusion - Modernization Is an Ongoing Business Decision

Successful IBM i modernization starts with knowing what you want to achieve, not simply deciding which technology to replace.  

Define the business outcomes first, then break the work into smaller, manageable parts that can be delivered and tested without putting daily operations at risk. 

Deliver each part successfully before moving on. But don’t stop there. Your organization also needs to change how it plans, funds, and delivers modernization. Otherwise, you risk treating it as a one-time project rather than an ongoing capability. 

The goal is to give the business room to evolve without putting the operations that keep it running at risk.

Plenty of companies still run on RPG applications built decades ago on IBM i. The code works, it handles orders and billing every day, and it rarely breaks. The problem is everything around it, because online stores, mobile apps and cloud tools all expect to connect quickly, and software designed in the 1990s was never built for that.

So the common fix is to put an API in front of it. That raises a fair question. Does connecting an old application make it modern, or does it just make its problems easier to see?

Why this stopped being a design question

In Fortra's 2026 IBM i Marketplace Survey, a shortage of IBM i skills became the industry's top concern at 69%, pushing cybersecurity out of first place after nine years. More than 60% of IBM i professionals are now aged 50 or above, and RPG is rarely taught in universities, so few people are arriving to replace them.

Here is why that matters. Putting a modern interface in front of RPG does not make the code behind it any easier for a new developer to work with, because the same small group of experienced people still has to maintain it. An API solves your connection problem, not your people problem.

What an API actually does here

Say your online store needs livestock levels. Instead of plugging into the old database, it sends a simple web request, the RPG program runs the same rules it always has, and the answer comes back in a format the store understands. Nothing inside the old system changes. Only the way other systems reach it changes.

There are two ways to set this up. IBM i can do it alone, because its Integrated Web Services server publishes existing programs as web services directly. Or you can add a gateway between logins, traffic limits, and logging. A lot of guidance assumes the gateway is compulsory, and it is not.

A modern front door does not change the house

An API gives a 30-year-old application a modern front door, but what sits behind that door is unchanged. Most long-lived RPG systems carry the same baggage: programs tangled together, so changing one thing breaks another, business rules that exist only inside the code, and no full map of what depends on what. Connecting more systems does not fix any of that. It puts it on display.

Here is a common example. A field gets updated by an overnight job, so on a green screen at nine in the morning it looks correct. When a live API asks for it at two in the afternoon, it returns yesterday's number. The flaw was always there. The API is simply the first thing that is noticed.

Four things an API cannot fix

These are the issues that turn a promising trial into a difficult live system.

• Old programs remember things; APIs do not. APIs expect every request to stand on its own, while many RPG programs assume they are partway through a conversation.

• Traffic behaves differently. If every call starts a brand-new job on the server, performance falls over as soon as volume picks up.

• Security gets flattened. IBM i controls access objects by object. If every API call runs under one powerful login, decades of careful control collapses into a single identity, and auditors will find it.

• Half-finished updates. If an API triggers several programs and one fails, the changes need to undo themselves cleanly, or your data quietly goes wrong.

Fixing these means tidying the code itself, not just wrapping it. The API modernizes access. Refactoring modernizes what is underneath.

When an API is enough on its own

Not every old system needs major surgery. The trouble is that "our code is hard to maintain" is a feeling, not a test, so these three questions are easier to answer honestly:

• Can someone tell you within a day exactly what a change to a core program would affect?

• Are there more than three people who could safely modify the programs your API would rely on?

• Have integration requests been postponed because nobody could estimate the work?

If the answers are reassuring, an API alone will probably serve you well. If they are not, it will publish a problem rather than solve one.

A simple plan that works

Take it in stages instead of attempting one giant rewrite.

1. Expose the parts that work well through APIs, where connecting them is the real need.

2. Clean up the code that is painful to maintain, converting old formats, splitting oversized programs, and moving to SQL.

3. Replace something only when keeping it no longer makes sense.

AI coding tools have become genuinely useful for step two, and IBM now offers one trained on IBM i specifics, which changes the cost of that work considerably.

Be careful who advises you, though. Most vendors recommend the approach their own product supports, so teams with long hands-on RPG experience who partner across the tooling market without reselling any of it tend to give straighter answers.

So, does it make the system modern?

It makes it reachable, which is not the same thing, and is often enough.

Thirty years of RPG does not mean thirty years of outdated technology. Those applications usually hold the logic that keeps the business running, and throwing that away creates risk you did not have before. The better question is not whether RPG is old, but whether the application can support where the business is heading, and whether enough people will still be able to change it when that direction shifts again.

Keep what still works. Fix what gets in the way. Replace only what has stopped earning its place.

Here is why the gap barely shrinks even when the technology improves. Onboarding is a shared job between two companies, and the timeline belongs to the slower side. Your team can cut its own work from three weeks down to three days, and the partner might still take six weeks to review specs, schedule testing, and give approval. You fixed your half of a process where the other half was never yours to control. 

Most conversations about faster onboarding skip that detail. The tools got better. The dependency did not. 

So it is worth looking at where the time actually goes. 

What Has Changed by 2026

Four important parts of the EDI onboarding job have moved forward. 

• AI helps with mapping. Software can read a partner's technical guide and suggest the connection rules instead of a developer writing every line by hand. It still needs a human check, but the first draft takes hours instead of days. 

• Networks are pre-connected. Many platforms already hold live links to hundreds of retailers and manufacturers. If your new partner sits on the same network, much of the setup is already done. 

• EDI and APIs run side by side. Teams no longer have to pick one, so a connection can start on whichever channel the partner already supports. 

• Compliance deadlines arrived. More e-invoicing mandates took effect in 2026 than in any year before it, across Europe, the Middle East, and Asia-Pacific. Belgium went live on 1 January 2026, Poland reached its largest taxpayers on 1 February, and France starts on 1 September, which is weeks away rather than quarters.

Now look at how those four fit into the workflow. 

Faster mapping and flexible APIs only help your side of the work. Networks are the only item that shortens the partner's side, because an existing link removes their need to review anything. The mandates speed up nothing at all. They remove the option of moving slowly. 

That explains why some companies see large gains while others see none. It depends more on whether your partners were already on your network than on which software you bought. 

What Still Slows Things Down

Delays come from two directions, and the split matters more than the list. 

Things you cannot control

• Partner rules. Every large buyer runs a unique rulebook with different formats, different mandatory fields, and different testing requirements. Better tools do not remove custom work. 

• The partner's schedule. They decide when someone reviews your work and opens a testing window.

Things you can control

• Messy data. Outdated product codes, missing fields, and mismatched SKUs. Many companies start onboarding before their own data is ready. 

• Customised ERPs. Heavy customisation makes clean data harder to extract. 

• Unclear ownership. Onboarding touches IT, sales, and operations at once, so tasks sit in inboxes with nobody accountable for the date.

The two collide during full testing, which runs from purchase order through to invoice and acknowledgement. 

When a test fails, you cannot simply try again tomorrow. You wait for the partner to offer another slot on their calendar. So a data problem does not cost the two days it takes to fix. It costs two days plus the four weeks until the partner looks at your file again. 

That multiplier is the gap between companies onboarding partners in days and companies still measuring it in months. Both bought good software. One arrived at the testing window with clean data. The other used the window to find its own mistakes. 

How to Move Faster

Different software will not fix the root issue. The partner holds the calendar, so the only lever you own is being ready before the window opens. 

• Clean data early. Fix product codes and close gaps while sales is still negotiating the contract. That work is cheap during commercial talks and expensive once the clock starts. 

• Assign one owner. One person responsible for the go-live date, with the authority to get answers out of IT, sales, and operations. 

• Treat the first test as the only one. Assume a failed test costs a month rather than a morning, and resource the preparation to match.

Every one of those happens before the partner is involved, which is exactly why they get skipped. 

The Bottom Line

A slow onboarding process is not a one-time cost. It repeats with every partner you add, and 2026 brings more partners plus deadlines that leave no choice about the connection. 

Which makes the useful question a fairly simple one. Does anyone own onboarding readiness before the next contract gets signed, or does it only become a problem afterwards?