Migrating from Monolith to Microservices: The Strangler Fig Pattern

Migrating a production monolith to microservices is one of the highest-risk programmes in enterprise software engineering. The instinct to design the target architecture, freeze the monolith, and execute a big-bang cutover is almost universally wrong — and has led to more failed transformation programmes than any other single pattern.

What is the Strangler Fig Pattern?

Named after the strangler fig tree, which grows around a host tree and eventually replaces it, the Strangler Fig migration pattern incrementally replaces monolith components with microservices while both run in production. An API gateway or routing layer directs traffic to the appropriate system, with the monolith handling anything not yet migrated.

Phase Sequencing

Migration sequencing should be governed by two criteria: business value delivered and coupling complexity. Start with services that have clear boundaries, high change frequency, or the most to gain from independent scaling. Avoid starting with highly coupled domain cores — these become blockers if dependencies are not properly resolved first.

The Verification Requirement

Each migrated service must be verified against the monolith in parallel before traffic is shifted. Response equivalence testing, load testing at production scale, and chaos engineering are non-negotiable validation steps before a monolith component is decommissioned.