Remediate technical debt by measuring it against business risk rather than code aesthetics, then paying it down continuously alongside feature work with a strangler approach. Wholesale rewrites usually fail because they discard accumulated domain knowledge and freeze value delivery for the duration.
Measuring debt in business terms
Debt metrics that only engineers read do not get funded. Translate them: lead time from merged change to production, change failure rate, mean time to restore, defect density in the modules you touch most, and the number of days a new engineer needs before their first meaningful production contribution.
The most useful single lens is the intersection of high change frequency and low comprehension. Use version history to find the files changed most often, then overlay complexity and test coverage. That intersection is where business velocity is actually leaking.
This framing matters because it produces a ranked list rather than a complaint. Leadership can act on a ranked list.
Sequencing remediation
Start with the safety net, not the code. Without automated tests, refactoring is indistinguishable from breaking things. Add characterisation tests that pin current behaviour, including behaviour you consider wrong, so that later changes are deliberate rather than accidental.
Then improve the build and deployment path. Continuous integration that takes an hour, manual releases and environment drift multiply the cost of every subsequent change. Fixing delivery amplifies everything else you do afterwards.
Only then address structure: extract modules, invert dependencies, remove duplication and replace cross-cutting hacks with proper seams. Structural change is much cheaper once tests and pipelines make it safe and fast.
- Add characterisation tests to lock in current behaviour before refactoring.
- Fix build, test and deployment speed early to amplify later work.
- Refactor along the seams identified by change frequency.
- Budget remediation continuously rather than as a one-off project.
Incremental replacement with the strangler pattern
Where replacement is necessary, route a stable interface in front of the legacy system and move capability behind it one slice at a time. New traffic goes to the new implementation while legacy handles the remainder, and you migrate in reverse order of risk so confidence builds before the hard parts.
The critical requirement is a seam you control: an API gateway route, a facade module, or a stable public interface. Without a seam you cannot move traffic gradually, and the migration becomes a single high-risk cutover.
Because both implementations exist for a period, the legacy system must keep working, which means resisting the urge to fix it. Stabilise and freeze; do not enhance.
| Approach | Risk | Time to value | Best when |
|---|---|---|---|
| Continuous refactoring | Low | Immediate | Code is understood, tests exist |
| Strangler replacement | Medium | Incremental | Seams exist, behaviour is stable |
| Module extraction | Medium | Medium | Dependency tangles block change |
| Full rewrite | High | Late and uncertain | Domain model itself is wrong |
| Replatform only | Low | Fast | Code is fine, infrastructure is not |
Avoiding the rewrite trap
The classic rewrite failure is not technical, it is informational. The legacy system encodes years of domain decisions, edge cases and regulatory nuances, and its code is often the only surviving specification. A rewrite team starts by re-deriving knowledge the original team already had, and discovers the edge cases only when production traffic arrives.
A second failure is the freeze. During a two-year rewrite the legacy system receives no improvements, competitors keep shipping, and the business loses patience before the new system is done. If you must rewrite, keep the legacy system on a maintenance path and deliver the new system in production-visible slices.
Rewrite when the domain model is genuinely wrong rather than merely inconvenient, and when you can articulate why incremental change cannot get you there.
- Write down why incremental change is impossible before choosing a rewrite.
- Preserve the legacy system as executable specification while it still runs.
- Deliver the replacement in slices that reach production early.
- Keep funding the business as usual backlog throughout.
Frequently asked questions
How do I convince leadership to fund technical debt work?
Express it in delivery terms they already track: lead time, change failure rate, time to restore service and ramp-up time for new engineers. A ranked list tied to those numbers is fundable; a code quality score is not.
Is it ever worth rewriting a legacy system from scratch?
Occasionally, when the domain model itself is wrong and incremental change cannot reach the required behaviour. Even then it should be delivered incrementally rather than as a single multi-year cutover.
What percentage of capacity should go to technical debt?
A common starting point is 15 to 25 percent of engineering capacity, adjusted by the measured defect density and lead time. Treating it as a standing allocation rather than a project keeps it from being cancelled when deadlines tighten.
References
Engineer your next strategic platform
Estimate your project investment and delivery timeline instantly, or schedule an architectural discovery call with our engineering leadership.