The conversation starts the same way every time: "everything here is bad, let's rewrite it." Sometimes that is right. More often it is a way to avoid figuring out someone else's code. Let us work out how to tell one from the other before the contract is signed.
Why a rewrite fails more often
The old system looks like chaos because ten years of exceptions piled up inside it. A strange condition in the middle of a function is somebody's old bug report. A duplicated check is a three-year-old incident.
The new system starts clean and collects the same exceptions again, one at a time, in production, on live users. Two years later it looks the same.
The second factor is time. While the replacement is being written, the old system keeps developing: the business does not stop. The team either drags two products along or freezes changes for a year, which the business does not survive.
Four criteria people count by
1. The share of code you will have to touch. Estimate how many files the changes planned for the year affect. Under 30%, refactor. Over 70%, a rewrite becomes rational.
2. Whether tests exist. Refactoring without tests is a blind rewrite with hope attached. If there are no tests, the first step is to cover the critical scenarios, and that is a separate project of 40 to 120 hours. Skipping it makes the whole conversation pointless.
3. Whether the platform is alive. PHP 5.6, Python 2, Angular 1 are platforms with no security updates. Convenience has nothing to do with it here: you are obliged to leave, and that is a rewrite regardless of code quality.
4. The speed of making changes. Measured simply. Take the last ten tasks and look at how long each took. If a fix that should take a day takes a week, and does so systematically, the cost of ownership is already above the cost of replacement.
The third path, chosen more often than either
Gradual replacement piece by piece. New code is written alongside the old, traffic is moved over in chunks, and the old system dies off one module at a time.
The scheme is this: a router is placed in front of the old application. At first it sends all requests to the old one. Then one section goes to the new. Then a second. A year later there is no old one left.
What it gives you: a working system at any moment, a rollback in a minute, a result the business sees within a month.
What it costs: a period when two systems coexist and the data has to be kept in sync. This is most often the hardest part, and it has to be planned before work begins.
What to do first in any case
Pin down the behaviour. Tests on the critical scenarios: checkout, payment, login, export. They will be needed under any scenario and will outlive any decision.
Describe the integrations. What the system takes in, what it gives out, to whom. This is a risk map: a broken integration is discovered a week later, when a partner has built up a discrepancy.
Collect metrics. Response time, error rate, load by section. Without them "it got better" stays a matter of faith.
How to count the money
Refactoring: hours to cover with tests plus hours for changes plus regression after each stage. It counts up predictably, because the volume is known.
Rewriting: the full cost of building the current functionality plus studying the old system plus running both in parallel plus data migration. The last three items are almost always absent from the initial estimates, and they produce a one-and-a-half to twofold overrun.
The practical rule: if the rewrite estimate does not exceed the refactoring estimate by at least twice, you have missed something.
A short checklist
Rewrite if: the platform has no security support, there are no tests and the code is unverifiable, the changes touch almost the whole codebase, and there are no developers to be found on the stack.
Refactor if: the system works, the changes are local, there are people who understand it, and the business is not ready to freeze development for a year.
In the remaining cases, gradual replacement. It is duller than either option and almost always cheaper.