5 October 20269 min read

Board Ready Scorecard for CTOs: Swiss Cases on Rewrite vs Refactor

An old wooden chair clamped for repair on a workbench, beside an unopened flat-pack box for a new chair.

Refactor by default. Rewrite only when measurable constraints make incremental change impossible. The risk, cost, and institutional knowledge lost in a full rewrite rarely pay off against the alternative of small, testable improvements. The single question that decides it: can small, testable changes meet your required business constraint? The scoring rubric below turns that question into a defensible answer.

TL;DR:

Conduct a decision matrix considering business criticality, data coupling, test coverage, deployment risk, team capacity, operational costs, and legal constraints before refactoring or rewriting.

Refactoring is best when there are existing seams, sufficient test coverage, and short time-to-value, especially if behavior is protected by tests; a rewrite is only justified if incremental changes cannot deliver needed capabilities.

Rewrites should be scoped, short, and driven by clear exit criteria, with evidence that partial migration cannot meet technical or regulatory needs, avoiding emotional decisions.

Incremental patterns like the Strangler Fig allow replacing legacy systems feature-by-feature or data domain by data domain, provided observability and rollback mechanisms are in place.

Senior engineers must oversee the decision process, ensuring assessment is based on evidence like test coverage, seams, and deployment risk, rather than preferences or outdated impressions.

A weighted decision matrix for the rewrite or refactor call

A single opinion rarely survives a board meeting. A scored matrix does. Score each factor from 1 (favors refactor) to 5 (favors rewrite), then apply weights that reflect what actually threatens your business.

Business criticality: how much revenue or compliance exposure sits behind this system right now.
Data coupling: how tightly the schema and business logic are fused, and whether you can slice either without touching the other.
Test coverage: the percentage of critical paths covered by automated tests you trust.
Deployment and rollback risk: how fast you can ship a change and undo it if it breaks something.
Team capacity: whether you have the senior engineers free to run a multi-month migration without starving other work.
Operational cost: the current maintenance burden, measured in hours per sprint or dollars per quarter.
Legal or regulatory constraints: whether a framework, data residency rule, or audit requirement blocks incremental change outright.

Weight business criticality and legal constraints heaviest, since they carry the sharpest downside if you get the call wrong.

A composite score under roughly 2.5 points toward refactor. A score between 2.5 and 3.5 suggests a Strangler Fig approach: incremental replacement behind a routing layer. Above 3.5, with corroborating evidence on at least two factors, a scoped rewrite becomes defensible. Collect real numbers before you score anything: unit test coverage percentage, mean lead time for changes, deployment frequency, and documented maintenance cost per quarter. A rubric built on guesses is just an opinion with a spreadsheet attached.

When the signs point toward refactoring

Most systems that look unsalvageable are actually just undertested. Refactoring wins when these conditions hold:

Seams already exist, or can be engineered in days rather than months, letting you isolate and change one module without touching the rest.
Incremental deployment is practical: you can ship a change behind a flag and roll it back in minutes.
Test coverage on critical paths is sufficient, or raising it is a bounded, estimable effort rather than an open-ended one.
Behavioral correctness matters more right now than internal design purity. Users do not notice clean architecture; they notice downtime.
Time-to-value is short, and your team or budget cannot absorb a multi-quarter rewrite without stalling other priorities.

A payment processing module with messy internals but solid test coverage is a textbook refactor candidate: the risk sits in behavior, not structure, and behavior is already protected by tests.

Pro Tip: Before scoring anything else, check whether you can write a passing test for the behavior you are about to touch. If you cannot, that is your first project, not the rewrite.

When a rewrite is actually the defensible choice

A rewrite earns its cost only under narrow, evidence-backed conditions, not because the code looks old or a new engineer dislikes the framework.

The current architecture blocks a capability the business genuinely needs, and no incremental change path exists to add it.
The data model or a regulatory requirement cannot be migrated safely in slices, so partial states would leave the system non-compliant or inconsistent.
No feasible seam exists anywhere in the codebase, and the coupling between components is so dense that isolating one piece risks breaking all of them.
A phased rewrite can be scoped tightly, funded for a short and bounded window, and shipped with explicit exit criteria rather than an open-ended “we’ll know it’s done when it’s done” mandate.

If your case does not satisfy at least two of these, you are choosing a rewrite for emotional reasons, not technical ones. That is the most expensive mistake on this list.

Strangler Fig and other incremental modernization patterns

The Strangler Fig pattern, documented by Martin Fowler, replaces legacy behavior in small, testable slices instead of a single cutover. Each slice ships, proves itself in production, and only then does the next slice start, which turns a high-risk bet into a series of low-risk ones.

Three variants cover most real migrations:

API gateway routing: a facade layer sends traffic to either the legacy system or the new component based on route, letting you cut over feature by feature.
Feature-by-feature extraction: you pull one capability out of the monolith at a time, starting with the lowest-risk, highest-friction feature.
Data slicing: you migrate one data domain at a time, keeping the rest on the legacy schema until its turn comes.

None of this works without observability, feature flags, fast rollback, and shadow writes that let you compare new and old behavior before you trust the new path alone.

What rewrites actually cost and how to control the risk

The honest cost of a rewrite rarely shows up in the original estimate. Three drivers dominate: running both systems in parallel while the new one catches up, developer time split between new features and migration work, and the reconciliation effort needed to confirm the new system produces the same results as the old one.

Define exit criteria for any parallel run before you start it: record parity thresholds, a reconciliation window, and explicit sign-off gates.
Use shadow writes so the new system processes real traffic without serving it, giving you production-equivalent validation before cutover.
Automate reconciliation between old and new outputs rather than checking by hand, which does not scale past the first few weeks.
Watch for the Second-System Effect: a rewrite tends to accumulate scope as engineers fix every old complaint at once, which is how a three-month project becomes a year.

Technical debt has a measurable interest rate. Research replicating developer productivity impact finds that technical debt increases the time developers spend on testing, analysis, and refactoring, which is exactly the cost you are trying to avoid by choosing the wrong migration path. DORA’s 2024 research adds a sharper warning: AI adoption alone correlated with a slight drop in delivery throughput and delivery stability, meaning tooling cannot substitute for the basics of small batch sizes and solid testing during a migration.

A scorecard and checklist you can run this week

Bring these items into your next planning meeting rather than a slide deck full of opinions; consider incorporating insights from backlog refinement in Scrum to make refactoring and incremental modernization safer.

Test coverage threshold: confirm coverage on the critical paths you are about to touch, and set a minimum before migration work starts.
Seam identification: list every module boundary that already exists or can be engineered within two sprints.
Rollback plan: write down, in one paragraph, exactly how you undo the first production change.
Parallel-run cost estimate: price out running both systems for the length of your planned migration window.
Stakeholder sign-off gates: name who approves moving from shadow writes to full cutover, in writing, before you start.

Score each factor from the matrix above, total the weighted result, and let the threshold decide your path: under 2.5 means refactor, 2.5 to 3.5 means strangler, above 3.5 with corroborating evidence means a scoped rewrite.

What senior-led delivery looks like in practice

Decisions like this tend to go wrong when the people scoring the rubric were not around when the system was built and will not be around to maintain what replaces it. Senior engineers remain involved on projects from the initial consultation through handover to ensure continuity of judgment.

Our Habitects AG case study shows a full-ownership technical migration where the choice between incremental extraction and a scoped rewrite was made against the kind of evidence this framework describes, not against a preference for new technology.
Our legacy migration and replatforming work and technical due diligence engagements apply this same rubric before recommending either path.

How we help teams choose and execute the right path

We run audits and discovery sprints that score your system against the exact factors above: test coverage, seams, deployment risk, and data coupling, so the rewrite or refactor decision rests on evidence rather than instinct. When the answer is incremental modernization, our legacy migration and replatforming work operationalizes the Strangler Fig with shadow writes and reconciliation built in from day one. When a scoped rewrite is the honest answer, senior engineers stay on the project from first scoping conversation through handover. Check our pricing page for the Guidance and Intensive engagement options, or look at our case studies to see how the framework played out on real projects.

FAQ

What is the difference between refactoring and rewriting?

Refactoring changes a system’s internal structure in small, tested steps while keeping its external behavior the same. Rewriting replaces the system entirely, usually starting from a new codebase or architecture, which carries far more risk and cost than incremental change.

What does refactor mean?

Refactoring means restructuring existing code to improve its design, readability, or maintainability without changing what it does from the outside. Tests confirm that behavior stays constant while the internals improve.

What is another word for “refactor”?

Common alternatives include “restructure,” “clean up,” or “modernize incrementally,” though none capture the testing discipline that distinguishes true refactoring from a casual rewrite of a small section. In practice, teams use “refactor” specifically to signal that behavior is protected by tests throughout the change.

Is ChatGPT good at refactoring code?

AI tools can speed up mechanical refactoring tasks like renaming, extracting functions, or suggesting cleaner patterns, but they do not replace the testing and review discipline that makes refactoring safe. DORA’s 2024 report found that AI adoption alone correlated with lower delivery throughput and stability, underscoring that foundational practices like small batch sizes and strong test coverage still carry the migration, not the tool.

When should I choose a Strangler Fig approach instead of either extreme?

A Strangler Fig approach fits when your decision matrix score lands in the middle range: some seams exist but coupling is still significant, or test coverage is partial rather than comprehensive. It lets you replace the system in slices, validating each one in production before committing to the next, which is why Martin Fowler’s original description frames it as the lower-risk default over a full rewrite.

Sources

Have a project this touches on?

A free 10-minute call is the fastest way to find out whether we are the right studio for it.

Book a free 10-min call

Keep reading