Refactor or rewrite? How to decide

We found no source with a rule that settles refactor against rewrite for every system, and none that compares the two on the same systems. What the sources do describe is why a full rewrite is risky: Martin Fowler names old behaviour that is hard to describe and users who cannot wait, and Microsoft's guidance calls replacing a whole complex system difficult.

What does the $1.52 trillion figure measure?

In its report The Cost of Poor Software Quality in the US: A 2022 Report, CISQ says the accumulated software technical debt "has grown to ~$1.52 trillion". The report was written by Herb Krasner, a retired professor of software engineering, and sponsored by Synopsys and Undo, two software tool vendors. CISQ is a consortium, and its press release of 6 December 2022 describes the debt as "the cost of reworking suboptimal software".

The report is open about how the number is built. In its 2020 edition CISQ estimated the debt principal in the US at about $1.3 trillion, and says that would rise to $1.52 trillion in 2022 "due to inflation alone". So the 2022 figure is a 2020 estimate adjusted for prices, not a new count. The report adds that it has "no good estimates yet" on the interest, the extra effort developers spend because the debt exists. We did not open the 2020 report, so we cannot say how the $1.3 trillion was derived.

Two limits follow. The figure covers the United States, so it says nothing directly about a European company. CISQ defines the principal of technical debt as the cost of refactoring or modifying software so that it reaches a desired level of maintainability, which is closer to a refactoring bill than to a rewrite bill. A buyer cannot read it as "a rewrite would cost this much". It does show why the question is worth asking: the report also puts the entire US IT labour base at $1.51 trillion in 2022, about the same size.

How much time does technical debt cost a team?

A European study gives a figure at team level. Besker and Bosch of Chalmers University of Technology in Sweden and Martini of the University of Oslo surveyed 43 developers from six companies and ran 16 interviews, then checked the result against a second dataset. Their paper in the Journal of Systems and Software reports that developers "waste, on average, 23% of their time due to TD". The most common extra activity was additional testing.

The two numbers measure different things. CISQ estimates a national sum of money. The Chalmers study asks developers how much of their working time goes on debt, in a sample of 43. CISQ also quotes the 23% figure, so the two are not independent confirmations of each other. We use the Swedish paper because it can be read on its own and was peer reviewed.

What do studies say about refactoring risk?

The best-known field study is Kim, Zimmermann and Nagappan at Microsoft, published in IEEE Transactions on Software Engineering in 2014. It used a survey of 328 professional engineers, interviews with a refactoring team, and the version history of Windows 7.

Their survey found that 76% of participants consider refactoring a risk for introducing subtle bugs and functionality regression. One engineer put the main risk as "misunderstanding subtle corner cases in the original code and not accounting for them in the refactored code". The authors also found that the most refactored 5% of modules showed larger reductions in inter-module dependencies and in several complexity measures than the other 95%, but grew more in size. They conclude that measuring the impact of refactoring takes more than one metric.

This study is about refactoring, not rewriting, and it is from 2014 at one company. We read the corner-case quote as a warning that applies with more force to a rewrite, since a rewrite has to rediscover every such case. That is our reading, not the authors' statement.

What does a rewrite risk that refactoring does not?

Martin Fowler's article on the Strangler Fig pattern, last dated 22 August 2024, states the case against the simple replacement. In his words, "we've seen this simple-sounding plan go down in flames most of the time". He gives three reasons: replacing a serious IT system takes a long time and users cannot wait for new features, the details of existing behaviour are hard to work out, and much of that behaviour is not wanted, so building it is waste. This is the experience of one author and his colleagues. It is not a measured failure rate.

His alternative is a gradual replacement in which new code grows around the old and takes over behaviour piece by piece. Fowler also warns that this "doesn't make the exercise easy" and that without a change in organisational culture the new system may end up in a similar mess.

When does a gradual approach not fit?

Microsoft's Strangler Fig pattern guidance for Azure lists cases where the approach "might not be suitable": when requests to the back-end system cannot be intercepted, when you cannot access the legacy system's source code and it has no other integration point you can change, when you migrate a small system and replacing the whole system is simple, or when you need to fully decommission the original solution quickly.

It also says the pattern fits when the original system can continue to exist for an extended period. The page was updated in 2026, and it is vendor guidance for one cloud platform, so the details of its examples are specific to that platform. The conditions above are general.

A decision checklist (our addition)

This list is our addition. It turns the sources above into questions, and it is not a method that any of them proposes. The answers need an engineer who has read your code.

1. Can someone describe what the system does today? Fowler says existing behaviour is hard to work out, and Kim's engineer names unaccounted corner cases. If nobody can describe it, a rewrite starts without a specification.

2. Is there a test or check that tells you a change broke something? In Kim's survey, 76% name regression bugs as a risk. Without such checks, both options are risky, and building them comes first.

3. Is the source code available, and can requests be intercepted or redirected? Azure lists both as conditions for a gradual replacement.

4. Is the system small? If replacing the whole thing is simple, Azure says the gradual pattern may not be worth it.

5. Can the old system keep running for a long time? If it can, a gradual replacement is possible. If it must be switched off soon, Azure lists that as a poor fit.

6. Can users go without new features while a replacement is built? Fowler names users who cannot wait as a reason replacements fail.

7. Is the cause of the debt something a new codebase would not fix? Fowler's point on organisational culture suggests that a rewrite by the same process may reproduce the same code.

8. Have you measured the cost? The Chalmers figure of 23% is an average from 43 developers. Ask your own team how much time goes on workarounds, extra testing and fixes, and compare that with the cost of the option.

Answers that favour a gradual approach, whether refactoring or gradual replacement, are yes to 2, 3 and 5, and no to 4 and 6. A no to 1 or 2 means the first piece of work is understanding and test coverage, whichever route follows. The sources do not give a score or a threshold, so the weighing stays a judgement for the people who know the system.

What should a buyer do next?

Ask for a written assessment before any decision between the two. On our site we describe codebase recovery as a review first, then a written recovery plan within two weeks that sets out what to fix, what to refactor later and what to leave alone. If the answer is a new system, custom software development is the related service.

What we could not confirm

We found no peer-reviewed study that compares full rewrites and refactoring on the same systems, and no measured failure rate for rewrites. Fowler's "most of the time" is his own experience. We did not find a source for how long a typical rewrite takes, or what it costs relative to refactoring.

We could not open the ISO/IEC 25010 standard, which defines maintainability, because the ISO site blocked automated access, and we do not rely on it. CISQ's 2020 report was not opened, so we cannot say how the $1.3 trillion starting figure was derived. There is no European equivalent of the CISQ national estimate that we could find; the Chalmers study is European, but it measures team time, not money.