If your most knowledgeable engineer were unavailable for eight weeks starting tomorrow, what would stop? Run through it honestly, asking whether releases would pause, whether hotfixes would slow down, whether deployments would become someone's side project, whether architecture decisions would freeze, and whether customer escalations would back up. If several of those trace back to one person, you are carrying risk that you probably already know exists. This article is how you address it.
Most engineering leaders know they have systems that need modernization. The harder question is which path to take. The business wants an answer, and the engineering team has opinions that conflict. And the default assumption is that old software should be rewritten—costs money to test and can be catastrophically wrong.
The scale of the problem is not small. Federal agencies, according to the U.S. Government Accountability Office, spend roughly 80 percent of their IT budgets maintaining existing systems rather than building new ones. In large enterprises, McKinsey's research shows that technology debt consumes 40 to 50 percent of the total IT investment budget. That is not a technology problem but a business problem. The money spent keeping systems alive is money that cannot be spent on products, customers or competitive advantage.
The question is not whether to act but how to act.
What You Really Need to Know About Old Software
The most expensive assumption in modernization is that old means broken. A twenty-year-old system with clean module boundaries, valuable business logic and a supported runtime is in far better shape than a five-year-old system with tangled dependencies on an abandoned framework. Platform age and system health are not the same thing.
IBM i is the clearest proof. The platform itself is not the constraint. IBM publishes a roadmap for IBM i running to 2035, so neither the hardware nor the operating system faces end of support, and what changed is the people rather than the platform. Fortra's 2026 IBM i Marketplace Survey gathered responses from roughly 320 IBM i users and found that a shortage of IBM i skills displaced cybersecurity as the top concern for the first time in nine years. Sixty-nine percent of respondents cited skills shortage as their top issue, up from 60 percent the year before. The risk on that platform is human, not technical, and that distinction changes which of the four modernization paths makes sense.
Four Options, Each One Right in Different Circumstances
Refactor when the business logic is valuable, and the architecture still works but the code has become difficult to maintain. Re-platform when the application is sound but its runtime or deployment model is not. Rewrite when the core architecture blocks major requirements and incremental improvement would cost more than replacement. Retire when the capability no longer differentiates the business and maintenance exceeds the value produced.
The trap is treating one of these as default. Each one is the right answer for a different set of circumstances, and the circumstances matter more than the age of the code.
Refactor: Improve Without Replacing
Refactoring means improving the internal structure of an application without changing what it does or what platform it runs on. You improve code organization, eliminate duplication, better separate concerns, modernize database access layers and introduce automated tests. The business sees no change and users see no change, and the only thing that changes is how easy the code is to maintain and how confident engineers feel modifying it.
This is the right choice when the business logic inside the application is valuable, the overall architecture is still sound, and the problem is purely that maintenance has become slow or risky. Use it when technical debt is slowing your release cycle and tests can protect existing behavior while you improve.
IBM i environments often land here. The business logic encoded in twenty years of RPG represents value that competitors cannot easily replicate. Databases carrying decades of production history are harder to migrate than they are to improve. The modernization path is not to throw that away. It is to improve the structure. Convert fixed-format RPG to free-format ILE. Break large monolithic programs into smaller modules. Replace outdated database definitions with SQL. Introduce automated testing and continuous integration pipelines. The result is a system that behaves identically to users but becomes substantially easier for new engineers to work on.
A financial institution did precisely this, converting legacy fixed-format RPG to free-format RPG ILE, upgrading its database to modern SQL-based structures that improved query performance by up to eight times, and replacing green-screen interfaces with responsive web applications. They added CI/CD pipelines with automated testing. They did not rewrite, they improved what worked.
The primary risk is straightforward but expensive to discover late: spending heavily to improve an architecture that is fundamentally unsuitable for where the product is heading. If the constraints that limit you are structural and baked into the architecture, refactoring the code will not remove them. It will just move the problem around.
Re-platform: Move Without Rewriting
Replatforming means moving an application to a more sustainable runtime or deployment model while preserving the logic it contains. A desktop application moves to web, an unsupported mobile stack moves to a supported one, on-premise infrastructure moves to cloud, and an out-of-support database or runtime gets replaced with a version that vendors still support.
The application still makes sense, and what makes less sense is the platform it runs on.
A global oil and gas company moved its AS400 ERP and database to AWS using an emulator like Infinite i. They preserved all workflows, gained on-demand scaling and improved disaster recovery capability, and cut high infrastructure costs. The effort was significant but the outcome was swift and low-risk because they were not rewriting the application, only moving it. The technical debt remained, but the quick, low-risk migration delivered immediate cost savings and flexibility, which set the stage for deeper modernization later if needed.
This is the right choice when the platform constraint is real and removable but the application logic is not the constraint. Use it when you cannot find engineers for a legacy language anymore, when the runtime is no longer sold by the vendor, when the platform cannot scale to meet current demand, or when security requirements force you off an unsupported version.
A mobile application delisted from an app store because of deprecated APIs and unsupported network security is a textbook re-platform trigger, where the application works but the runtime does not, so the answer is to move it.
The risk is underestimating how much the platform constraints shaped the design. An application built for a mainframe with certain performance characteristics will behave differently on a different platform. Those differences usually surface in one customer environment before they show up in testing.
Rewrite: When Architecture Is the Constraint
A rewrite rebuilds substantial portions of an application, usually on new architecture and often on a new platform. It is not refactoring with a bigger scope. It is a different class of work.
This is the right choice when the core architecture blocks requirements you need to support, when the technology is effectively unsupportable, when security limitations are structural rather than incidental, and when incremental change has become more expensive than replacement. You need sufficient knowledge to define correctness. You need tests or documented behavior. You need to be able to rediscover the business rules that the old code encodes.
The primary risk is massive and easily underestimated: the current product contains years of implicit behavior that nobody ever documented. In a rewrite, that undocumented behavior becomes invisible until it fails in production. Every team that has done a rewrite at scale has experienced the surprise of discovering that some obscure process, some exception case, some customer-specific rule that nobody remembered is critical to real operations.
An engineering team ran a rewrite of a ten-year-old system. The new version passed every test and every requirement and shipped to production, and a week later a single customer's workflow stopped working. After investigation, the team found that the old system had a bug that the customer had built their entire operation around. The bug was now fixed in the new version, and the customer's entire workflow broke as a result. Fixing it meant understanding both what the customer needed and why the old system had satisfied that need despite being technically incorrect.
That is the class of problem that makes rewrites expensive. You cannot prevent it with better testing or better requirements capture. You can only mitigate it by knowing as much as possible about the current system before you rebuild it.
Retire: The Option Nobody Wants to Say Out Loud
Sometimes the correct engineering decision is to stop owning the capability. Retire the application when it is no longer strategically differentiating, when usage is low, when credible commercial alternatives exist that are stronger than what you can build, or when maintenance costs exceed the value the application creates.
This option is almost never present in modernization content, and that absence is telling. A rewrite or a re-platform engagement is a large project, whereas retirement is not. Vendors selling modernization services have no incentive to recommend that a customer retire something. But from the customer's perspective, retirement is sometimes the cleanest answer.
If you own a module that your largest customers no longer use, that your growth customers are not demanding, and that requires specialized expertise you cannot hire, then maintaining it is pure cost with no offsetting value. Retire it and move the work to a commercial solution. Tell the small number of remaining users that you are sunsetting the capability and here is what they should migrate to instead. The total cost of that transition is frequently lower than two years of maintenance on a system that no longer matters to the business.
The Ten Questions That Determine the Right Path
Before you commit budget to any of these options, ask yourself ten questions honestly. The answers determine the path far more reliably than the age of the system does.
Is the capability still creating business value? Or is it one of those screens or processes that the business calls critical but nobody uses at scale? Business value should mean measurable value to the customer or to the company, not simply that the system is running. Systems can run forever without creating value.
How much of the business logic in this system is still valuable? Sometimes the answer is most of it. Sometimes the answer is that the business rules were correct five years ago and have drifted significantly. If the logic is becoming obsolete, a rewrite that codifies current thinking might be better than preserving the old logic intact.
Is the platform still viable? Is the vendor still selling it? Are updates available? Can you run it on infrastructure you can afford? Can you hire people who know it?
Can you hire the people you need to maintain or modify this system? Grails and Ruby on Rails developers are getting hard to find. RPG programs are retiring faster than universities are teaching the language. If you cannot hire the people and cannot train the people, then maintaining the current architecture becomes expensive regardless of how sound it was when built. This is closely tied to key-person risk, which you should reduce before you modernize.
Is the current architecture flexible enough to support the changes you need to make? Some architectures can bend, while others are brittle. If your next significant feature requires architectural change, then the refactor option has a lower ceiling than you might hope.
How much security exposure does the current system carry? Deprecated TLS, unsupported libraries, removed APIs, unpatched dependencies. These turn modernization from a strategic improvement into a compliance necessity. The timeline changes from next fiscal year to this quarter.
How much test coverage do you have? How much of the system's behavior is expressed as executable tests? The less you know, the more dangerous a rewrite becomes. If you have thousands of lines of code and no automated tests, then the knowledge about what the system does at runtime lives in peoples' heads. That knowledge is invisible and easy to lose.
How many integrations does this system support? Does it connect to ERPs, CRMs, EHRs, partner systems? Does it expose APIs that other services depend on? If the integration surface is large, then rewriting is more complex because every integration has to be re-implemented and re-tested.
Is this product still differentiating your business? Or is it now a commodity? Products that differentiate deserve investment and have budget. Commodity functions are often better bought than built.
How much downtime can your customers tolerate? A multi-year rewrite might be technically perfect but commercially impossible if your customers cannot accept two years of reduced functionality or phased access to capabilities. Phasing lets you deliver value incrementally. A big bang rewrite often cannot be phased.
Gather the Evidence Before You Choose
Most teams jump to a decision before they understand the system they are modernizing, and that is how rewrites overrun. Before you commit to any of these four paths, do the work to understand what you are dealing with.
Build a dependency map. What does this system depend on? Write down every external integration, library, database, scheduled process, customer-specific extension and shared service. Most teams discover at least one dependency nobody even remembered exists.
Capture existing behavior. Characterization tests show what the system does at runtime, not what people believe it does. Documentation records what people think it should do, so find the difference between the two, using production telemetry to show usage patterns and support tickets to show what breaks. Interviews with subject matter experts reveal the rules and the exceptions that nobody wrote down.
Understand actual usage. Some screens that the business calls critical are barely used. Some obscure API endpoint that nobody pays attention to supports the largest customer. Instrument before you assume, and look at actual usage data rather than stakeholder opinions about usage.
Separate valuable business logic from implementation baggage. This is the work that determines the modernization strategy. A rule exists because a customer asked for it years ago. Another rule exists because of a technical constraint that no longer applies. They look identical in the code. Telling them apart requires knowing the business, not just reading the code.
The Decision Matrix
Rate the system across all ten criteria on a scale of one to five, where one is problematic and five is strong. The pattern that emerges usually points clearly toward one of the four options.
A system with high business value, valuable logic, reasonable architecture and available skills but aging code that is hard to maintain usually scores high on refactor and low on rewrite, so the path is clear.
A system with high business value and valuable logic but an unsupported platform and growing skills shortage usually scores high on re-platform. Move it to where you can hire people and get vendor support, and preserve the logic that has value.
A system with low business value, little valuable logic, architectural constraints that block change and high maintenance costs usually scores high on retire. It has reached the end of its useful life.
Rewrite scores highest only when you have a system that blocks major capabilities, carries high risk, has poor test coverage but solid business logic you can rediscover. That is a specific and relatively rare situation.
Not sure which path your system needs? We run modernization assessments that map dependencies, capture undocumented behavior and produce a costed, phased recommendation rather than a single predetermined answer.
What to Do Before You Choose
Run the ten-question analysis. Build the dependency map. Capture the existing behavior. Understand the actual usage. Document the business logic separately from the technical implementation. All of this is work you can start Monday without hiring anyone. All of it changes how you answer the modernization question.
Where AI Genuinely Helps, and Where It Stops
AI accelerates the evidence-gathering phase. It can map repositories and find dependencies faster than a manual review. It can draft documentation and suggest test cases. IBM's own approach to RPG modernization now includes AI-assisted code explanation, conversion and testing, which validates that this is a legitimate way to accelerate the process.
The boundary is precise and important: AI can speed up extraction and initial documentation of what the system does. It cannot tell you which fifteen-year-old behaviors are intentional requirements and which are accidental artefacts. That judgment requires a person who knows what the business promised customers and what promises are still current.
Why Phased Modernization Usually Wins Over the Big Rewrite
A multi-year rewrite is technically elegant and commercially difficult. Customers do not pause while you rebuild. Revenue continues and products continue evolving, so a system that serves no customers during a three-year rewrite is no longer competitive by the time it ships.
Phasing lets each increment carry its own business justification. The first phase might modernize the data layer. The second might upgrade the user interface. The third might refactor a core module. Each delivers value and each gives the team a chance to correct the plan based on what they learn. The total cost is sometimes higher because there is some rework as you integrate between phases, and the timeline is longer, but the product generates revenue the entire time and the team is never bet on a single outcome that has to be perfect.
Mature B2B products make this even more critical because of customer-specific behavior. These products usually contain dozens or hundreds of small customizations for specific customers. A phased approach lets you handle the variants in sequence rather than requiring them all to be solved before anyone sees value.
FAQ
What is the difference between refactoring and rewriting software?
Refactoring improves the internal structure of the code while keeping the same behavior and the same platform. A rewrite rebuilds substantial portions of the application, often on new architecture. Refactoring is lower risk and lower cost but has a lower ceiling on what problems it can solve. A rewrite addresses architectural constraints that refactoring cannot touch.
When should you rewrite a legacy application instead of refactoring it?
Rewrite when the core architecture itself blocks the capabilities you need to support, when the technology is no longer sold or supported by vendors, when security limitations are structural rather than incidental, and when analysis shows that incremental improvement would cost more than replacement. Verify first that you have enough knowledge of existing behavior to define correctness for the new version. Undocumented behavior is what makes rewrites overrun their schedules.
Is IBM i a legacy platform that needs replacing?
No. IBM publishes a roadmap for IBM i extending to 2035, so the platform has a clear future. Fortra's 2026 IBM i Marketplace Survey found that skills shortage, not platform viability, displaced cybersecurity as the top concern for 69 percent of respondents. The constraint is hiring and knowledge transfer, not the platform itself. That makes replatforming usually the wrong answer and refactoring combined with skills development usually the right one.
How do you decide whether to retire an application?
Retire when the capability no longer differentiates the business, when usage is low, when commercial alternatives exist that are better than what you can build and maintain, or when maintenance costs exceed the measurable value the application creates. Measure usage from actual data rather than from stakeholder opinion. Some applications people think are critical are running at quarter capacity or less.
