Strangler Fig Pattern vs. Big Bang Rewrite: How to Modernize a Legacy System

Every legacy modernization conversation eventually asks the same question: replace it all at once, or replace it in pieces? The honest answer depends on how coupled the system actually is — not on which approach sounds more thorough.

What each approach actually is

Big bang rewrite

A big bang rewrite means building the replacement system in parallel with the legacy one, then switching over in a single cutover once the new system is judged feature-complete. Nothing goes live until everything does. The appeal is obvious: no time spent running two systems side by side, no routing layer, no partial states to reason about.

Strangler fig pattern

The strangler fig pattern — named after the vine that grows around a host tree and gradually replaces it — builds new services alongside the legacy system and routes traffic to them one capability at a time, through a facade or proxy layer that decides which system handles each request. The legacy system keeps running the parts not yet migrated. Over time, as more capabilities move to the new system, the legacy system's footprint shrinks until there's little or nothing left to retire.

Why a big bang rewrite concentrates risk

The core problem with a big bang rewrite isn't the engineering — it's that every migration risk lands on one date. Data migration bugs, missed edge cases in business logic nobody documented, integration gaps with systems the legacy app talks to: all of it surfaces at once, in production, after the point where rolling back is still easy. Legacy systems accumulate undocumented behavior for years; a rewrite has to rediscover all of it before cutover, and a rewrite that's chasing requirements nobody wrote down tends to run long, which only grows the gap between what the new system was built against and what the legacy system has since started doing.

That's also why a big bang rewrite is a worse bet the longer it runs. A six-week rebuild of a small, well-understood tool carries the same cutover-risk shape as a two-year rebuild of a core system — but the two-year version has two years for the legacy system's behavior to drift further from what the rewrite assumed.

The two ways a strangler fig migration fails

The strangler fig pattern isn't risk-free — it fails in two specific, predictable ways, and both are visible before you commit to the approach.

No clean interception point

The pattern depends on being able to intercept requests for a given capability and route them to the new service instead of the old one. If the legacy system has no seam to intercept — no API boundary, no routable entry point, logic buried inside a monolith with no clear edge — there's nothing for the facade layer to redirect. Some systems need a thin routing layer built first, before any functionality can move, just to create that seam.

Shared mutable data

If the old and new systems both read and write the same underlying data while the migration is in progress, every piece you move has to solve data consistency, not just functionality. A capability that writes to a shared table has to either keep both systems' writes in sync during the transition or accept inconsistency until the legacy path for that data is fully retired. This is usually the real reason a strangler fig migration stalls for months on one stubborn piece — not the code being replaced, but the data it still shares with everything that hasn't moved yet.

When a big bang rewrite is still the right call

Incremental migration isn't automatically the safer choice. A system small enough, isolated enough, and low-stakes enough that a cutover failure is cheap to recover from is a reasonable candidate for a straight rewrite — an internal admin tool, a single well-bounded service with few integrations, anything where "roll back to the old version for a day" is a real option rather than a crisis. The strangler fig pattern's overhead — building and maintaining a routing layer, running two systems during the transition, coordinating staged releases — isn't free, and for a small enough system it costs more than the risk it's protecting against.

A practical decision framework

In practice, most systems that prompt a "should we modernize this" conversation are old enough and connected enough to enough other systems that the strangler fig pattern is the lower-risk default. The exceptions are usually smaller than the team expects going in.

How we approach this on real projects

On custom software engagements that start from an existing legacy system, the first deliverable is almost never code — it's a map of the system's actual seams and shared data, because that map is what decides whether strangler fig or a scoped rewrite is the right call for each piece. Modernization timelines vary enormously depending on how coupled the existing system turns out to be once that discovery work is done, so we don't quote a fixed duration before that assessment — it's determined per project, during discovery.