Skip to content
Back to skills

Strangler Fig

ASecurity

Replace a legacy system incrementally behind a routing facade, moving one slice at a time instead of a big-bang rewrite. Use when retiring or rewriting a system that must keep running throughout.

  • 7 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 5, 2026
ai-agentsrustgoapi

Works with

  • api

Security analysis

A100/100

Scanned September 5, 2026

npx -y skills add Amey-Thakur/AI-SKILLS --skill strangler-fig --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Strangler Fig?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Strangler Fig
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/amey-thakur-strangler-fig/badge)](https://www.skillsdirectory.com/skills/amey-thakur-strangler-fig)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: strangler-fig
description: Replace a legacy system incrementally behind a routing facade, moving one slice at a time instead of a big-bang rewrite. Use when retiring or rewriting a system that must keep running throughout.
---

# Strangler fig

A big-bang rewrite ships nothing for months, then swaps two systems at once
and prays. The strangler fig pattern, named for the vine that grows over a
tree until it stands on its own, replaces a system piece by piece behind a
facade that routes each request to old or new. Value ships continuously and
rollback is a config change.

## Method

1. **Put a facade in front of the old system.** Route all traffic through one
   interception point: a reverse proxy, an API gateway, or a dispatch layer.
   Until every call passes through that seam, you have nowhere to redirect a
   slice from old to new.
2. **Carve off one thin vertical slice.** Pick a single endpoint or
   capability, low-risk and self-contained, and reimplement just that in the
   new system. Resist starting with the scariest module; start where a win
   is cheap and reversible.
3. **Route the slice to new, keep the rest on old.** Flip that one route at
   the facade. The new path handles its slice while everything else stays on
   the legacy system, untouched and serving.
4. **Shadow before you trust.** Send the slice to both systems, compare
   outputs, and log divergence, but keep serving the old result until the new
   one matches on real traffic. Shadowing catches the cases your tests
   missed.
5. **Migrate data on the slice boundary.** Move or sync only the data the new
   slice owns, using dual-write or change-data-capture so both systems stay
   consistent during the overlap. Do not migrate the whole store up front.
6. **Retire the strangled path, then repeat.** Once a slice runs clean on new
   long enough, delete its old code and data. Iterate slice by slice until
   the legacy system serves nothing, then remove the facade if nothing else
   needs it.

## Checks

- Can you point to the single facade every request flows through?
- Is at least one slice fully served by the new system in production right
  now?
- Can you route a slice back to the old system with a config flip and no
  deploy?

## Boundaries

Strangler fig suits systems large enough that a rewrite would take months and
must keep running throughout; a small script is cheaper to replace outright.
This skill governs migration shape, not the safety of edits to the legacy
code you keep touching along the way: for those, see legacy-code-changes.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…