Rewrite, Refactor or Replace? Picking a Modernization Path with AI

Get in touch:

Thinking through a new idea or stuck with a challenge? Drop us a message—we'll listen, brainstorm, and help move things forward.

The last two rows matter. AWS treats retire as a first-class option, with a rule of thumb that applications averaging under 5% CPU and memory, or with no inbound connections for 90 days, are candidates. In our experience, shutting down a system nobody uses is often the cheapest modernization available.

A rewrite is the option that throws away the existing behaviour and asks you to reproduce it from memory.

Why Rewrites Keep Going Wrong

The argument against the big rewrite is old and has not weakened. In April 2000, Joel Spolsky argued that rewriting from scratch is the single worst strategic mistake a software company can make. His example was Netscape, which had gone almost three years without a major release while it rewrote its browser, and lost market share in the gap. His reasoning was that the old code looks messy because it contains years of bug fixes, and a rewrite discards that knowledge.

Martin Fowler reaches the same place from the other direction. In his Strangler Fig Application write-up, last dated August 2024, he notes that the simple plan of building an exact replacement has often gone down in flames. Replacements take a long time, users will not wait for new features, and existing behaviour is hard to specify. He adds that much of it is behaviour nobody wants, which a rewrite wastes effort recreating.

Our own view, from delivery work, is that the failure is rarely in the new code. It is that nobody can say what the old system does at the edges: how it rounds, which order a batch runs in, what it does with a malformed record. Those details live in the code, not in any document.

What AI Changes, Option by Option

AI is useful here in specific places. It is not a reason to pick a different strategy on its own.

It lowers the cost of refactoring. Google's paper, "Migrating Code At Scale With LLMs At Google" (April 2025), covers 39 distinct migrations by three developers over twelve months. The model produced 74.45% of the code changes, and the developers estimated a 50% reduction in total migration time compared with earlier manual efforts. These were scoped, repetitive changes with a clear before and after, and the estimate is the developers' own, so treat it as a ceiling for similar work, not a forecast for yours.

It makes discovery faster, which helps every option. In our experience, explaining unfamiliar code and drafting documentation is where AI helps most, and Thoughtworks reported cutting reverse-engineering time by two thirds on one 15-million-line programme. We cover it in what actually works in AI-powered legacy modernization.

It does not make a rewrite safer. A model can write a clean replacement quickly. It cannot tell you whether the replacement behaves like the original. In April 2026 Gartner's report "Too Big to Fail" argued that more than 70% of mainframe exit projects started in 2026 will fail to deliver their intended benefits because generative AI is overestimated, as The Register reported. The report recommended evaluating each workload and continuing to improve existing mainframe systems instead of assuming an exit is achievable.

It leaves replacement mostly untouched. Buying a product is about fit, licences, data migration and change management. In our view AI can speed up requirements mapping and data migration scripts, but the decision does not hinge on it.

A Decision Guide

Ask these questions in order. The first "yes" usually settles it.

1. Does anyone still use it? If not, retire it. Check usage data before spending anything.
2. Is it a commodity function? In our judgement, payroll, HR, basic CRM and document management rarely set a business apart. Replace with a product, and spend your engineering effort elsewhere. This is AWS's repurchase option.
3. Does it work, but run on a platform that is ageing? Replatform. Move the database to a managed service or the app to containers, change little code, and keep behaviour identical.
4. Does it work, but is it hard to change? Refactor in slices. Put the new structure beside the old, move one capability at a time, and compare behaviour before each cutover. This is the strangler fig approach.
5. Is it small, well-tested and well understood? Then a rewrite of that component is reasonable. Keep it bounded, keep the old one running until the new one has matched it, and have tests ready first.
6. Is it large, poorly documented and business-critical? Do not rewrite it in one go. Start with discovery, write characterization tests that pin the current behaviour, and go back to step 4.

A useful sanity check on any choice: could you cut over one piece at a time? If the answer is no, the plan carries the all-or-nothing risk that Spolsky and Fowler describe, whatever it is called.

What AI Adds to the Refactor Path in Practice

If you land on refactoring, which most systems should, AI earns its place in four steps.

• Map the system. Use it to list modules, dependencies and data flows, and have each module's owner check the result.
• Write tests that pin current behaviour. AI can draft characterization tests quickly. A person must confirm they capture what the system really does, bugs included.
• Make the repetitive changes. Library swaps, API upgrades and framework moves are the work Google's study measured. Run these with the tests as a safety net.
• Review everything. Google's 50% figure already includes engineers reviewing and correcting the model's output. Budget for that review.

For timing on this path, see how long AI-assisted legacy modernization takes, and for the readiness work that comes first, why legacy systems block AI adoption. Modernization should also fit a wider plan.

The Bottom Line

The choice is less about technology than about risk. Refactor in slices when the system matters and works, replace when it is a commodity, retire when nobody needs it, and rewrite only what you can specify and test. AI makes the middle option cheaper and the discovery work faster, and it leaves the old rule in place that you cannot rebuild what you do not understand.

If you want a second opinion on which path fits a specific system, get in touch. We will tell you plainly where AI helps and where it does not, and a dedicated team can run a scoped pilot without pulling your own engineers off the roadmap. For the wider planning context, see our AI strategy for software companies pillar.