Strangler fig, in practice

The pattern everyone cites and half-implements. The three rules that make it work on a real estate, learned the expensive way.

Pixel drawing of a vine winding up and over a stone column

Fowler named the pattern twenty-odd years ago: grow the new system around the old one, route traffic over piece by piece, decommission when nothing is left. Every modernization deck since has a strangler-fig slide. Most projects run something else: a rewrite with the pattern's name taped on.

The difference is checkable. Here is what the real thing requires.

  1. The facade goes in first, before any new code. A routing layer you control (proxy, API gateway, even DNS if that's what you have) in front of the old system, passing 100% of traffic through, changing nothing. Boring on purpose. If you cannot ship the do-nothing facade, you have learned something important about the estate before betting on it.
  2. Slices are vertical and small. One route, one report, one transaction type. Value flows monthly, not at the end. The moment someone proposes migrating "the data layer" as a slice, you are in a rewrite. Stop and renumber.
  3. The old path stays warm until the ledger says otherwise. Run both, compare outputs, keep rollback one config change away. Divergence is a finding, not an embarrassment; half the time the divergence is a bug in the old system that the business has been silently absorbing for years.

The part the slide decks skip: the fig only finishes if decommissioning is a funded project, not an aspiration. The pattern's whole point is that there is never a big-bang cutover, which also means there is never a dramatic moment that forces the old system off. You have to schedule its death deliberately, seam by seam, or you end up running two estates forever and calling it progress.

Sequencing is where we earn our fee, and the rule is unromantic: strangle along the seams the system already has, not the ones the target architecture wishes it had. Finding those seams is its own entry. Start with the slice that is read-heavy, low-write, and owned by a team that wants to move. Bank the win. On a billing rebuild the cleanest seam is usually one finance already drew, which is why we slice the payment rebuild by invoice type. The org's patience for slice twelve is purchased by slices one through eleven landing on schedule.

One war story, serial numbers filed off. A distributor's order system, nineteen years old. The facade went in over a weekend. First slice, order status lookup, took three weeks. The fortieth slice took two days, because by then the team had the muscle. Total wall time: fourteen months, zero cutover weekends, one incident, caused by the old system, which was by then serving 4% of traffic. That is what the pattern looks like when it is actually running. It looks like nothing happening, monthly, on purpose.