blog single

Rebuild or refactor: how to decide

Engineering team reviewing an old system diagram

Published on:

February 12, 2026

TAG:

PLATFORM ENGINEERING

BY:

Edgeless Team

Read Time:

5 MIN READ

post detail

Every mature codebase reaches a point where the team debates a rewrite. The argument for rebuilding is easy to make: the current system is slow to change, the original authors have left and every new feature takes longer than the last. The argument against is equally strong: rewrites often take twice as long and deliver less than planned.

What refactoring actually means

Refactoring is changing the structure without changing the behavior. It happens in small steps, each one covered by tests, and the system stays in production throughout. A rebuild replaces the structure and often the technology, with a period where two systems exist and a migration between them.

The distinction matters because the risk profiles differ. Refactoring spreads risk across many small changes. A rebuild concentrates risk in a launch, when every workflow moves at once. A team can refactor for a year and stop at any point with a working system. A rebuild has a long middle where nothing is usable.

Most requests for a rewrite are really requests for relief from a specific pain. Slow releases, a dependency that blocks an upgrade, a module nobody understands. Identifying that pain often turns a rewrite into a targeted refactor with a much smaller scope.

Measure the cost of the current system

Before choosing, put numbers on the pain. Time from request to release. Hours per week spent on workarounds. Incidents per quarter. The number of changes that require a specialist. The age of the dependencies and the security risk they carry.

Compare those numbers with what the business needs next year. If the current system can support the roadmap with a manageable amount of work, a refactor is probably enough. If it cannot support the next three features at all, the case for a rebuild is stronger.

Include the cost of the rebuild itself. The team that builds the new system is not shipping new features, and the business funds two systems during the migration. A rebuild that takes eighteen months carries eighteen months of frozen product work, which is a cost that rarely appears in the estimate.

The signals that favor a rebuild

A rebuild is reasonable when the technology is unsupported and cannot be upgraded in place. When the data model is fundamentally wrong for the business and every feature works around it. When the system cannot be tested, deployed or observed, and the cost of adding those abilities is close to the cost of a new build.

It is also reasonable when the business has changed so much that the current system encodes a process that no longer exists. In that case, refactoring preserves assumptions that are now wrong, and the team spends years improving the wrong thing.

The platform is unsupported or cannot receive security updates.
The data model blocks the roadmap rather than slowing it.
Deployment and testing cannot be added without a structural change.
The business process has changed beyond recognition.
The team that understands the system has left and cannot be replaced.
The cost of the workarounds exceeds the cost of a replacement.

Why rewrites fail

Rewrites fail when they try to reproduce every behavior of the old system. The old system contains years of exceptions that nobody documented, and the new one discovers them one by one. The scope grows, the launch slips and the team loses confidence.

They fail when the new system has no real users until the end. Feedback arrives after the design is fixed, and the changes needed to make it usable become a second project. A staged migration with real users on the new system early is much safer.

They fail when the organization does not change the practices that made the old system difficult. A new codebase with no tests, no deployment pipeline and no ownership becomes the old codebase in three years. The rewrite buys time, not a permanent fix.

Architecture diagram split between old and new systems — A rebuild needs a migration path with real users on the new system early. A big bang launch concentrates all the risk on one day.

A middle path: strangle the old system

The safest rebuild is gradual. Put a stable boundary around the old system and move one capability at a time to the new one. Route traffic at the boundary so both systems can run in parallel. When a capability moves, the old code for it is removed.

This pattern lets the business keep shipping while the platform changes. It also produces evidence early: the first capability proves the new architecture, the deployment pipeline and the team's ability to operate it. If something is wrong, the cost of changing direction is one capability, not the whole program.

It requires discipline at the boundary. A clear interface, a shared data model and a plan for each capability. Without that discipline, the two systems become entangled and the migration stalls halfway, which is the most expensive outcome of all.

Making the call

Write a one page decision record: the pain, the options, the evidence, the cost and the conditions that would change the answer. Review it with the people who maintain the system and the people who fund it. A written record prevents the same debate from returning every quarter.

Set a review point. If the chosen path has not produced the expected improvement by a specific date, reassess. A decision with a review date is easier to defend than a commitment with no exit.

Estimating a rebuild honestly

A rebuild estimate is usually built from the features the team can see. The expensive part is the behavior nobody documented: the report that runs on the first Monday, the integration that depends on a field with an unusual format, the customer who uses a workflow from 2018.

Add a discovery phase that inventories the current behavior, including the exceptions. Count the integrations, the scheduled jobs, the imports and the manual steps that touch the system. Those counts are a better predictor of effort than the number of screens.

Estimate the migration as a project of its own. Moving data, reconciling history, retraining users and running both systems in parallel all take time. A rebuild estimate without a migration line is not a complete estimate.

What to do with the old system

Keep the old system read only for a period after the move. People will need to look up a record from last year, and a read only archive is cheaper than importing every historical detail into the new model. Set an end date for the archive and put it in the plan.

Freeze changes on the old system at a defined point. A rebuild that also has to absorb new features from the old system will never finish. Agree what counts as a critical fix and route everything else to the new roadmap.

Celebrate the retirement. Turning off the old system is the moment the cost saving begins. Without a clear retirement date, the old system stays alive for years and the business pays for both.

Refactor when the structure is wrong. Rebuild when the assumptions are wrong. Measure both against the cost of the current workarounds.
Edgeless Team

We assess old systems, model the cost of refactoring against a staged rebuild, and run migrations that keep the product shipping.

Explore software development

The right answer is usually smaller than the first proposal. Find the pain, measure it and choose the smallest change that removes it. That discipline is what keeps a platform decision from becoming a two year detour.

Refactoring

Architecture

Engineering

Rebuild or refactor: how to decide

Let's Talk About Your Project