A CTO looks at a tangled, aging system everyone hates and makes the call that feels obvious: rewrite it from scratch, clean this time. Two years later the rewrite is late, the old system is still running because it cannot be turned off, and the new one has re-implemented only part of the behavior, badly. The decision felt bold. It was the single most common way large engineering efforts fail.
This is more than a bad project. It is a failure to weigh the decision honestly.
The rewrite-versus-refactor decision is more than a gut call about whether code is worth saving. It is a deliberate framework that weighs the value hidden in the existing system, the true cost and failure rate of rewrites, and the incremental path of refactoring, so the choice rests on evidence rather than the urge to start clean.
However, many teams default to a rewrite because the old code is unpleasant, and discover that the rewrite runs long, loses behavior, and leaves them running both systems.
Energy Platform Replatformed to Multi-Region Cloud
A migration playbook for VPs of Infrastructure responsible for resilience and regulatory geography.
If you are a CTO or VP of Product Engineeringresponsible for the fate of an aging system, the intent of this article is:
- Explain why rewrites fail far more often than they feel like they will
- Show the framework for choosing rewrite, refactor, or a middle path
- Lay out how to tell whether your instinct to rewrite is justified
To do that, let's start with the basics.
What Is the Rewrite vs Refactor Decision? The Basic Definition
At a high level, the rewrite-versus-refactor decision is the choice between rebuilding a system from scratch and improving it incrementally in place. A rewrite replaces the system; a refactor restructures it while preserving behavior. The decision hinges on the value embedded in the current system, the realistic cost and risk of each path, and whether an incremental approach can reach the goal.
To compare:
Demolishing and rebuilding an old house is sometimes right, but it is slow, expensive, and you lose everything about the house that quietly worked. Renovating room by room is often faster to value and keeps you living in the house throughout. Most teams reach for demolition because the house annoys them.
Why Is a Deliberate Decision Necessary?
Issues that a deliberate decision addresses or resolves:
- The urge to start clean overrides the evidence
- A rewrite discards years of embedded, tested behavior
- Rewrites run far longer than expected
Resolved Issues by a Deliberate Decision
- The value in the existing system is weighed
- Rewrite cost and failure rate are faced honestly
- Refactoring is considered as a real option
Core Components of the Decision
- An honest assessment of the existing system's value
- A realistic estimate of rewrite cost and risk
- An evaluation of the incremental refactor path
- A decision tied to business goals and constraints
- Disciplined execution of whichever path is chosen
Modern Tools for the Decision
- Code analysis to gauge complexity and coupling
- Delivery metrics to quantify the drag
- The strangler-fig pattern to make refactoring viable
- AI assistance that lowers the cost of refactoring and controlled modernization
- Characterization tests to protect behavior on either path
The tools inform the decision; weighing value, cost, and risk into a choice is leadership judgment.
Other Core Issues They Will Solve
- Refactoring keeps the system running throughout
- Incremental change is reversible, so risk is controlled
- The decision can be defended with evidence
In Summary: A deliberate rewrite-versus-refactor decision serves the business rather than the urge to escape unpleasant code.
Importance of the Decision in 2026
AI has shifted the cost of both options, which makes the old instinct even less reliable. Four reasons explain why it matters now.
1. Rewrites still fail at high rates.
The base rate of large rewrites running long, losing behavior, or failing outright has not improved. The instinct to rewrite remains the most common expensive mistake.
2. AI lowered the cost of refactoring.
AI assistance can make incremental improvement and controlled modernization cheaper, tilting the math toward refactoring for many systems.
3. Fast generation tempts more rewrites.
Because AI makes producing new code feel cheap, teams underestimate the true cost of a rewrite, which is behavior preservation, not typing.
4. The value in old systems is under-credited.
Years of tested behavior and edge-case handling are easy to dismiss when the code is ugly, and expensive to rediscover after it is gone.
Traditional vs. Modern Decision-Making
- Rewrite because the code is bad vs. decide on value, cost, and risk
- Rewrites feel fast vs. rewrites carry a high, faced failure rate
- Refactoring is second-best vs. incremental refactoring is often stronger
- A gut call vs. an evidence-based framework
In summary: A modern approach is an evidence-based decision that treats refactoring as a first-class option, not a frustration-driven rewrite instinct.
Details About the Core Components of the Decision: What Are You Designing?
Let's go through each layer.
1. Value Assessment Layer
Old code often encodes hard-won behavior.
Value decisions:
- Tested logic and edge cases embedded over years
- Business rules that live only in the code
- What a rewrite would have to rediscover
2. Rewrite Cost Layer
Rewrites are almost always larger than they feel.
Cost decisions:
- Reproducing all existing behavior, not the happy path
- The realistic timeline, including the long tail
- The honest base rate of rewrites going wrong
3. Refactor Path Layer
The frequently underrated option.
Refactor decisions:
- Restructuring in place while preserving behavior
- The system kept running throughout
- Each step reversible
4. Decision Layer
The right answer depends on what the business needs.
Decision factors:
- Which path serves the actual goal
- Time, risk tolerance, and resources
- Middle paths like strangler-style modernization
5. Execution Layer
A chosen path still needs discipline.
Execution decisions:
- A rewrite only with behavior capture and equivalence checks
- A refactor that is incremental, tested, and reversible
- Reassessment as evidence accumulates
Benefits Gained from a Deliberate Decision
- Value in the existing system preserved when it should be
- Rewrite risk faced rather than discovered
- A choice defensible on evidence
How It All Works Together
Facing an aging system, the team assesses the value embedded in it, the tested behavior and business rules a rewrite would have to rediscover. They estimate the true cost and failure rate of a rewrite honestly, including the long tail of reproducing all existing behavior. They evaluate the refactor path, restructuring in place while keeping the system running and each step reversible, and consider middle paths like strangler-style modernization. The decision is tied to business goals and constraints, not to frustration with the code. Whichever path is chosen is executed with discipline and reassessed as evidence accumulates.
Common Misconception
Ugly, painful code should be rewritten.
Ugliness is not evidence for a rewrite. Old code is often ugly precisely because it accumulated the handling of real edge cases the business needs. A rewrite discards that hard-won behavior and takes far longer than it feels like it will. The pain of working in the code is real, but it usually argues for refactoring.
Key Takeaway: The urge to rewrite is triggered by frustration, and frustration is not evidence, so the decision must rest on value, cost, and risk.
Real-World Decision-Making in Action
Let's take a look at how the rewrite-versus-refactor decision operates with a real-world example.
We worked with a team poised to rewrite an aging system everyone disliked, with these constraints:
- Preserve the tested edge-case behavior in the old code
- Avoid repeating a stalled rewrite attempt
- Stop running two systems indefinitely
Step 1: Assess the Embedded Value
Measure what the system actually held.
- Tested behavior and edge cases cataloged
- Business rules living only in the code identified
- What a rewrite would need to rediscover estimated
Step 2: Estimate Rewrite Cost Honestly
Face the real number.
- Reproducing all behavior scoped, not the happy path
- A realistic timeline including the long tail set
- The base failure rate of rewrites confronted
Step 3: Evaluate the Refactor Path
Take incremental change seriously.
- A restructuring that preserved behavior mapped
- The system kept running throughout
- Each step made reversible
Step 4: Decide Against the Business Goal
Choose on evidence.
- Each path weighed against the actual goal
- A strangler-style incremental modernization chosen
- The frustration-driven full rewrite rejected
Step 5: Execute With Discipline
Follow the choice safely.
- Behavior preserved and verified at each step
- The plan reassessed as evidence accumulated
- Old parts retired only once replaced and proven
Where It Works Well
- Any aging system where a rewrite instinct is driven by frustration
- Systems holding years of embedded, tested behavior
- Situations where continuity and reversibility matter
Where It Does Not Work Well
- Systems on a truly dead platform where incremental change is impossible
- Cases where the business genuinely needs different behavior
- Small systems that can be rebuilt trivially and safely
Key Takeaway: The framework pays off wherever the rewrite instinct is strong and the existing system holds real value, which is most of the time.
Common Pitfalls
i) Rewriting because the code is ugly
Mistaking frustration for evidence leads to discarding years of tested behavior for a rewrite that runs long and loses logic. Decide on value, cost, and risk.
- Embedded edge cases lost
- Timeline underestimated
- Old system cannot be retired
ii) Underestimating rewrite cost
Treating a rewrite as rebuilding the happy path ignores that the real work is reproducing all existing behavior, which is most of the cost.
iii) Dismissing refactoring
Treating incremental improvement as second-best overlooks that it is often faster to value, lower risk, and reversible.
iv) Ignoring the base rate
Assuming this rewrite will beat the odds, when large rewrites fail at high rates, is how the most common expensive mistake gets made again.
Takeaway from these lessons: The rewrite that feels obviously right is exactly the decision that most often goes wrong. Weigh value, cost, and risk before committing.
Rewrite vs Refactor Best Practices: What High-Performing Teams Do Differently
1. Decide on evidence, not frustration
Weigh value, cost, and risk rather than acting on the pain of working in the code.
2. Respect the value in old code
Treat years of embedded, tested behavior as an asset a rewrite would have to rediscover expensively.
3. Face the rewrite base rate
Confront the honest failure rate and true cost of rewrites before choosing one.
4. Treat refactoring as first-class
Evaluate incremental, reversible improvement as a real option, often the stronger one.
5. Choose middle paths when they fit
Use strangler-style modernization to get rewrite-level renewal with refactor-level risk where appropriate.
Logiciel's value add is helping teams make the rewrite-versus-refactor call on evidence, and execute whichever path they choose without losing behavior.
Takeaway for High-Performing Teams: Distrust the rewrite instinct precisely because it feels so obviously right, and decide on the numbers instead.
Signals You Are Deciding Well
How do you know your decision rests on evidence rather than frustration? Not by how bold it feels, but by what you weighed. These are the signals that separate a deliberate decision from a frustrated one.
You can state the embedded value. You know what a rewrite would have to rediscover.
You faced the true rewrite cost. Your estimate includes all behavior and the long tail.
Refactoring was seriously evaluated. Incremental change got a fair hearing, so you avoided rewrite bias.
The choice ties to a business goal. The decision serves the goal, not the annoyance.
You considered a middle path. Strangler-style modernization was on the table.
Adjacent Capabilities and Connected Work
This work does not exist in isolation. The rewrite-versus-refactor decision connects to modernization, technical debt management, and architecture, because it governs how a system's health is restored. Treating them as separate is the most common scoping mistake.
The modernization discipline that preserves behavior is how a chosen incremental path is executed. The debt portfolio thinking that prioritizes fixes informs whether a system's debt warrants a rewrite or a refactor. The architectural understanding that shaped the system informs what renewal it needs. Naming these adjacencies upfront lets leadership see the decision, modernization, and debt management as one concern for the long-term life of a system.
The common mistake is treating each adjacency as someone else's problem. The modernization that executes the choice is your problem. The debt analysis that informs it is your problem. The architecture that shapes it is your problem. Pretend otherwise and the most common expensive mistake repeats. Own the adjacencies you depend on, partner with the teams that hold them, and share the timeline.
Conclusion
Getting this decision right means distrusting the choice that feels obvious. The urge to rewrite is triggered by frustration with unpleasant code, and frustration is not evidence. Old systems hold years of tested behavior, rewrites fail at high rates, and refactoring is often the stronger path. The teams that get it right decide on value, cost, and risk.
Key Takeaways:
- The rewrite instinct is the most common expensive mistake, because it feels obviously right
- Ugly code is not evidence for a rewrite; it often encodes valuable, tested behavior
- Refactoring and middle paths deserve first-class consideration against an honest rewrite cost
Making the decision well requires weighing embedded value, true rewrite cost, and the refactor path against business goals. When done correctly, it produces:
- Value in the existing system preserved when it should be
- Rewrite risk faced rather than discovered
- Refactoring used where it serves better
- A choice you can defend on evidence
Energy Operator Built Real-Time Grid Signal Pipeline
A real-time grid pipeline playbook for Heads of Data Platform.
What Logiciel Does Here
If you are about to rewrite a system because the code is painful to work in, pause and weigh the embedded value, the true rewrite cost, and the refactor path before you commit.
Learn More Here:
- AI-Powered Code Modernization: Legacy to Modern Without the Rewrite Risk
- Technical Debt Management: A CTO's Portfolio Approach
- Spec-Driven Development: How Teams Ship AI-Assisted Code That Lasts
At Logiciel Solutions, we work with CTOs and VPs of Product Engineering on rewrite-versus-refactor decisions and executing them without losing behavior. Our reference patterns come from production deployments.
Explore how to make the right renewal decision for your system.
Frequently Asked Questions
Why do rewrites fail so often?
Because the real work is reproducing all existing behavior, including years of undocumented edge cases, not writing new code. That is consistently underestimated, so rewrites run long, lose behavior, and leave both systems running.
Isn't ugly code a reason to rewrite?
Usually not. Code is often ugly because it accumulated the handling of real edge cases the business needs. Frustration with the code is real but is not evidence; decide on value, cost, and risk.
When is a rewrite actually the right call?
When the platform is truly dead and incremental change is impossible, or when the business genuinely needs different behavior rather than the preserved behavior of the existing system.
What is a middle path between rewrite and refactor?
Strangler-style modernization: incrementally replacing parts of the system behind a stable interface while preserving behavior. It offers rewrite-level renewal with refactor-level, reversible risk.
How does AI change the decision?
AI lowers the cost of refactoring and controlled modernization, which tilts the math toward incremental paths for many systems, while also tempting teams to underestimate the true cost of a full rewrite.
