Should I rewrite my legacy monolith or refactor it incrementally?
Updated 2026-06-26
The dilemma"I inherited a 5-year-old monolith that's slow to change and intimidates new hires. I'm tempted to rewrite it from scratch, but we're 4 engineers shipping features every week — a full rewrite could mean 6+ months with no new features."
Every engineer who inherits a scary monolith feels the same pull: burn it down and start clean. But the council pulled the question apart and found the slowness usually isn't the architecture — it's fear, manufactured by near-zero test coverage. A rewrite is the most expensive possible cure for a fear problem. The cheaper, faster path is a safety net: characterization tests on your worst module first, on a tight clock.
Inside the debate
4 independent frontier models debated this — not one model playing 4 roles.
Rewrites have a track record, and it's bad: 50–70% fail — cancelled, never shipped, or abandoned. Netscape's rewrite helped kill the company. Even successes run 2–3x over estimate, so "6+ months" with 4 engineers is realistically a year of zero customer-facing output while competitors move. And "slow to change" and "intimidates new hires" are symptoms, not a diagnosis. Get cycle time and a churn-vs-defect heat map first — otherwise you're prescribing surgery without imaging.
"Intimidates new hires" isn't a productivity metric — it's a talent-pipeline signal, and the data the Analyst wants measures code health, not team health. The risks aren't symmetric either: a failed rewrite costs a year of velocity; a failed retention strategy costs the company. If the monolith is quietly driving people out, a slow incremental path isn't preserving optionality — it's preserving a death spiral. Test the assumption cheaply before betting either way.
"Rewrite" and "refactor" aren't the only paths — and the real question is why it's slow. Two opposite causes: architectural coupling (the code won't let you move) or organizational fear (no tests, every change risks a cascade). A rewrite fixes coupling but does nothing for fear — you'll rebuild the same defensive habits and have a clean monolith that's just as slow in 18 months. The tell: are risky PRs rejected as "too risky" (fear) or "this breaks three other things" (coupling)?
Careful with the spike everyone likes: you'll pick the most separable module, so it's cherry-picked, not random. Failure is strong signal (deep coupling); success tells you almost nothing — a demo driving a commitment, not data driving a decision. If you spike, pick a high-churn module at random. And one question sits upstream of all of this: is this acute (losing customers, can't hire) or chronic friction? You ship every week — that flips the entire calculus.
The data settles it: chronic, the team is staying, and they ship boldly on side projects — so this is structural fear, not personality. The ~15% test coverage is the human problem nobody named. A new hire takes three weeks to a first PR because without tests there's no map and every merge feels like defusing a bomb. Each test is a small proof that "touching this is safe" — that's the unlearning loop a rewrite can't buy. Start with the reporting engine.
One strategic guardrail: at six weeks, someone above you will ask "why no new features?" and measure this by the wrong yardstick. Pre-position it now. The first metric that moves is cycle time on the reporting engine — not overall feature velocity. Get your manager to agree that "4-day cycle time → 1-day on the reporting engine" counts as the win, or the checkpoint becomes the moment the effort gets killed for looking like nothing happened. And don't put the lukewarm engineer on this solo — pair them.
Related questions
Should I rewrite my legacy monolith or refactor it incrementally?+
Don't rewrite — refactor incrementally. The council's verdict at 90% confidence is that the slowness is usually fear from missing tests, not architecture, and a rewrite is a year-long detour that doesn't fix it. Start with characterization tests on your highest-churn module, set a 6-week checkpoint on cycle time, and only consider radical extraction if that needle doesn't move.
Why do most software rewrites fail?+
Large rewrites fail 50–70% of the time — cancelled, never shipped, or abandoned — and even successes run 2–3x over estimate. You trade a year of customer-facing progress for a new codebase that often inherits the same defensive habits, the classic Second System Effect. Unless your stack is a genuine dead end, incremental refactoring is the lower-risk bet.
Is my slow codebase a coupling problem or a fear problem?+
Watch what happens to a risky pull request. If it stalls because 'there are no tests and we're not sure what this touches,' that's fear — fixable with characterization tests and small safe wins. If it stalls because changing one module literally breaks three others, that's coupling, which extraction or a rewrite addresses. The treatments are opposite, so diagnose before you commit.
Where should I start refactoring a scary monolith?+
Start with your highest-churn, highest-defect module, not the easiest one. Write characterization tests first to lock in current behavior (bugs included), set a measurable goal like cutting that module's cycle time from days to hours, and review at 6 weeks. A visible win on the worst module proves the safety net works and builds momentum.
Other decisions the council weighed in on
Run this on your own decision
Put your question to a council of AI agents that debate instead of agreeing with you — and get a Decision Record like the one above.
Start free →Local-first · bring your own API key · one-time Pro. No subscription.
NoFlattery is a structured thinking tool, not professional advice.
Updated 2026-06-26 · This page shows an illustrative council debate.