Refactor vs Rebuild | Ampity Software Engineering
A structured assessment across five dimensions, four options with real cost estimates, and a recommendation with the reasoning. Not a framework. A decision.
The debate consumes energy in every planning cycle. The wrong call in either direction is expensive.
Rewrites are tempting. Starting fresh feels like finally doing it right. More often, the rewrite takes twice as long as estimated and the new system eventually accumulates its own problems.
Wanting to rewrite because the code is hard to read
The real problems are missing tests and poor observability. A rewrite inherits both if the process doesn't change. The code isn't the issue.
Patching a system with architectural problems
Each patch makes the next one harder. The ceiling gets lower with every sprint. Refactoring cannot fix a structural problem.
Underestimating the transition period
The old system keeps running while the new one is being built. Both require engineering attention. That cost is rarely in the estimate.
A decision made on emotion, not evidence
Engineers who built the current system resist. Engineers who didn't want a rewrite. The debate runs for months. What's missing is a way to separate "annoying to work with" from "actively preventing the business from moving forward."
We assess the system, lay out the real options with costs, and give you a recommendation.
The assessment separates what is annoying from what is actively preventing the business from moving forward. Those are different problems. Most teams conflate them.
Structured assessment across five dimensions
Code quality, test coverage, architectural constraints, deployment complexity, domain model accuracy. Each evaluated independently. The score determines which category you are in, not the loudest voice in the planning meeting.
Four options with real cost and risk estimates
Targeted refactoring, incremental strangling, partial rebuild, full rebuild. For each, we estimate real cost and risk, including the transition period where you are maintaining two systems. That number is usually missing from rebuild proposals.
A recommendation with the reasoning
We give you our recommendation, not a decision matrix. If the assessment points to a full rebuild, we say so. If refactoring is the right answer, we say that too.
The transition cost of maintaining two systems is included in every rebuild estimate. That is what changes the math.
A clear-eyed decision, made with full information about the tradeoffs.
No more "should we or shouldn't we" consuming energy in every planning session. The debate has been resolved and the reasoning is documented.
System assessment across five dimensions
Written findings for each dimension with the evidence behind the score. Code quality, test coverage, architectural constraints, deployment complexity, domain model accuracy.
Cost and risk estimates for all four options
Targeted refactoring, incremental strangling, partial rebuild, full rebuild. Each with effort, timeline, risk, and transition costs. Numbers you can take into a planning discussion.
Recommendation with documented reasoning
What we found, how we weighed it, and why we landed where we did. Documented so the decision survives the next team change.
Results
Diagnosed
Code, tests, architecture, deployment, data, domain boundaries, and operational evidence are reviewed together.
Compared
Repair, incremental replacement, partial rebuild, and full rebuild use the same cost, risk, and transition criteria.
Decision-ready
The recommendation states its assumptions, trigger points, rejected options, evidence gaps, and first reversible step.
Decision evidence
The recommendation includes source observations, option costs, transition states, risks, rejected alternatives, trigger points, and the first reversible action.
Related services
System Architecture Design
If the assessment points to a rebuild, the next question is what the target architecture looks like. Domain-first design with an executable migration path.
Platform Modernization
Executing the migration once the decision is made. Whether the answer was incremental strangling, partial rebuild, or full rebuild.
Technology Stack Evaluation
If a rebuild is the answer, the technology choices for the new system require the same structured approach applied to stack selection.
Frequently asked questions
How do you decide whether to refactor or rebuild software?
Compare targeted repair, incremental replacement, partial rebuild and full rebuild against the same evidence: domain fit, architectural limits, tests, change cost, operational risk and transition effort. The recommendation should explain why an option fits and what evidence would change it.
Can an application be modernized while it remains live?
Often, yes. Incremental replacement can move selected functions behind stable interfaces while the existing system continues operating. Data authority, compatibility, traffic routing, rollback and the cost of maintaining both paths must be planned before implementation.
What costs are commonly missed in a rebuild estimate?
Running old and new systems together, data migration, integration changes, training, regression testing, support and decommissioning are often missed. A rebuild estimate should include these transition costs as well as the work to create the replacement.
Does old technology automatically justify a rewrite?
No. Age alone does not establish business harm. Unsupported dependencies, security exposure, repeated incidents or constraints on required changes may justify intervention, but the least disruptive option that addresses the evidenced problem should still be considered.