Rewrite vs strangler fig:
replace it all at once, or strangle it a piece at a time.

What each one actually means.

A big-bang rewrite builds the replacement alongside the original and cuts over on a date. Until that date the old system remains the system of record, so every change the business asks for is either made twice or deferred.

The strangler fig pattern, named by Martin Fowler in 2004 after the vine that grows around a tree and eventually replaces it, works differently. A facade sits in front of the existing system and routes each request. One capability at a time moves behind the facade to a new implementation; everything else still reaches the original. The old system shrinks until it is empty, and then it is switched off.

The structural difference is where the risk sits. A rewrite concentrates all of it on one day. A strangler fig spreads it across many small cutovers, each of which can be rolled back on its own.

When a rewrite is the right call.

Big-bang has a poor reputation, most of it earned. It is still the right answer in a few specific situations.

The system is small enough to hold in your head

If one person can read the whole codebase in a week and the behaviour is genuinely understood, the coordination overhead of a facade may cost more than it saves.

The behaviour is documented and tested

A rewrite is fundamentally a specification problem. If you already have the specification, its largest risk is already gone.

A hard external date forces a single cutover

A platform shutdown or a contract end date sometimes removes the option of running both systems in parallel.

The data model itself is the problem

If the fix requires a fundamentally different schema, incremental migration means maintaining a translation layer for the entire project. Occasionally that is worse than a clean break.

How rewrites fail.

Joel Spolsky’s 2000 essay on Netscape’s rewrite is still the clearest short account of this, and the failure mode has not changed in the twenty-five years since.

The feature freeze outlasts the business’s patience

A rewrite that runs eighteen months means eighteen months of “we will add that to the new system”. Businesses do not stay still that long. Either the freeze breaks, and you are now building two systems, or the business routes around you.

The undocumented rules surface at the end

Rules nobody wrote down are discovered during acceptance testing, at the worst possible moment, by users already unhappy about the change.

The cutover has no rollback

One date, one switch, and a rollback plan that means discarding the project. That asymmetry is what makes the final week of a rewrite so unpleasant.

Scope grows because the system is being rebuilt anyway

Once everything is in play, every stakeholder’s wish list becomes negotiable and the replacement quietly stops being a replacement.

What the strangler fig costs.

It is not free, and pretending otherwise is how the pattern gets oversold.

You build and maintain a facade

The routing layer is real software. It has to be correct, observable, and fast enough that it does not become the thing users complain about.

Two systems run at once, for a long time

Sometimes years. That means two deployment paths, two monitoring surfaces, and a data synchronisation story you have to get right rather than hope about.

Seams have to exist, or be made

Some legacy systems have clean boundaries. Many do not, and the early work is carving them out. This is where most strangler-fig projects actually spend their first months.

It requires sustained discipline

The pattern only finishes if someone keeps moving capabilities across. Half-strangled systems that stalled when budget and attention moved elsewhere are a real and common outcome.

How we choose.

We run Event Storming before either path is committed to. The workshop produces a model of the business process and, critically, shows where the natural boundaries fall. Those boundaries are the seams a strangler fig needs, and their absence is itself a finding worth having early.

If the model comes back with clear bounded contexts and a manageable number of integration points, we sequence a strangler fig and move the highest-risk context first, so the hardest part is proven at the start rather than discovered at the end.

If the system turns out to be small and the model is simple, we will say so, and a rewrite becomes reasonable. In our experience that is the less common outcome.

Where each approach earns its keep.

Common questions

How long does a strangler fig migration take?

Longer in calendar time than a rewrite of the same system, and that is the trade. You are buying reversibility and continuous delivery of value with elapsed time. The comparison that matters is not total duration but when the business sees the first working improvement.

Can you apply the strangler fig pattern to a desktop application?

Yes, though the facade looks different. Instead of an HTTP router you are typically extracting business logic into a service that both the existing desktop client and the new implementation call. The principle, one capability at a time behind a stable interface, is unchanged.

What if the legacy system has no clean boundaries?

Then creating them is the first phase of the project rather than a preamble to it, and it should be planned and budgeted that way. This is the most common reason a strangler fig takes longer than people expect.

Do you ever recommend neither?

Often. Sequencing only matters once the decision to move is justified, and a good number of systems do not clear that bar. Our guide on when not to modernize covers the test we apply first.

Related

When not to modernize · How we run Event Storming · Automated conversion vs rewrite