strangler-fig-method

Replaces a component by growing a new implementation alongside the old one, behind a facade that routes traffic, slice by slice, until the old one has no callers left and can be deleted.

When to use

Precondition

Same green safety net as Mikado (characterize-with-contracts) — here replayed against BOTH the old and the new implementation; a slice only cuts over when NEW is contract-equivalent to OLD on every harness test.

Procedure (summary)

  1. Facade — introduce (or confirm) a routing seam; otherwise the facade is slice zero (transparent, verified against OLD only)
  2. Slice — partition the contract into independently-cutover-able slices (default: one per endpoint)
  3. Build NEW — implement one slice, replay the same characterization tests against NEW (contract equivalence)
  4. Cutover gate (S4) — cut over only if NEW tests pass (same assertions as OLD) AND the full harness stays green
  5. Strangle — repeat; once OLD is unreachable, remove OLD + the facade’s OLD branch (final slice)

Exit contract

Invariants

Why this shape

The facade contains the blast radius: each slice cuts over independently, with fine-grained rollback, and contract equivalence is verified by the same tests against both implementations.

« Gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled. » — Fowler, M., Bliki: StranglerFigApplication, 2004.

Allowed customisation

See also