Refactoring vs Rewriting Code: A Decision Framework for Tech Leaders

Section 01

Decision matrix: preserve structure or replace implementation?

Use this matrix to shortlist options. These are decision criteria, not measured success rates or guarantees.

Compare feasible options for the same required outcome. If refactoring cannot satisfy a mandatory requirement, a lower estimate does not make it a viable choice. If a component replacement can satisfy that requirement, ask what additional benefit justifies replacing the rest.

Section 02

Define refactoring and rewriting precisely

Martin Fowler's definition of refactoring centers on improving internal code structure while keeping observable behavior intact. Extracting a tangled calculation into clearly named functions can be refactoring. Changing the calculation's business rule is a separate functional change, even if both happen in the same project.

Rewriting means implementing selected capabilities again. A replacement may preserve existing behavior, intentionally change it, or retire behavior the business no longer needs. Record which behavior to preserve, change, or retire so the team can distinguish missing features from approved removals.

Fowler's Strangler Fig description, updated August 22, 2024, explains how to move behavior gradually into new code, find boundaries, and use temporary architecture while old and new coexist. It does not establish a universal cost advantage or success percentage.

For the delivery sequence after choosing an incremental approach, see incremental legacy modernization. The broader legacy application modernization research covers other modernization strategies, including platform changes.

Section 03

Gather evidence before choosing an approach

Identify the business outcome, the current baseline, and a measurable acceptance condition. For example, a team might need to change pricing rules without touching unrelated order-processing code. Investigate whether the difficulty comes from tangled logic, shared data, an unsupported dependency, or unclear requirements. Each suggests different work.

Gather evidence that distinguishes the options:

• Examine a recent feature change: which modules, integrations, and tests had to change, and where did the team wait or rework?
• Identify critical business behavior, including exception handling, batch jobs, permissions, and historical data rules. Ask operators and domain experts to check findings from the code and production records.
• Test platform assumptions. An old framework version may permit an upgrade; an unsupported dependency may be replaceable without rebuilding the application.
• Measure performance under a representative workload. A database query bottleneck, external service limit, and system-wide architectural constraint need different remedies.
• Document release and recovery constraints. Include acceptable interruption, data recovery requirements, and who can approve changes in behavior.

Test coverage percentages and code size can inform discovery, but neither supplies a universal threshold for rewriting. A test suite that misses the billing exception path may provide little assurance about that path, regardless of its overall coverage.

A legacy system risk assessment can help frame the investigation. Use the findings to select a small representative trial: restructure one difficult change path, replace one isolated capability, or validate a proposed successor against a critical workflow. State what result would invalidate the preferred option before running the trial.

Section 04

Build a cost comparison with visible assumptions

Include discovery, engineering, validation, knowledge transfer, temporary operation, cutover, and retirement in each estimate. Identify costs that stop at each milestone and costs that continue until the old system is retired. Avoid multiplying lines of code by an unexplained industry rate: identical code counts can conceal very different behavior and integration requirements. For a separate assessment of remediation work, see the technical debt calculation formula; keep that assessment distinct from the full replacement budget.

Hypothetical business case

This invented example shows how to calculate the costs. Its figures are assumptions, not market prices, quotes, measured outcomes, or predictions.

Assume a company wants to reduce the effort needed to change its order-processing application while preserving the agreed workflows. In this example, discovery has provisionally found all three options feasible. Refactoring retains the platform; component replacement rebuilds the order-processing component; system replacement rebuilds the application. Value any additional capabilities separately.

All amounts are USD. The assumed loaded engineering cost is $15,000 per engineer-month. Testing and knowledge transfer are separate allowances for additional specialist and operator time, excluded from those engineering months. Parallel-operation allowances cover additional infrastructure and support beyond current operation. The cutover allowance includes rehearsals, release support, and retirement work. Durations and staffing are assumptions awaiting validation.

For component replacement, the subtotal is $300,000 + $90,000 + $30,000 + $48,000 + $35,000 = $503,000. Adding $100,600 contingency gives $603,600. The contingency is a planning assumption, not a probability of overrunning the budget.

Sensitivity and value limits

Suppose the component replacement needs three extra months with the same four engineers and additional parallel-operation cost. Engineering adds 4 × 3 × $15,000 = $180,000; overlap adds 3 × $12,000 = $36,000. With the same contingency assumption, the funding requirement becomes ($503,000 + $180,000 + $36,000) × 1.20 = $862,800, an increase of $259,200. This scenario assumes testing and other allowances remain sufficient; revise them if the delay changes scope.

Now assume steady-state monthly running costs after completion are $15,000 for refactoring and $10,000 for component replacement. The replacement's additional investment is $603,600 − $342,000 = $261,600. At assumed savings of $5,000 per month, simple recovery of that difference takes 52.32 months after those savings begin. At only $2,000 per month, it takes 130.8 months.

These calculations exclude financing, discounting, taxes, inflation, revenue effects, and the timing of savings during delivery. The funding table also excludes ordinary current-system running costs and forgone product work. Add those to a dated cash-flow comparison over the same horizon before making an investment decision. Faster delivery may create value, but saved engineering hours become cash savings only if spending actually falls; otherwise, show what work the released capacity enables.

A wider replacement could still be justified by a mandatory platform exit or a valuable new capability. A refactor could become more expensive if discovery reveals that the required change affects the whole application. Replace the assumptions with observed effort, supplier estimates, and trial results rather than treating this example as an answer for your system.

Section 05

Compare failure modes and acceptance evidence

Refactoring retains working code, but a structural change can still alter behavior accidentally. Require tests for the critical paths being changed and evidence that the new structure reduces the specific difficulty identified during discovery. Reorganizing code without making the next change easier is weak evidence of value.

Component replacement adds an interface between implementations. Examine who owns each write, how results are reconciled, and when the old component can stop serving traffic. A rollback that redirects requests may be insufficient after the replacement has written data the old component cannot interpret.

System replacement requires deciding which behavior to preserve and validating it across a wider scope. Undocumented business rules, changed integrations, and data conversion can expand that workload. List the required capabilities before estimating that work.

For every option, agree on acceptance evidence before estimating completion:

• Business owners approve required workflows and intentional behavior changes.
• Tests cover representative normal, exception, and recovery paths, with discrepancies investigated rather than silently accepted.
• Performance and reliability are checked against the actual operating requirements.
• Operations staff can support the result, and recovery has been rehearsed under the proposed data state.
• Retirement conditions identify remaining consumers, support obligations, and costs that will end.

A smaller change can limit exposure, but an incremental program can also stall in permanent coexistence. A single cutover can avoid a long overlap period, but it concentrates migration and acceptance work. Choose the release strategy using the system's dependencies and recovery constraints.

Section 06

Evaluate the delivery proposal

After testing the technical options, evaluate the team that will deliver the chosen scope. Use the legacy application modernization companies comparison to find candidates and ask each team to support its proposed approach with evidence.

For refactoring, request a representative change plan, tests of existing behavior, and results showing that the change makes the next feature easier to deliver. For component replacement, request interface contracts, data ownership, coexistence costs, and retirement criteria. For system replacement, request the business-rule inventory, acceptance scope, migration plan, and explanation of why narrower options cannot meet the requirement.

Ask for estimate assumptions and exclusions, comparable completed work, and differences between initial and final scope. A claimed success rate needs a defined denominator, outcome definition, and exclusions before it is useful. A fixed-price proposal can be credible if acceptance and change control are clear; a per-line estimate can be weak if it conceals discovery work.

Have the team demonstrate the proposed approach on your system in a trial before accepting a whole-project estimate.

Section 07

Frequently asked questions

Can we combine refactoring and rewriting?

Yes. A team may refactor code to expose a stable boundary, then replace the component behind it. Keep the behavior-preserving work separate from intentional functional changes so that tests and business approvals remain clear. The incremental modernization guide covers the subsequent delivery sequence.

Does an unsupported platform force a full rewrite?

Investigate an upgrade, replacement of the unsupported dependency, or migration of the affected component. Full replacement becomes a stronger candidate when those narrower options cannot meet the required support, security, or operating conditions.

How should we track whether the choice worked?

Compare results with the original baseline and acceptance conditions. Track effort for comparable feature changes, production incidents, recovery time, operating spend, and the business outcome the project was intended to enable. Record scope changes and competing explanations for improvement. Cleaner code alone does not prove financial return.

---

Evidence and scope, reviewed October 1, 2026: The definitions draw on Fowler's refactoring guidance and his August 2024 Strangler Fig article. The matrix is editorial decision guidance; all business-case figures are hypothetical assumptions. This article makes no empirical claim about comparative project success rates, median costs, or timelines.