It usually starts with a reasonable decision. The RPG applications are old, the developers who built them are nearing retirement, and a new platform promises a clean slate. Leadership approves the budget. A timeline gets drawn up. Everyone agrees this is the responsible thing to do.
Eighteen months later, the new system is still not ready. The original scope has grown. The old applications are still running the business, because they have to.
And someone in a steering committee meeting finally asks the question nobody wanted to ask: should we keep going?
Many of these projects never announce their failure. They simply stop, and the organization goes back to the system it was trying to leave, having spent the budget and lost the time.
This pattern is common enough across enterprise IT that it has been measured. And IBM i organizations are, for specific reasons, more exposed to it than most.
The Numbers Behind the Pattern
The largest study of its kind was published in 2025 in the Project Management Journal. A research team led by the University of Oxford compared cost overruns across more than 11,000 projects in 23 categories, from roads and rail to nuclear power and the Olympics. Their finding was stark: IT projects carry more extreme cost risk than any other project type studied, including nuclear waste storage.
The shape of that risk matters. The majority of IT projects in the dataset came in on or under budget. But roughly 18% overran by more than 50%, and those projects averaged an overrun of 453%. The danger is not that every project runs a little over. It is that a meaningful share become something several times more expensive than anyone approved.
Earlier research from McKinsey and Oxford points to one of the biggest drivers. In a study of more than 5,400 IT projects, researchers found that every additional year a project is scheduled to run increases cost overruns by 15%. The same study described a large retailer that abandoned a $1.4 billion effort to overhaul its IT systems, then launched and lost a second $600 million project before filing for bankruptcy.
The lesson is consistent across more than a decade of research: the bigger and longer the bet, the worse the odds.
Why IBM i Replacements Are Especially Exposed
Every large IT project carries risk. Replacing mission-critical RPG applications adds four specific pressures that make the typical failure pattern more likely.
The Business Rules Nobody Wrote Down
Decades of RPG code contain decisions that were never documented anywhere else. A pricing exception for one customer. A tax calculation adjusted for a regulation that changed in 1998. An inventory rule someone added after a bad quarter. These rules are the business, and in many organizations they exist only in source code and in the memory of a few veteran developers.
A replacement project has to find every one of them, understand why it exists, and rebuild it correctly. The ones that get missed do not show up in a demo. They show up in production, in the first month-end close on the new system.
The Target Keeps Moving
The business does not pause while a replacement is built. Change requests keep arriving, and each one forces a choice: implement it in the old system, the new system, or both. Implementing in both doubles the work. Implementing in one creates a gap. Over an 18 to 24 month build, those gaps accumulate until the new system is chasing a version of the business that no longer exists.
The Cutover Nobody Will Sign
Big-bang replacements end with a single moment when the old system is switched off and the new one takes over. For applications that run order processing, invoicing, and overnight batch jobs, that moment carries enormous risk. The closer it gets, the more cautious stakeholders become, and the more the go-live date slides.
The Experts Are Already Stretched
The people who understand the old system best are the people a replacement project needs most, to explain the logic, validate the new build, and support the cutover. They are also the people keeping production running. On IBM i teams, that is often a very small group, and a replacement project asks them to do two full-time jobs at once.
What One Failed Replacement Looked Like
A leading UK textile rental and laundry services provider, operating 16 plants across the country, lived this pattern directly. As described in the case study, the company spent 16 to 18 months implementing a third-party system meant to replace its RPG applications, then made the difficult decision to abandon it and return to the applications it already had.
That left the company with an urgent mandate and very little room to work. It had six months to deliver a modern experience across all 16 plants. Only two members of its IT team could read and maintain RPG. And its overnight batch processing and invoicing could not be interrupted for a single day.
Instead of attempting a second replacement, the company futurized what it already had using Profound AppDev, rolling out in phases rather than all at once. The result was delivery across all 16 plants within the six-month deadline, 100% uptime for mission-critical batch processes and invoicing throughout the transformation, and decades of refined RPG business logic fully preserved.
The contrast is the point. The same organization, with the same team and the same applications, went from an abandoned 18-month replacement to an on-time, six-month transformation. What changed was not the people or the platform. It was the approach.
The Alternative Is Not Standing Still
When a replacement fails, the tempting conclusion is that the only safe option is to leave everything alone. That conclusion is just as costly, only slower. The skills gap keeps widening, the backlog keeps growing, and the business keeps waiting on changes it needed last year.
The organizations that avoid both outcomes take a third path: Futurization™, our unique methodology for building new capability on top of proven IBM i applications instead of replacing them. Rather than one large bet with a single cutover, Futurization breaks the work into increments that each deliver value on their own.
The same 2025 study that documented IT’s extreme cost risk also pointed to an antidote. The researchers found that the riskiest project types tend to be bespoke, built as one-of-a-kind efforts, while the lowest-risk types are modular, assembled from many small, repeatable units. Building big things from small ones is a close description of how Futurization works.
That approach directly addresses the failure patterns above.
The Cutover Nobody Will Sign
he RPG logic that runs the business keeps running. Nothing has to be rediscovered and rebuilt from scratch before the organization can move forward.
The target stops moving
Because each increment is small, change requests do not accumulate into a gap between two systems. The business and the application evolve together.
There is no single cutover
Coexistence architecture lets futurized and existing programs run side by side, so change rolls out program by program and site by site. If one increment needs adjustment, the rest of the business is unaffected.
Value arrives early
Instead of waiting two years for a go-live, the organization sees results from the first increment. Given McKinsey’s finding that every additional year of project duration adds 15% to cost overruns, keeping increments short is not only faster. It is lower risk.
Ryder shows what this looks like when the goal is new capability rather than recovery. As its case study describes, the company used Profound.js, a component of Profound AppDev, to build a new web and mobile application for its freight operations while continuing to rely on its existing RPG business logic. The results included an average 1.1-day reduction in delivery cycle times, service-to-invoicing time cut from 48 hours to 24, roughly $30,000 in annual savings, and 10 fewer person-hours of manual effort per week at each site. None of that required replacing the applications underneath.
Where Agentic Futurization Changes the Math
The incremental approach has always been lower risk than replacement. The historical trade-off was speed. Futurizing program by program took sustained effort from exactly the developers who were already in short supply.
That is the constraint Agentic Futurization, powered by CoderFlow is designed to remove. CoderFlow’s AI agents work inside your own environment on real IBM i tasks: building new web interfaces, converting fixed-format RPG to free-format, refactoring record-level access to SQL, and documenting what programs actually do. Each change is compiled and validated against the original program’s recorded behavior before it reaches a developer, and nothing is committed without human approval.
Because agents can work on many programs in parallel, the timeline for incremental Futurization shrinks without giving up the incremental structure that makes it safe. Organizations keep the control of a program-by-program approach and gain the pace that used to require a large, dedicated team.
What This Means for Developers
For the developers asked to deliver a transformation, the difference between replacement and Futurization shows up in the daily work.
A replacement asks you to reverse-engineer an entire application, specify it for someone else to rebuild, and then prove the rebuild matches. Futurization asks you to work on one program at a time, in a language and an environment you already know.
In practice, that means scoping changes at the program level, so every change has a clear boundary and a clear owner. It means capturing a program’s current behavior before changing it, so there is an objective standard for whether the new version is correct. And it means keeping the futurized and original versions compatible, so the program can go back into production without waiting for anything else to be finished.
Your knowledge of the existing code is not a liability to be documented and retired. It is the foundation the work is built on.
Questions Worth Asking Before Approving a Replacement
For IT leaders evaluating a proposal to replace RPG applications, a few questions tend to separate realistic plans from optimistic ones.
Has every business rule in the current applications been identified and documented, or is that expected to happen during the project? How will change requests be handled during a build that may run two years or more? What is the rollback plan if the cutover goes badly? And when does the business see its first measurable return: at go-live, or before?
If the honest answers point to undocumented logic, dual maintenance, a single high-stakes cutover, and value that arrives only at the end, the proposal is carrying exactly the risks that the research says turn large projects into failed ones.
Start With What You Already Have
The most expensive transformation is the one that consumes two years of budget and ends where it began. The organizations that avoid that outcome do not avoid change. They change in increments small enough to succeed, on applications that already work.
If your organization is weighing a replacement, or recovering from one, a Profound Discovery assessment can map your applications and identify where Futurization delivers value first. To talk through your situation with our team, reach out to Futurization@ProfoundLogic.com.