Every team that inherits a legacy system eventually faces the same question: do we rebuild this from scratch, or do we modernise what we have? The decision feels binary. It is not. And getting it wrong is one of the most expensive mistakes a technology organisation can make.

Rebuild too eagerly and you burn eighteen months rewriting functionality that already worked. Migrate too conservatively and you spend years applying patches to a system that was never going to support your future needs. Both outcomes are depressingly common, and both are avoidable if you approach the decision with a structured framework instead of gut instinct.

The False Binary

The first thing to understand is that “rebuild versus migrate” is rarely a clean either-or choice. Most successful modernisation efforts end up as a hybrid: migrating some parts of the system while rebuilding others. The real question is not “which one?” but “which parts get which treatment?”

A typical e-commerce platform might have a payment processing system that works perfectly well — the logic is sound, it is well-tested, and it handles edge cases that took years to discover. Rebuilding that from scratch would be reckless. But the same platform might have a product catalogue system built on assumptions that no longer hold, with a data model that cannot support the business’s expansion into B2B sales. Migrating that system onto a new platform without rethinking the data model would be papering over the real problem.

The discipline is in assessing each major component of your system independently rather than making a single sweeping decision for the entire codebase.

When to Rebuild

There are genuine situations where a rebuild is the right call. They are less common than most developers think, but they do exist.

The Architecture Is Fundamentally Wrong

Sometimes the original system was built on assumptions that turned out to be false. An application designed for hundreds of users that now needs to serve hundreds of thousands. A monolith that processes everything synchronously when the business now requires real-time event processing. A system built around a data model that assumes one-to-one relationships where the domain has turned out to be many-to-many.

When the architectural foundations cannot support the requirements — not just today’s requirements but the requirements you can see coming over the next three to five years — rebuilding may be the only path forward. Migrating a system incrementally only works if the target architecture is reachable from the current one. If the gap is too wide, incremental steps do not get you there.

The key word here is “fundamentally.” Every system has architectural decisions that, in hindsight, were suboptimal. That is not a reason to rebuild. The threshold is that the architecture actively prevents you from delivering what the business needs, and no amount of refactoring will change that.

The Technology Stack Is Dead

Every technology has a lifecycle. Some stacks reach a point where the community has moved on, the vendor has dropped support, and hiring developers with relevant experience becomes a recruiting nightmare.

If your system runs on a framework that has not had a meaningful update in five years, and the last three developers you hired took six months to become productive because nobody teaches this technology any more, the technology itself has become a strategic liability. Migrating the system to a new platform while preserving the existing codebase does not solve this problem — you will still need developers who can work with the old code during and after the migration.

This is different from a technology being “old.” Plenty of older technologies remain well-supported and perfectly capable. The question is whether the ecosystem around your stack is alive and healthy, or whether you are operating on a dead platform with a shrinking pool of talent.

The Business Model Has Changed Entirely

Sometimes the system built to support the old business model is simply irrelevant to the new one. A company that sold physical products through a traditional e-commerce flow now needs to support subscription models, digital products, and marketplace functionality. A B2C platform needs to become a B2B platform with fundamentally different pricing, ordering, and fulfilment logic.

When the business has pivoted so dramatically that the existing system supports almost none of the new requirements, rebuilding around the new model makes more sense than trying to bend the old system into a shape it was never designed for.

When to Migrate

Migration is the right choice more often than most teams expect. The instinct to “start fresh” is powerful but often misguided.

The Core Logic Is Sound

If the system does what it is supposed to do and the business rules encoded in it are correct, there is enormous value in preserving that logic. Business rules accumulate over years. They encode edge cases, regulatory requirements, and hard-won knowledge about how the domain actually works. A rebuild must re-discover all of this.

The strangler fig pattern is specifically designed for this situation: the logic is right, but the platform, performance, or developer experience needs to change. You preserve the behaviour while replacing the infrastructure.

The Problem Is Infrastructure, Not Application

Many legacy system complaints are really infrastructure complaints. The system is slow because it runs on undersized hardware. Deployments are painful because there is no CI/CD pipeline. The database is struggling because nobody has optimised queries or added appropriate indices in years.

These are migration problems, not rebuild problems. Move the application to modern infrastructure, containerise it, set up proper deployment pipelines, and address the performance bottlenecks. You will get 80% of the benefit at 20% of the cost and risk of a full rebuild.

The Data Model Works

If the underlying data model accurately represents your domain, that is an enormous asset. Data models are deceptively hard to get right, and a correct one represents years of refinement. Rebuilding the application while preserving the data model is straightforward. Rebuilding the application while also migrating to a new data model is an order of magnitude more complex and risky.

The Team Knows the Domain

A team that has worked with a system for years has deep institutional knowledge of how it behaves, where the edge cases are, and what the users actually need. A rebuild asks that team to start from zero. Their domain expertise is still valuable, but the efficiency gains from knowing the existing codebase are lost.

Migration lets the team apply their existing knowledge directly. They understand the system well enough to identify the weakest parts and address them systematically.

The Hybrid Path

In practice, the best outcomes come from combining both approaches. The pattern we see work most consistently is: migrate the platform, rebuild the interface.

This means moving the backend — the business logic, data access, and integrations — to a modern platform incrementally, preserving the behaviour that works. Simultaneously, rebuild the user-facing layer from scratch using modern frontend technologies and design practices.

This hybrid approach works because the backend and frontend have different risk profiles. Backend logic is hard to get right and expensive to get wrong. It encodes business rules that took years to refine. Migrating it preserves that investment. Frontend interfaces, by contrast, have a shorter useful life, are easier to test visually, and benefit enormously from modern frameworks and design systems. Rebuilding the frontend on top of migrated APIs gives you a modern user experience without the risk of recreating complex business logic from scratch.

A Risk Assessment Framework

To make this decision systematically, score your system across five dimensions. Each dimension gets a score from 1 (favours migration) to 5 (favours rebuild).

1. Architecture Fitness

How well does the current architecture support your requirements?

  • Score 1-2: Architecture is sound. Performance issues or developer experience can be addressed without structural changes.
  • Score 3: Architecture has limitations but workarounds exist. Some components may need rethinking.
  • Score 4-5: Architecture fundamentally cannot support current or near-future requirements. Incremental changes cannot bridge the gap.

2. Team Capability

Does your team have the skills to execute each approach?

  • Score 1-2: Team has deep knowledge of the existing system and can migrate it efficiently. Hiring for the current stack is feasible.
  • Score 3: Team can work with the system but productivity is limited. Some key knowledge has been lost through turnover.
  • Score 4-5: Few or no team members understand the legacy system. Hiring for the current stack is extremely difficult.

3. Business Alignment

How well does the system support current business needs?

  • Score 1-2: System supports the core business model. Gaps are in non-critical areas or can be addressed through extensions.
  • Score 3: System supports some business needs but significant functionality is missing or misaligned.
  • Score 4-5: Business model has changed enough that the system supports a minority of current requirements.

4. Technical Debt Severity

How much accumulated debt exists?

  • Score 1-2: Debt exists but is manageable. Codebase is reasonably maintainable. Test coverage is adequate.
  • Score 3: Significant debt in some areas. Changes are slow and risky in parts of the system.
  • Score 4-5: Pervasive debt throughout. Every change risks breaking something else. Minimal test coverage. Deployments are consistently painful.

5. Time Pressure

How urgently does the business need improvement?

  • Score 1-2: Business can tolerate a longer timeline. Incremental improvement is acceptable.
  • Score 3: Moderate urgency. The business needs visible progress within six months.
  • Score 4-5: High urgency. The current system is actively losing customers or preventing the business from operating.

Interpreting the Scores

Total 5-12: Migrate. The system has a solid foundation and the risks of a rebuild outweigh the benefits. Use an incremental approach like the strangler fig pattern to modernise systematically.

Total 13-18: Hybrid. Some components need rebuilding, others should be migrated. Assess each major component individually using the same framework.

Total 19-25: Rebuild. The system is fundamentally misaligned with your needs. Invest in understanding the existing behaviour thoroughly before starting, and consider building the new system incrementally rather than as a single big-bang project.

Note that a high score on time pressure alone does not justify a rebuild. Rebuilds take longer than migrations, not shorter. If time pressure is your primary driver, migration almost always gets you to improvement faster.

The Cost of Getting It Wrong

Getting this decision wrong is expensive in both directions.

Unnecessary rebuilds waste the most obvious resource — time and money — but the hidden cost is knowledge destruction. Every business rule, every edge case handler, every workaround for a real-world problem that the old system handled correctly must be rediscovered during the rebuild. These rediscoveries typically happen in production, when a customer encounters a scenario the rebuild team did not anticipate.

Unnecessary migrations waste effort more subtly. The team spends months carefully migrating components of a system that is fundamentally wrong. Each component migration is successful in isolation, but the migrated system still does not meet business needs because the underlying architecture or data model was the real problem. The organisation ends up rebuilding anyway, having spent the migration budget to arrive at the same starting point.

The framework above is designed to help you avoid both traps. Score honestly, assess each component independently, and resist the emotional pull of a clean start. A rebuild should be a strategic decision backed by evidence, not a developer’s desire for a fresh codebase.

Making the Decision

Gather your technical leadership and score the system against the five dimensions. Do it for the system as a whole, and then repeat the exercise for each major component. You will almost certainly find that different parts of the system score differently — that is normal and expected.

Use the results to build a modernisation roadmap that applies the right approach to each component. Some will be migrated. Some will be rebuilt. Some might be replaced with off-the-shelf solutions. The important thing is that each decision is made deliberately rather than by default.

If you are facing this decision and want a second opinion from engineers who have seen both approaches succeed and fail, we are happy to have a conversation. Reach out to us or learn more about our legacy modernisation services.