Most legacy modernisation programmes fail for organisational reasons, not technical ones. The technology to replace a creaking core system with minimal disruption has existed for years; what derails programmes is the decision to attempt it all at once. A board under pressure to “fix the legacy problem” often greenlights a wholesale rewrite, expecting a clean break from the old estate within eighteen months. Two years later, the team is still chasing feature parity, the legacy system has not been switched off, and the business has spent twice the original budget on a system that does not yet work as well as the one it replaced.
The alternative is less dramatic but considerably more reliable: modernise incrementally, keep the legacy system operational throughout, and let the new architecture earn its place piece by piece. This is not a new idea, but it has become more urgent as the cost of legacy debt compounds and as regulators in sectors such as financial services, energy, and healthcare apply increasing scrutiny to operational resilience.
Why “Big Bang” Rewrites Keep Failing
The appeal of a full rewrite is obvious. Teams get to start clean, escape years of undocumented business logic, and avoid the perceived inefficiency of running two systems in parallel. In practice, the economics rarely work out that way. Research from McKinsey shows that the average enterprise carries technical debt equivalent to a substantial share of its total technology estate, and that a meaningful proportion of new product budgets is consistently redirected to managing it rather than building on it. The same body of research found that one B2B organisation had to abandon roughly a quarter of a planned £2 billion margin-expansion programme once the true cost of the underlying technical debt became clear, illustrating how unaddressed legacy complexity directly constrains strategic optionality, not just IT spend.
The deeper problem with rewrites is that legacy systems are rarely as poorly designed as they appear; they are usually encoding years of accumulated business knowledge that nobody has bothered to document elsewhere. A migration team that treats this complexity as something to eliminate, rather than something to understand and preserve, tends to rediscover the same edge cases the legacy system was quietly handling all along, usually in production, after go-live.
McKinsey’s more recent analysis of enterprise technology budgets reinforces the point from a different angle. Organisations that treat modernisation as a continuous, deliberate discipline, allocating a meaningful and sustained share of their technology budget to “change” activity rather than letting new capability simply accumulate on top of an ageing core, are the ones best positioned to keep run costs falling over time, freeing up further investment for the next wave of change.[1]
The Strangler Fig Pattern: Modernising Without Switching Anything Off
The most widely adopted alternative to the big-bang rewrite is the Strangler Fig pattern, a term coined by Martin Fowler after observing how strangler fig vines in Queensland’s rainforests grow around a host tree, gradually drawing it into a new structure until the original is no longer needed. Applied to software, the same principle holds new capability is built around the legacy system, not as a replacement for it on day one, but as a parallel structure that gradually absorbs functionality until the legacy core can be retired.
Microsoft’s own architecture guidance describes the mechanism clearly. A façade, typically an API gateway or reverse proxy, sits between the client and both systems. Initially, it routes the overwhelming majority of traffic to the legacy application. As new services are built and validated, the façade incrementally redirects specific request types to the new system, until the legacy application has no remaining dependencies and can be decommissioned outright.[2]
What makes this approach particularly suited to regulated and operationally sensitive environments is that at no point does the system as a whole stop functioning. Each migrated capability can be tested, observed, and rolled back independently of every other capability still running on the legacy estate. A defect in a newly migrated reporting module does not require rolling back authentication, payments processing, or any other function that has not yet moved. This containment of blast radius is the single biggest reason the pattern has become the default approach for organisations that genuinely cannot tolerate downtime, financial services platforms processing live transactions, healthcare systems handling patient data, and public sector services where an outage has consequences well beyond inconvenience.
The pattern is not without trade-offs. Running two systems in parallel for an extended period adds real operational cost and complexity, and the temptation to expand scope mid-programme, turning “let’s add a routing layer” into “let’s rebuild everything while we’re at it”, is one of the most common ways Strangler Fig programmes lose the very risk-management benefits that justified the approach in the first place. Disciplined scoping, not technical sophistication, is usually what separates successful incremental modernisation from a slow-motion big-bang rewrite with extra steps.
The Technical Mechanics of Zero-Disruption Migration
Below the architectural pattern sits a set of more specific techniques that make near-zero-downtime migration achievable in practice, particularly where stateful systems and live databases are involved.
Change data capture (CDC) is the foundation. Rather than freezing writes to take a one-off snapshot of the legacy database, CDC tooling streams every insert, update, and deletion from the source system to the target system in real time, while a bulk historical transfer runs in parallel. This means the new environment stays synchronised with live production activity throughout the migration window, rather than working from data that is hours or days stale by the time cutover happens.
Blue-green deployment complements this by maintaining two fully independent, production-equivalent environments, conventionally labelled blue (the current live system) and green (the new or updated system), with traffic routed to only one at a time. Once the green environment has been validated against real, CDC-synchronised data, traffic is switched over, often in a matter of seconds, with the blue environment kept warm as an immediate rollback path if anything is amiss. AWS’s own engineering documentation on blue-green database deployments illustrates how granular this monitoring can be in practice, down to capturing exact switchover timings and topology changes to support rapid diagnosis if a cutover does not go cleanly.[3]
The combination of these techniques, a Strangler Fig façade controlling traffic flow at the application layer, CDC keeping data synchronised at the database layer, and blue-green deployment providing a safe, reversible cutover mechanism, is what allows organisations to retire genuinely old infrastructure (15- or 20-year-old transaction processing cores, for example) without a single planned outage window, let alone an unplanned one.
Why UK Regulated Sectors Cannot Afford to Get This Wrong
The risk of inaction is not hypothetical for UK organisations in regulated sectors, and the public sector offers a particularly stark illustration of what happens when legacy modernisation is deferred indefinitely. The National Audit Office’s January 2025 report on government cyber resilience identified at least 228 legacy IT systems still in active use across government departments, more than a quarter of which carried a high likelihood of an adverse operational or security incident, and found that over half of these had no fully funded remediation plan in place.[4] A subsequent Public Accounts Committee review found the picture had not materially improved, with 319 legacy systems identified across the public sector by January 2025 and around a quarter rated “red” for combined likelihood and impact of failure.
This is not solely a public sector phenomenon. The same dynamics, ageing cores, undocumented dependencies, deferred remediation, sit underneath financial services, energy, and healthcare organisations that have simply had the budget to paper over the symptoms for longer. The NAO’s findings are instructive precisely because the same root causes apply well beyond government: when modernisation is treated as a discretionary cost rather than an operational resilience requirement, the gap between what regulators and customers expect and what the legacy estate can actually deliver only widens.
For CTOs and Programme Directors weighing up modernisation investment, the more useful question is rarely “can we afford to modernise this system?” It is “what is the ongoing cost, in risk and constrained optionality, of leaving it exactly as it is?” Framed that way, an incremental, Strangler Fig-led modernisation programme, one that delivers measurable risk reduction every quarter rather than promising a single transformational outcome eighteen months from now, tends to be a considerably easier case to make at board level, and a considerably safer one to deliver.
Getting Started Without Betting the Business
Organisations that get this right tend to follow a similar sequence. They start by identifying genuine seams in the existing system, natural boundaries such as authentication, reporting, or notifications, rather than attempting to decompose the entire estate at once. They introduce a routing or façade layer before touching any legacy code, which on its own often improves visibility into traffic patterns that were previously opaque. They resist the temptation to expand scope once the programme is underway. And critically, they treat data decoupling as a first-class concern from day one, rather than an afterthought once application-layer migration is already in flight, since shared databases are consistently where well-scoped Strangler Fig programmes run into the most difficulty.
None of this requires abandoning the legacy estate’s accumulated business knowledge, and none of it requires a single planned outage. It requires a clear-eyed view of where the real risk sits, the discipline to migrate in genuinely small increments, and the technical capability to keep both systems synchronised and observable throughout. That combination, strategic sequencing paired with rigorous delivery, is precisely where senior, experienced technology leadership earns its keep.
Flipware Technologies works with FTSE 100 organisations undergoing data and digital transformation, and with funded healthtech platforms needing fractional CTO or outsourced delivery leadership, to plan and deliver legacy modernisation programmes that protect business continuity throughout. If your organisation is weighing up how to approach a legacy estate that has become a constraint rather than an asset, get in touch with Flipware Technologies to discuss an approach suited to your risk tolerance and timeline.
References
- McKinsey & Company, “Recalibrating technology budgets for the AI era”, March 2026
- Microsoft Learn, “Strangler Fig Pattern, Azure Architecture Center”
- Amazon Web Services, “Achieve near-zero downtime database maintenance by using blue/green deployments with AWS JDBC Driver”, February 2026
- National Audit Office, “Government cyber resilience”, January 2025
