Almost every established business runs at least one system that everyone is afraid to touch. It was built years ago, it still processes critical transactions, and the people who understood it best have moved on. Changes take months. Security updates are risky. And yet the business depends on it every day.

The tempting answer is a complete rewrite. The evidence suggests that is usually the wrong one.

Why big-bang rewrites fail

A full rewrite asks a team to reproduce years of accumulated business logic — much of it undocumented — while the original system keeps changing. Meanwhile, the business sees no value until the very end. Budgets overrun, scope expands, and many rewrites are abandoned or launched with critical gaps.

A more reliable approach is incremental modernisation: replacing the system piece by piece, delivering value at every step, and keeping the business running throughout.

The strangler fig pattern

Named after a vine that gradually grows around a tree, the strangler pattern places a routing layer in front of the legacy application. New capabilities are built as modern services, and traffic for each capability is moved from the old system to the new one when it is ready. Over time, the legacy system shrinks until it can be retired.

The advantages are significant:

  • Lower risk. Each change is small and can be rolled back.
  • Early value. Users benefit from improvements within weeks, not years.
  • Continuous learning. The team discovers hidden business rules gradually rather than all at once.

A practical roadmap

1. Understand before you change

Map the system: its modules, data flows, integrations and the business processes it supports. Interview the people who use it. Identify which parts change most often and which cause the most pain.

2. Build a safety net

Before moving anything, add automated tests around the behaviour you intend to preserve. Characterisation tests — which record what the system currently does, right or wrong — are invaluable when the original requirements are lost.

3. Prioritise by value and risk

Start with a capability that is valuable, reasonably self-contained and frequently changed. Avoid the most complex, most critical module as your first move.

4. Introduce the routing layer

An API gateway or reverse proxy lets you direct specific requests to new services without changing clients.

5. Migrate data deliberately

Data is often the hardest part. Use change-data-capture or synchronisation so old and new systems stay consistent during transition, and define a clear owner for each data set.

6. Retire relentlessly

Every migrated capability should be switched off in the legacy system. Modernisation that only adds new systems simply creates a bigger estate to maintain.

Choosing the target architecture

Not every system needs microservices. For many organisations, a well-structured modular application on a managed cloud platform delivers most of the benefits with far less operational complexity. Choose microservices when you genuinely need independent scaling or independent team deployment — not because it is fashionable.

Modernisation is not a technology project. It is a business continuity project that happens to involve technology.

Measuring progress

Track outcomes the business cares about:

  • Lead time from idea to production
  • Deployment frequency and change failure rate
  • Incidents and recovery time
  • Cost to run and maintain
  • Percentage of traffic served by modern components

Getting started

If you are living with a system that holds your business back, start with an assessment rather than a decision to rewrite. Our custom software team begins every modernisation engagement with a code, architecture and security audit, followed by a phased roadmap that delivers value in the first quarter.