Most IBM i systems today run applications built decades ago. They still process orders, manage inventory, and close the books without failure. That reliability is real, and it’s why the platform has lasted.
It also creates a difficult question for leadership. Do you keep fixing and extending the existing system as needs come up, or do you rebuild it properly?
The numbers pull in both directions. In Fortra’s 2026 IBM i Marketplace Survey, 95% of respondents said IBM i delivered better ROI than their other servers. At the same time, IBM i skills became the top concern for the first time since 2017, and 79% of organizations report at least one failed modernization project, at an average cost near $1.5 million.
Small fixes are cheap now and expensive later. Full rebuilds are expensive now and risky throughout. Neither choice is automatically safe, and the right one depends on what the application does for the business, not how old it is.
Patching vs. Overhauling: What’s the Difference?
Both words get used loosely, so it’s worth being exact.
Patching means keeping the existing application and changing it as needs arise. You add a field, adjust a calculation, bolt on a web front end, wrap a program in an API so another system can call it. The core code stays. You’re extending and repairing what’s already there. Most IBM i shops do this continuously, often without calling it anything at all.
Overhauling means replacing the application or rebuilding its foundation. That can take a few forms: rewriting the code in a modern language, re-architecting a monolithic program into smaller services, or moving to a new packaged system entirely. The common thread is that the old code stops being the thing you depend on.
When Patching Is the Right Strategy
Patching gets treated as the lazy option. It often isn’t. For a lot of applications, continuing to fix and extend the existing system is the financially correct choice, and rebuilding would destroy value rather than create it.
Patching makes sense when:
The application is stable and rarely changes. If a program does its job and the business hasn’t asked for much in years, a rebuild spends money to reproduce something you already have. The return is close to zero.
The business logic is proven and hard to reproduce. Decades of edge cases, tax rules, and customer-specific exceptions are baked into that code. Rewriting means rediscovering all of it, and that’s where projects fail. Remember that 79% failure rate: much of it comes from teams underestimating logic they didn’t know existed.
The change you need is small and contained. Adding a field, exposing a program through an API, or putting a web screen on top of existing logic are targeted fixes. There’s no reason to rebuild the engine to repaint the car.
Budget and people are limited. A full overhaul needs sustained funding and skilled staff for months or years. If you don’t have both, starting one is how you end up with a half-finished rebuild and the old system still running.
There’s a real risk to name, though. Patching solves the immediate problem but adds nothing to the pile of technical debt underneath.
When Overhauling Creates Greater Business Value
Overhauling stops being the expensive option and becomes the smart one when the cost of keeping the old system quietly climbs past the cost of replacing it.
Overhauling is the better investment when:
The application changes constantly and every change is slow. If the business asks for new features often, and each one takes weeks because the code is fragile, you’re paying a tax on every request. A modern architecture turns those weeks into days. In one documented engagement, moving a sales platform from a monolithic to a modular architecture delivered three times faster analytics processing and over 90% system stability.
The people who understand the code are leaving. This is the pressure that moved to the top of the survey. A 2025 analysis found more than 72% of IBM i developers are over 50, with 35.8% already 60 or older. When the logic lives in one person’s head and that person retires, patching isn’t even an option anymore. Rebuilding while they’re still around to explain the rules is far cheaper than reverse-engineering them after they’ve gone.
Technical debt is blocking things the business needs. When old architecture stops you from adding AI, connecting to modern systems, or meeting a new regulation, the debt has moved from an IT problem to a business constraint. Companies on legacy systems are 40% more likely to experience compliance failures, and that risk compounds as rules tighten.
A support or hardware deadline forces the issue. IBM i 7.4 moves to paid, narrower Service Extension support on September 30, 2026, and Power8 hardware can’t run anything newer, making a refresh mandatory for those shops. A forced move is the natural moment to rebuild rather than lift the same old code onto new hardware.
Patching vs. Overhauling: Comparing the True Costs
The mistake most cost comparisons make is looking only at the invoice. Patching wins on price every single time if that’s all you measure. The real comparison has to include the costs that don’t show up on a quote: the slow feature delivery, the compounding debt, the risk sitting in one retiring developer’s head.
Here’s how the two approaches compare across what actually matters to the business.
| Factor | Patching | Overhauling |
| Upfront cost | Low. Each change is small and funded from the running budget. | High. Often six or seven figures, with an average project cost near $1.5 million. |
| Long-term cost | Rises quietly. Technical debt compounds at roughly 20% a year, and each year of delay adds 20–25% to the eventual cost of change. | Front-loaded, then flat. Most of the spend is up front; running costs drop afterward. |
| Risk | Low per change, high in aggregate. One retirement or one fragile module can stall the business. | High during the project. 79% of organizations report at least one failed modernization, usually from underestimated logic, not bad technology. |
| Agility | Degrades over time. Small changes start taking weeks as the code gets more fragile. | Restored. A modern, modular design turns week-long changes back into day-long ones. |
| Scalability | Limited by the original architecture. You work within what the old design allows. | Built in. Re-architecting removes the ceiling the monolith imposed. |
| Technical debt | Grows. Every patch solves the problem and adds to the pile underneath. | Reset. The point of a rebuild is to clear the debt, provided you don’t recreate it. |
| Business impact | Keeps things running, adds little new capability. Good for stability, poor for growth. | Enables what the old system blocked: AI, integration, compliance. Reported ROI ran 288–362% in Kyndryl’s 2025 survey when scoped well. |
Redefining ROI Beyond IT Budgets
Ask what a modernization project returns and most answers stay inside the IT budget: lower maintenance, fewer servers, a smaller support contract. Those savings are real, but they’re the smallest part of the return, and treating them as the whole picture is why good projects get rejected. The maintenance savings alone rarely justify a seven-figure rebuild. The business case lives elsewhere.
A fuller view of ROI covers four things the IT budget never captures.
Speed to Change
When the business asks for a new feature, how long until it ships? On a fragile system the answer stretches into weeks, and every delayed change is a delayed opportunity. This is a revenue question dressed as a technical one. A system that lets you respond to the market in days instead of months has a value that never appears on the infrastructure line.
Risk Avoided
Some of the biggest returns come from costs that never happen. A breach that doesn’t occur, an outage that doesn’t take down order processing, a compliance failure that doesn’t trigger a fine. Companies on legacy systems are 40% more likely to experience compliance failures. Removing that exposure is worth money even though nothing visible changes the day after.
Knowledge you Keep
The single sharpest ROI on IBM i right now is capturing business logic before the person who understands it retires. With more than 72% of IBM i developers over 50, the rules that run the business are walking toward the door. A rebuild that documents and preserves that logic isn’t just modernizing code. It’s insuring the operation against a loss that has no recovery plan.
Capability Unlocked
The old architecture doesn’t just cost money to maintain. It quietly blocks things: the AI project you can’t start, the partner integration you can’t build, the customer experience you can’t offer. In the 2026 survey, AI and machine learning was the fastest-rising concern, jumping from 30% to 42% in a year, and much of that ambition runs straight into what legacy systems can’t support. The return here is the value of the door being open.
Put those together and the framing changes. The question stops being “what does this cost to run?” and becomes “what is this system preventing us from doing, and what is that worth?”
Conclusion
The biggest mistake companies make is treating patching and overhauling as an either-or decision. They are not competing approaches. They are different strategies, and the right choice depends on the application.
If an application is stable, reliable, and continues to meet business needs, a few updates or patches may be all it needs. Spending time and money rebuilding it may not deliver much value.
But if an application is slowing down the business, difficult to maintain, or depends on knowledge that only a few people have, simply patching it can create bigger problems over time. In those cases, a complete overhaul may provide a much better long-term return.
The key is to look beyond the immediate cost. Consider how the application affects productivity, innovation, maintenance, and future growth. Every application should be evaluated based on the value it brings to the business, not just its age or maintenance cost.
Some applications only need a patch. Others need a complete overhaul. The goal is to choose the option that delivers the greatest business value while making the best use of your investment.
