Strangler Fig Migration

Martin Fowler named it after a fig that grows around a host tree until the tree is no longer needed. Instead of a big-bang rewrite, you grow the new system around the old one until the old one only holds what isn’t worth moving.

Three buckets

1. Delivered and stable: leave it. Migrating something that already works, and that nobody is changing, is cost and risk with no benefit to its users.
2. Still relevant, still changing: migrate it. Prioritise by how often it changes and how much the old system hurts.
3. Everything new: only on the new platform, from day one. This is the rule that actually shrinks the legacy system. Without it, the old one keeps growing while you migrate.

A routing or façade layer in front means callers don’t care which system serves them. Keep the old system maintainable but frozen: no new features there.

Measure it

Track the share of new work landing on the new platform, how many people the old system still needs to keep running, and the point at which switching it off becomes boring rather than scary.

Where I’ve used it

On a low-code network automation platform (Building a Low-Code BPMN Workflow Platform), long-lived automations, such as moving customers between network sites or automating infrastructure across whole regions, stayed on the legacy workflow engine once they were delivered. The ones still being changed were migrated, and every new use case went on the new platform. It’s the same instinct, at a much smaller scale, as an incremental build-tool migration (Progressive Overload and Incremental Migration).