Legacy system modernisation without disrupting the business

Legacy system modernisation means changing an old, business-critical application without stopping the business that depends on it — which is why the safest route is almost never a single, risky cutover. The options range from leaving a system exactly as it is (retain) to rebuilding it from scratch (rebuild), and the pattern that lets you modernise gradually, running old and new side by side, is the strangler fig. This guide covers the seven modernisation options, how a phased migration actually works, and the controls that keep the business running while you do it.

If you're still deciding whether to build, buy or modernise at all, our custom software development guide is a good starting point before you get this specific.

The seven modernisation options#

Microsoft's Cloud Adoption Framework groups modernisation and migration choices into seven strategies (plus "retire," for workloads you're decommissioning outright), each tied to a different business driver rather than a technical preference alone.

None of these is inherently "better" — they're trade-offs between speed, cost, risk and how much of the system's current limitation you actually fix. A system can also be treated differently module by module: it's common to rehost the parts you won't touch soon and rearchitect the one component that's actually holding the business back (see Microsoft's migration strategy guidance and its replatform/refactor/rearchitect guidance).

AWS's cloud migration guidance covers similar ground with slightly different labels: rehost, replatform, repurchase, refactor or re-architect, retire and retain, plus relocate for large infrastructure moves (AWS, "6 Strategies for Migrating Applications to the Cloud"; AWS Prescriptive Guidance, "Migration strategies"). The terms don't map one to one — AWS's "repurchase" is roughly what this article, following Microsoft's naming, calls replace, and AWS treats rearchitecting and rebuilding as points on a single "refactor" spectrum rather than as separate options. Whichever vendor's labels you use, the decision is the same, and where it lands on rebuild or rearchitect, the cost drivers are close to those for any new build; see how much it costs to build a web app for how scope and integrations move that number.

The strangler-fig pattern: modernising without a big-bang cutover#

Rearchitecting or rebuilding a system doesn't have to mean a single cutover weekend. The strangler-fig pattern, named by Martin Fowler after a vine that gradually grows around a host tree until the tree beneath it is gone, replaces a legacy system piece by piece while it keeps running (Fowler, "StranglerFigApplication").

The mechanics are straightforward, per the Azure Architecture Center's description of the pattern:

1. Put a façade (a proxy or router) in front of the legacy system. At first, it routes almost all traffic to the legacy system unchanged.
2. Build one piece of new functionality at a time, and update the façade to route just that traffic to the new system instead.
3. Repeat, module by module, until the façade routes everything to the new system and the legacy system has no remaining dependents.
4. Decommission the legacy system, and — usually — remove the façade once it's no longer earning its keep.

This is deliberately slow, and that's the point: each step is small enough to test, validate and roll back on its own, rather than betting the whole migration on one release (Strangler Fig Pattern, Azure Architecture Center). It's not free, though — Microsoft's own guidance notes it doesn't suit every case: if you can't intercept requests to the legacy system, can't modify its source code, or need to fully decommission it quickly, a strangler-fig approach adds coordination overhead you don't need. For a small system that's simple to replace outright, just replace it.

Data migration: moving the system of record without losing it#

Data is usually the part that makes modernisation risky, because unlike code, you can't just redeploy a previous version if something goes wrong. A pattern that works well alongside the strangler fig, drawn from Microsoft's own worked example, looks like this:

1. New service, old database. The new service goes live but still reads from and writes to the legacy database for its domain's data. Nothing about the data has moved yet — only the code calling it.
2. Introduce the new data store. Extract the relevant tables into an isolated database for the new system, loaded via an initial ETL job and kept in sync afterwards using change-data-capture so both stores agree while the legacy system is still writing.
3. Validate before cutover. Compare the two stores for consistency. This is the step it's tempting to skip under time pressure, and the step that actually protects you.
4. Cut over, then decommission. Once validated, point reads and writes at the new store, and only then remove the corresponding tables from the legacy database — treated as a deliberate, final step, not a by-product of cutover.

Rollback stays possible right up until you delete the old tables and sync process, which is exactly why that removal should happen last, and on purpose, rather than as clean-up you do without thinking.

Risk controls: parallel run, feature flags, rollback#

Three controls do most of the work of making each migration step safe to attempt and safe to reverse:

• Parallel run. Send the same input to both the old and new systems and compare outputs before the new one takes over for real. This is especially valuable for anything calculation-heavy or compliance-sensitive, where "it looks right" isn't good enough on its own.
• Feature flags. Gate new functionality behind a toggle so it can be switched on for a small slice of traffic, watched, and switched off instantly if something's wrong — without a redeploy. Martin Fowler's feature toggle categories are a useful checklist: release toggles hide unfinished work in production, ops toggles act as a kill switch under load, and permission toggles expose a feature to a chosen group of users before everyone else. Where the strangler-fig façade routes traffic at the level of a whole route or service, feature flags let you control risk at a much finer grain, inside a single service. Our guide to zero-downtime deployments covers the release-side techniques (blue-green, rolling, canary) that pair naturally with flags.
• Rollback. Decide what "safely reversible" means for a change before you ship it, not after something breaks. For data changes, that usually means keeping the old write path alive until the new one is validated, as above. For code changes, it means being able to redeploy the previous version without a pending data migration blocking you from doing so.

A phased roadmap for legacy system modernisation#

Making the business case#

Modernisation competes for budget against new features, so the case for it needs to answer questions a non-technical stakeholder will actually ask:

• What does it cost to keep patching this system every year, compared with modernising the highest-risk part of it? If part of that comparison is ageing on-premises hardware versus managed cloud servers, current plans and prices make that side of the sum concrete.
• What's the real business exposure if it fails — compliance, revenue, reputation — versus the cost of the work to reduce that exposure?
• Which parts of the system are genuinely specific to how the business operates, and which are commodity functionality a "replace" option (an off-the-shelf product) could cover for less?
• Can this be funded and delivered in phases, each with a visible result, rather than as one large project whose only payoff is at the very end?

The phased approach in this guide is itself part of the business case: it lets you fund and prove out the highest-value, highest-risk piece first, rather than asking for a full budget upfront against a return that only arrives at the end of the project. If you want a second opinion on scoping a specific slice, custom software development covers how we approach a build of this size, from discovery through to delivery.

What to do next#

Legacy system modernisation is rarely a single decision — it's a set of decisions, one per component, backed by controls that let you change your mind safely. If you're weighing options for a system that's becoming a drag on the business, our cloud migration service can help assess which of the seven options fits each part of it before you commit to a roadmap.