Almost every business we speak to has at least one application it would rather not talk about. It's usually old, it's usually held together with a mixture of custom code and institutional knowledge, and everyone agrees it needs replacing. Very few of those replacements ever actually happen, because the plan on the table is always the same: stop, rebuild it properly, switch over. That plan is exactly why nothing changes.

In short: You can modernise a legacy application without a full rewrite by using the strangler-fig pattern, putting a stable interface in front of the old system and replacing it piece by piece while it keeps running, so value lands continuously and nothing is switched off until its replacement is already carrying live traffic. It avoids the all-or-nothing risk of a big-bang rebuild.

Why do big-bang rewrites fail so often?

A full rewrite sounds clean in a slide deck. In practice it runs into the same three problems almost every time.

The first is scope creep. Once a team is inside the old application deciding what the new one should do, they inevitably find more than they bargained for: undocumented business rules, edge cases nobody remembers the reason for, integrations quietly holding three other systems together. The rebuild grows to match what they find, and the timeline grows with it.

The second is that the business doesn't get to pause while this happens. Orders still need processing, customers still need serving, reports still need producing. The old application has to keep running, in full, for the entire length of the rewrite. Every hour spent on the new system is an hour not spent improving the one people are actually using.

The third is timing. Rewrites commonly take twelve to eighteen months, sometimes longer, and requirements captured at the start have usually moved by the time anything ships. You can end up delivering a faithful rebuild of a system the business has already outgrown.

Put those three together and you get the pattern we see repeatedly: a rewrite stalls, gets descoped, or is quietly abandoned six or nine months in, and every penny spent on it is sunk cost with nothing running to show for it. The old system is still there, still needs supporting, and the appetite for trying again has usually gone with the budget.

"A big-bang rewrite has to work perfectly on day one to be worth anything. Incremental modernisation delivers value at every single step along the way."

Comparison showing a single large system shattered into pieces versus a stack of smaller components replaced one at a time
A big-bang rewrite risks everything at once. Incremental replacement risks one piece at a time.

What is the strangler-fig pattern?

Rather than replacing everything at once, the strangler-fig approach replaces a legacy system piece by piece, from the outside in. You put a stable interface in front of the old application, then build new components behind it one at a time, routing traffic to each new piece as it becomes ready. The legacy system keeps handling everything that hasn't been rebuilt yet. Nothing is switched off until its replacement is already carrying live traffic successfully.

The name comes from the strangler fig tree, which grows around a host tree until the host is no longer needed. The IT version is far less dramatic and considerably less risky: at no point is the business running on something half-built. Old and new coexist, and the old system is retired only once there's genuinely nothing left for it to do.

The practical effect is that value lands continuously rather than in one all-or-nothing release. Replace the reporting layer and reporting gets better immediately. Replace the customer-facing portal and that experience improves immediately, with no single cutover date the whole project is riding on.

Where should you start in practice?

Not every piece of a legacy application is equally worth rebuilding first. A few principles that consistently work:

  • Start with the highest-pain, highest-value piece. Usually that's whatever generates the most support tickets, or whatever is blocking the new features the business actually wants. Fixing that first proves the approach and buys goodwill for the rest of the programme.
  • Move data and integration layers before touching the interface. Getting data into Azure and building solid APIs around it gives everything else a stable foundation, and it's usually less politically sensitive than changing a screen people use every day.
  • Build new pieces on Azure App Service, Azure Functions, or Power Platform rather than recreating the old architecture. There's little value in modernising the technology while faithfully reproducing the structure that made the old system hard to change in the first place.

Budget for the transition, don't ignore it

Running old and new side by side is genuinely more complex than either system on its own. There's a period where data may need to flow both ways, where two things need monitoring instead of one, and where staff need to understand which system does what while the boundary shifts. That's a real cost, not an inconvenience to wish away, and it should be planned and budgeted for explicitly rather than treated as a footnote. Done well, it's still far shorter and far less risky than the equivalent stretch of a big-bang rewrite, because at every point along it the business has a fully functional application, not a half-finished one.

When is a full rewrite genuinely the right call?

Incremental modernisation isn't the answer to everything. A full rewrite makes sense when the underlying platform is fully unsupported or unsupportable, so there's no stable base left to strangle anything around, or when the business logic itself is wrong rather than just the technology it's built on. Replatforming faithfully just gets you the wrong thing on newer infrastructure. In those cases, a proper rebuild, planned with eyes open about the timeline and the risk, is worth doing.

For most legacy estates, though, that's not the situation. The technology is dated, but the logic is broadly sound, and the risk lies in how you get from one platform to the other rather than in the destination itself.

If you've got a legacy application everyone agrees needs modernising but no one wants to commit to a rewrite for, that's exactly the conversation our application modernisation and Azure migration team has every week. Our free assessment maps out the highest-value starting point, without asking you to sign off on a twelve-month rebuild to get there.

RM
Ryan Mangan

Founder & CTO of Systech IT Solutions, Microsoft MVP and Chartered Fellow of the BCS, and author of the bestselling Mastering Azure Virtual Desktop. Ryan has spent nearly two decades helping organisations adopt Azure, Microsoft 365 and modern workspace technology pragmatically.