Skip to content
Latticework
Esc
Try
No. 052Change & Evolution

Strangler Fig

Replace a legacy system gradually by growing the new one around it until the old one can be removed.

A façade lets traffic move to the new system slice by slice, until the legacy system has nothing left to do.

To an executive

Replacing an old system in small steps spreads risk and delivers value as each piece ships, instead of one large, late bet with nothing to show until the end.

To an engineer

Put a routing layer in front of the legacy system, and move one capability at a time to the new one. Retire the old parts as they empty.

The idea

Strangler figs germinate in the branches of a host tree, send roots down around its trunk, and over many years grow into a self-supporting tree of their own. By the time the host dies, the fig no longer needs it. Martin Fowler borrowed the image in the early 2000s for a way of replacing legacy software: grow the new system around the edges of the old one until there is nothing left for the old one to do.

The alternative it argues against is the big-bang rewrite: freeze the old system, build its replacement in parallel, and switch over on a single date. Rewrites routinely take far longer than planned, chase a moving target as the business keeps changing, and deliver no value until the very end. Strangling replaces one large, late, high-risk bet with many small ones, each of which pays off as soon as it ships.

Why it works

Risk is spread over time. Each slice is small enough to test, release, and roll back on its own. A mistake affects one capability, not the whole business.

Value arrives early. Users get the improved capability as soon as its slice moves, which keeps sponsors funding the programme and turns the migration into a stream of deliveries rather than a single promise.

Learning compounds. The first slices expose the hidden behaviour, undocumented integrations, and data quirks of the legacy system while the stakes are still low. Later slices are planned with that knowledge.

The old system keeps working. There is never a day when the business depends on software that has not yet carried real traffic.

Where it applies

  • Replacing a monolith or mainframe that is too large or too critical to rewrite in one go.
  • Moving to a new platform such as the cloud, a new database, or a new integration style, one capability at a time.
  • Re-drawing boundaries when the old system tangles several business domains together and you want each one owned by a separate team.
  • Buying instead of building, when parts of a home-grown system move to a SaaS product while the rest stays put.

How to apply

  1. Find the seams. Identify where requests or events enter the legacy system: user interfaces, APIs, batch jobs, message queues, database triggers. These are your interception points.
  2. Put a façade in front. Route traffic through a proxy, gateway, or event router you control. On day one it sends everything to the legacy system; later it decides, slice by slice, where each request goes.
  3. Choose the first slice carefully. Pick something valuable but bounded: one product line, one customer segment, or one business capability. Avoid the most tangled area first, and avoid something so trivial that it teaches you nothing.
  4. Decide how data moves. Data is usually the hardest part. Decide for each slice which system is the source of truth, and how the other stays in sync: change data capture, events, or a temporary shared database. Protect the new model from legacy concepts with an anti-corruption layer.
  5. Move, measure, repeat. Divert traffic gradually with canary releases or feature flags, compare outcomes with the legacy path, and widen the diversion as confidence grows. Track progress as traffic moved and legacy code deleted, not as new code written.
  6. Fund the ending. Plan and budget the decommissioning of each legacy component from the start, including the façade itself if it is no longer needed.

Example scenario

A retailer's order management ran on a thirty-year-old mainframe. A full rewrite had been tried and abandoned. The team instead put an API gateway in front of the mainframe's order interfaces and moved one product category, gift cards, to a new order service. Change data capture kept the mainframe's reports correct.

Gift cards taught them that order numbers carried hidden meaning for the warehouse, which they had not found in any documentation. Fixing that early made the next categories much smoother. Over two years they moved category after category. The final cutover was a non-event: the last route changed, and the mainframe was switched off a quarter later.

Questions to ask

  • Where can we intercept traffic to the legacy system?
  • What is the first thin slice to migrate, and what will it teach us?
  • Which data does each slice need, and who owns it during the transition?
  • What transitional code are we willing to build and later throw away?
  • How will we know the old system can be turned off, and is that date funded?

When not to use it

  • The system is small. If a rewrite takes weeks rather than years, the façade and transitional code cost more than they save.
  • You cannot intercept anything. Strangling needs a point where requests can be redirected. Without one, you must first create a seam, which may itself be a large project.
  • The old system must go quickly. If a licence, a data-centre exit, or a regulator sets a hard deadline, a carefully planned cutover may be the only option.

How it misleads you

The most common failure is stopping halfway. The easy slices move, the hard ones stay, and the organisation ends up running two systems indefinitely, paying for both and understanding neither. Strangling only reduces risk if the old system eventually dies, so plan and fund the decommissioning from the start.

It can also hide a lack of target design. Moving slices one by one does not tell you what the new architecture should be; it only tells you how to get there safely.

In the wild

Further reading

Last reviewed · Suggest an improvement