Refactor vs. rewrite: a decision guide for your backend

1. Name the constraint you need to remove

Begin with a statement that can be tested. “The backend is old” is a description. “This workflow cannot meet its response-time target under the expected workload” names a requirement. “Every billing change risks altering existing customer contracts” names a different constraint and needs different evidence.

• What must the product do that it cannot reliably do today?
• Which users, contracts, integrations, or operational responsibilities depend on the current behavior?
• What has already been tried, and what did it establish?
• What must keep shipping while the change is underway?
• What evidence would show that the constraint has been removed?

A performance investigation may reveal one expensive access pattern. A reliability review may reveal an unsafe release process. Neither finding automatically requires a new architecture. Use the diagnosis to set the boundary of the decision.

2. Compare three realistic paths

Refactoring changes internal structure while preserving externally observable behavior. If you are also changing the product’s rules, record that as a separate decision so the team knows which differences are intended.

Reference: Martin Fowler: Refactoring definition

These choices are not determined by language preference or line count alone. A large, understood system can be easier to improve than a small one with unclear data ownership. The useful comparison includes what you know, what you must learn, and how much exposure each step creates.

3. Recover the behavior before replacing the implementation

An old system often contains business rules that never made it into a specification. Look at production workflows, support history, integration contracts, and unusual records. Ask which edge cases represent intentional customer commitments and which are defects people have learned to work around.

Create checks around the boundaries you intend to change. For a billing workflow, that may include representative contract rules, rounding, retries, failure recovery, and reconciliation. For an API, it may include response semantics and client expectations as well as status codes. A test that confirms a new component starts does not establish behavioral parity.

If you cannot yet describe the important behavior, fund discovery first. Rewriting unknown rules in a newer stack does not make them known.

4. Use staged replacement when a boundary makes it possible

The strangler fig approach introduces a replacement gradually while the old system continues operating. Martin Fowler describes it as a way to spread investment and feedback over the course of modernization. The principle can be useful without turning every application into a fleet of microservices.

Reference: Martin Fowler: Strangler Fig

A controlled routing boundary lets selected operations use the new implementation while others remain on the old path. AWS’s pattern guidance also identifies the routing layer as a potential bottleneck or failure point. That extra component needs its own operational plan.

Reference: AWS Prescriptive Guidance: Strangler fig pattern

Choose a slice with a meaningful outcome and manageable dependencies. Avoid calling it small merely because it has few endpoints. A single endpoint that changes balances across several systems can be harder to migrate than a larger read-only feature.

• Define which implementation owns each operation during the transition.
• Specify where writes go and how readers see a consistent state.
• Plan how historical records are handled and how discrepancies are detected.
• Set a limited rollout boundary and a recovery path.
• State when the old implementation and temporary compatibility code can be removed.

5. Count the migration work in the estimate

Compare complete delivery paths. The rewrite estimate should include understanding existing rules, building the replacement, testing integrations, moving or reconciling data, operating two paths where necessary, training the team, and retiring the old system. The refactoring estimate should include compatibility checks and the cost of working within current boundaries.

Data changes deserve particular attention. Switching traffic back does not automatically undo writes made by the new system. Before rollout, determine whether the old implementation can read the new records and how interrupted or duplicated operations will be reconciled. Some changes require forward recovery rather than a simple rollback.

Reserve room for discoveries. Present assumptions and ranges instead of treating unknown behavior as zero work. If the business can support only one team, explicitly account for maintaining the current product while that team builds its replacement.

6. Test the decision on one capability

A full rewrite may be proposed because reporting exposes uncomfortable design choices. Start by measuring the reporting workload. A focused query change could solve the immediate problem. If the reporting needs cannot fit the transactional model, a separate read-oriented capability might be a useful staged experiment.

Before choosing that path, answer how fresh the reporting data must be, who owns transformations, how discrepancies are detected, and how customers return to the existing report if the new path fails. A new data store is not an improvement unless it meets those requirements at an acceptable operating cost.

Run a bounded experiment using representative, sanitized data. Compare correctness, performance, implementation effort, and operational burden. If the new boundary produces more coordination work than expected, revise the plan before expanding it. The experiment is valuable when it changes the decision, not only when it validates the initial preference.

Write the decision before committing the roadmap

Business constraint and evidence:
Behavior that must remain compatible:
Options considered:
Smallest experiment for each credible option:
Data ownership and migration plan:
Dependencies and ongoing support needs:
Success criteria and stop criteria:
Rollout and recovery approach:
Estimated effort, assumptions, and unknowns:
Decision owner and review date:

Choose the approach that gives the team a credible route to the required outcome with risks it can manage. Revisit the decision when new evidence arrives. A well-scoped backend rescue may combine immediate stabilization, focused refactoring, and one staged replacement; the useful plan is the one that fits the actual constraint.

References and further reading

• Martin Fowler: Refactoring definition
• Martin Fowler: Strangler Fig
• AWS Prescriptive Guidance: Strangler fig pattern