Skip to content
Brain Matrix
Book a call

Problem 04 — Legacy drag

Your technology is slowing the whole company down

Rewrites fail more often than they succeed, and usually for the same reason: they ask a business to stand still for a year. We modernise in slices you can stop at, keeping the system running while what is underneath it changes.

Symptoms we hear

  • Releases are rare and frightening
  • Only one person understands a critical component
  • The stack blocks hiring and integration
  • Costs rise while delivery slows

The problem

The problem, stated plainly

Legacy is not a technology. It is a system that has become risky to change — and risk to change is what turns a two-day feature into a two-month negotiation. The technology may be perfectly serviceable; what has degraded is the confidence to touch it.

The business cost shows up somewhere other than engineering. Releases become rare and frightening. Hiring gets harder because nobody wants to work on it. Integration requests get refused. Eventually the technology is quietly setting company strategy, by determining what is considered possible.

  • Releases are rare, and frightening when they happen
  • One person understands a critical component
  • The stack blocks hiring and integration
  • Costs rise while delivery slows
  • There is no test suite anyone trusts
  • Nobody is certain what would break if a component were changed

Root cause

Why this happens

Understanding why a problem exists is what separates a solution from a workaround.

  1. 01

    The system succeeded

    Legacy is what successful software becomes. Years of accommodating real requirements from real customers produce accumulated complexity — much of which encodes knowledge nobody has written down anywhere else.

  2. 02

    Understanding left before the code did

    The people who held the reasoning moved on. What remains is behaviour without rationale, which makes every change a question of whether this line is load-bearing.

  3. 03

    Testing was never retrofitted

    Without a suite anyone trusts, every change requires manual verification, so changes get batched, so releases get bigger, so releases get riskier — which is a loop that tightens on itself.

  4. 04

    The rewrite was proposed and shelved — correctly

    A twelve-to-eighteen-month rewrite with no interim value is a genuinely bad bet, and shelving it was the right call. The mistake is concluding that nothing can be done, rather than that this particular plan was wrong.

Possible solutions

The options actually available

There are more routes than 'live with it' or 'rewrite it', and the middle options are where most of the value is.

Stabilise first

When it fits

Releases are the immediate pain. Add tests around critical paths, automate deployment, add observability.

What to watch

This is unglamorous and frequently the highest-return work available. It also makes every later option safer and cheaper.

Strangle the monolith incrementally

When it fits

Well-bounded capabilities can be moved out one at a time behind a stable interface, with the old system still running.

What to watch

Boundaries. Extracting the wrong seam creates two coupled systems instead of one, which is worse than where you started.

Replatform without redesign

When it fits

The logic is sound but the hosting, runtime or dependencies are the constraint.

What to watch

Resist redesigning while moving. Changing two variables at once makes failure impossible to diagnose.

Expose an API layer over the existing system

When it fits

The system works, but nothing can integrate with it and that is what is blocking the business.

What to watch

Often the fastest route to unblocking, and it buys time to make the larger decision properly.

Full replacement

When it fits

The domain has genuinely changed, the technology is unsupportable, or the system is beyond safe modification.

What to watch

Only with a slice-by-slice migration and a running fallback. A big-bang cutover is a bet on being right about everything simultaneously.

Our approach

How we approach it

The organising principle is that you should be able to stop after any phase and be better off than before it.

  1. 01

    Establish what the system actually does

    Not what the documentation says. Behaviour, dependencies, data flows, and the undocumented rules that turn out to be business-critical. This is archaeology, and skipping it is how migrations lose data.

  2. 02

    Build a safety net before touching anything

    Characterisation tests around critical paths, a repeatable deployment, and observability. Without these, every subsequent step is a guess with consequences.

  3. 03

    Find the seam that is worth cutting

    The first extraction should be valuable enough to justify itself and self-contained enough to succeed. Getting this choice right is most of the difference between momentum and a stalled programme.

  4. 04

    Migrate in slices with the old system running

    Route traffic gradually, compare outputs, keep the fallback available. Cutovers should be reversible until the moment they are obviously unnecessary.

  5. 05

    Leave the knowledge behind

    Documentation, decision records and tests, so that the modernised system does not become the next legacy system for exactly the same reasons.

Technical capability

What we actually build with

Listed so a technical evaluator can judge us on specifics rather than adjectives.

Assessment

  • Codebase and architecture review
  • Dependency and risk analysis
  • Data model archaeology
  • Behaviour characterisation
  • Options with costed trade-offs

Stabilisation

  • Characterisation and regression tests
  • CI and repeatable deployment
  • Observability and error tracking
  • Security and dependency remediation
  • Backup and recovery verification

Migration

  • Strangler-pattern extraction
  • API layers over existing systems
  • Data migration with reconciliation
  • Parallel running and output comparison
  • Progressive traffic routing

Modern platform

  • Cloud and container platforms
  • Infrastructure as code
  • Modern application stacks
  • Identity and access modernisation
  • Cost and performance optimisation

Qualification

Whether this is for you

We would rather lose a project than take one that should not exist.

This works well when

  • A system that still carries real business value
  • Appetite for incremental change over a big bang
  • Access to the people who know how it behaves
  • A business reason, not just an engineering preference

We are the wrong choice when

  • A requirement to rewrite everything at once
  • No access to the running system or its data
  • A system due to be retired within the year
  • Modernisation as a substitute for a product decision

Relevant work

What this looks like in practice

Professional services2026Anonymised

Recovering an upgrade path from two years of undocumented customisation

Every customisation had been made in the vendor's code, so upgrading meant losing them.

The platform had been customised directly, so it could not be upgraded — several versions behind, with security fixes out of reach. We reconstructed what had actually changed and rebuilt the upgrade as a reviewable merge.

  • PHP
  • Laravel
  • MySQL
  • Git
  • Automated diffing

Brain Matrix Labs — free tool

Should you build custom software?

Useful when the real question is whether to replace or to buy.

Open the tool

Questions

What clients ask us

Should we just rewrite it?

Usually not, and rarely all at once. Big-bang rewrites ask the business to stand still while carrying full risk until the end, and they routinely rediscover requirements that were encoded in the old system without being documented anywhere. Incremental replacement gives you value earlier and lets you stop. There are exceptions — an unsupportable runtime, or a domain that has genuinely changed — and we will say so when we see one.

Can you work on a system in a technology you do not specialise in?

Frequently, yes. Assessment, characterisation testing, seam identification and incremental extraction are largely technology-independent skills. We will be direct about where we are strongest and where you would be better served by a specialist, rather than learning on your budget.

How do we keep the business running during this?

That constraint shapes the whole approach. Old and new run in parallel, traffic moves gradually, outputs are compared, and the fallback stays available. If a phase cannot be delivered without stopping the business, it is scoped wrong and we rescope it.

What if the original developers are gone?

That is the normal case rather than the difficult one. Behaviour can be characterised from the running system and its data even where intent is undocumented — which is precisely why characterisation tests come before changes rather than after them.

How long does modernisation take?

It is not a project with an end date so much as a sequence of phases, each a few weeks to a few months, each leaving you better off. Many organisations stop after two or three because the pain that prompted the work has gone — which is a good outcome, not an abandoned programme.

How do we justify this internally?

Not with technical debt arguments, which do not travel outside engineering. Use release frequency, incident rate, time to deliver a representative change, and the specific things the business has been told are impossible. Those are the numbers that move a board.

Further reading

On this topic

Technology Strategy5 min read

Modernising legacy software without a rewrite

Big-bang rewrites ask a business to stand still for a year and carry all the risk until the end. Here is the incremental alternative, how to choose the first slice, and how to justify it to a board that does not care about technical debt.

Solutions

Other problems we solve

Next step

Let's talk about what's holding your business back.

A 45-minute conversation with a senior engineer. We will look at your situation, say what we would do, and tell you if the answer is not software. No pitch deck, no pressure.

Book a strategy callExplore the Labs tools