Contents
- The three options, priced in calendar time
- The 10-question scoring rubric
- Three decision patterns we see repeatedly
- When buying beats building
- What a diagnostic settles that an internal debate can’t
- FAQ
- Next step
This argument is already happening inside your engineering team.
One group wants to rewrite. They can list every reason the current system is unfixable and they are not wrong about any of them. Another group wants to refactor incrementally. They have watched a rewrite fail before and they are not wrong either.
The argument does not resolve, because both sides are reasoning from the same missing evidence. Nobody has measured anything. The loudest engineer wins, or the most tired one concedes.
Here is a rubric that replaces the argument with a score. Ten questions, explicit thresholds, and a result that points at one of three paths — plus a fourth that is usually the right answer and almost never gets proposed.
The three options, priced in calendar time
Money is the obvious axis. Calendar time is the one that actually kills companies, because it is what your competitors and your team’s patience are measured in.
| Option | What it is | Realistic calendar | Risk profile |
|---|---|---|---|
| Refactor | Improve the existing system in place, no architectural change | Continuous; meaningful gains in 3–6 months | Low risk, low ceiling. Cannot fix an architecture. |
| Rebuild | New system, same problem domain, built to replace | 6–12 months minimum for anything non-trivial | High risk, high ceiling. The feature-freeze trap lives here. |
| Replace | Buy commercial software, migrate off custom code entirely | 3–9 months, mostly data and process work | Low technical risk, high organizational risk. |
| Phased strangler | Route traffic incrementally from old to new, seam by seam | 9–18 months, but shipping from month 2 | Medium risk. Reversible at every step. |
That fourth row is the answer more often than any of the first three, and it is the one nobody proposes in the meeting because it sounds like indecision. It is not indecision. It is the only option that does not require you to be right about everything up front.
[INTERNAL LINK: /insights/strangler-fig-pattern-migration “how a phased strangler migration actually works, including where it stalls”]
The 10-question scoring rubric
Score each question. Add them up. The total tells you which path the evidence supports — not which path anyone in the room prefers.
Score 0 = no / rarely, 1 = partly, 2 = yes / consistently.
| # | Question | Threshold that scores 2 |
|---|---|---|
| 1 | What share of sprint capacity goes to production incidents and unplanned work? | Over 30% |
| 2 | How long until a newly hired senior engineer ships to production unsupervised? | Over 6 weeks |
| 3 | Can you deploy on a Friday afternoon without a discussion? | No — deploys are events |
| 4 | What percentage of the codebase has automated test coverage you’d trust? | Under 20% |
| 5 | Is there business logic only one person can explain? | Yes, and more than one such person |
| 6 | Is a core dependency past end-of-life or unsupported? | Yes, and upgrading is blocked |
| 7 | Has a feature been declared “too risky to touch” in the last 12 months? | Yes |
| 8 | Does the architecture prevent something the business has already committed to? | Yes — a sold roadmap item is blocked |
| 9 | Can you answer a security or compliance questionnaire without a multi-week scramble? | No |
| 10 | Has engineering attrition been above your company’s average for 2+ years? | Yes |
Reading your score
0–6 — Refactor. Your problems are real but they are not architectural. A rebuild here is engineering wanting a fresh start, and it will cost you a year to relearn things you already know. Invest in tests, observability and dependency hygiene.
7–12 — Phased strangler, almost certainly. This is the broad middle, and it is where most companies actually sit. You have genuine architectural constraints and a system too valuable to switch off. Cut one seam, route traffic, prove it, cut the next.
13–17 — Rebuild, but only after a diagnostic. The evidence supports architectural change. It does not tell you what to build — and a rebuild launched without a written architecture map fails the same way the last one did. what a Systems Audit settles before a rebuild starts
18–20 — Stop and stabilize first. A score this high means you are not in a position to make a good decision about anything. A team spending most of its capacity firefighting cannot gather accurate requirements, because the people who hold those requirements are exhausted. Stabilize, then re-score in 90 days. [INTERNAL LINK: /insights/software-project-rescue “the 90-day stabilization sequence”]
The one question that overrides the score
Question 1. If more than 30% of your sprint capacity is going to unplanned production work, refactoring has already lost — not because refactoring is wrong in principle, but because you have no capacity to do it. Refactoring is voluntary work. Voluntary work is the first thing an incident-driven team stops doing.
That threshold is where the argument usually ends in our engagements. Nobody who is drowning refactors their way out.
Three decision patterns we see repeatedly
On these examples: the patterns below are composites drawn from recurring engagement shapes, not accounts of specific clients. The decision logic is real; the situations are archetypes. [FILL: if you want named case studies here, substitute three real engagements with client permission and real outcome numbers. Do not attach invented figures to these archetypes — a fabricated case study is the fastest way to lose the credibility the rest of this cluster is built on.]
Pattern A — “The rewrite that should have been a refactor.” A SaaS platform, 8 years old, scoring 5 on the rubric. Engineering wanted a rewrite; the real complaint was a bad developer experience and a slow test suite. Rewriting would have cost a year and reproduced the same domain model. What the score pointed at: tooling, CI speed and dependency upgrades. Boring, unglamorous, and correct.
Pattern B — “The strangler nobody proposed.” A logistics system, scoring 11. Leadership was split into a rebuild camp and a refactor camp, deadlocked for two quarters. Neither was right. Routing order-intake — the highest-change, lowest-coupling seam — to a new service first let them ship improvements in month two while the monolith kept running everything else.
Pattern C — “The score that said stop.” A fintech scoring 18. They arrived asking for a rebuild quote. What the numbers said was that a rebuild decision made in that state would be a guess. Eight weeks of stabilization first, then re-score. The rebuild conversation became possible — and much cheaper to scope — once the team could think.
When buying beats building
The rubric assumes you should own this software. Sometimes you shouldn’t.
Replace with commercial software when all of the following hold:
- The system does something genuinely non-differentiating — billing, CRM, ticketing, HR, standard back-office
- Your customers have never chosen you because of it
- A mature vendor exists with a real migration path, not just an import button
- You can live with their roadmap rather than yours
Do not replace when the system encodes the thing you actually compete on. Companies discover too late that the “boring internal tool” contained fifteen years of pricing logic that was, in fact, the business.
The honest test: if a competitor adopted the same commercial product tomorrow, would you have lost anything? If no, buy it. If yes, that system is a product, not overhead.
Also budget realistically. A replacement is 20% software selection and 80% data migration and process change. The license is the cheapest part.
What a diagnostic settles that an internal debate can’t
Every question in the rubric above is answerable with evidence. Most teams have never gathered it, because gathering it is nobody’s job and everybody’s inconvenience.
A Systems Audit gathers it. Two to three weeks, $18K–$35K, fixed price against fixed scope. You finish owning four things: an architecture map, a risk register with severity scoring, a remediation plan with sequencing, and a fixed-price build proposal.
The walk-away clause matters most on exactly this decision. You own all four artifacts whether you hire us, hire someone else, or do nothing — which means the diagnostic is not a commitment to a rebuild. It is the thing that tells you whether you need one.
what each path costs, with published price bands
FAQ
Should I rebuild or refactor my legacy system?
Score it rather than debate it. If under 30% of sprint capacity goes to unplanned production work and your architecture isn’t blocking committed roadmap items, refactor. If both of those are false, you need architectural change — but a phased strangler migration is usually the right form of it, not a big-bang rebuild.
How long does a legacy system rebuild take?
Six to twelve months minimum for anything non-trivial, and that assumes you start with a written architecture map. A phased strangler migration runs longer end-to-end — nine to eighteen months — but starts shipping value in month two instead of month nine, which is why it fails less often.
What percentage of rewrites fail?
Published failure rates vary so widely by definition that quoting one is close to meaningless. The more useful question is why they fail, and the recurring cause is consistent: a rewrite that requires a feature freeze creates a window where the business is not being served, and the window is always longer than planned. [EXTERNAL LINK: Martin Fowler’s writing on StranglerFigApplication, as the canonical reference for the alternative]
Is buying commercial software cheaper than rebuilding?
Usually on licence cost, rarely on total cost. A replacement is roughly 20% software selection and 80% data migration and process change. Buy when the system is genuinely non-differentiating; build when it encodes what you compete on.
Can we decide this without an external audit?
You can, if you’re willing to gather the evidence yourself — every question in the rubric above is measurable with your own data. Most teams never do, because it’s nobody’s job. An audit is a way of making it someone’s job with a deadline.
Next step
Run the rubric with your engineering leads this week. It takes an hour and it will change the shape of the argument, whatever the score says.
If the score lands between 7 and 17, that’s the range where an outside diagnostic pays for itself — book the Systems Audit, or start with the free 90-minute Code & Risk Review if you’d rather see how we work first.
