SA-301b · Module 1

Strangler Fig Migration

3 min read

No team starts with microservices. They start with a monolith that served them well until it did not. The strangler fig pattern — named after the vine that gradually envelops a host tree — is the migration strategy that replaces monolith functionality incrementally. Extract one bounded context at a time. Route its traffic to the new service. Verify correctness. Move to the next context. The monolith shrinks as the services grow.

Do This

  • Extract the bounded context with the highest change velocity first — it benefits most from independent deployment
  • Run the monolith and the new service in parallel with traffic splitting — verify correctness before cutover
  • Maintain the monolith's database schema during migration — new services write to their own stores, a sync layer bridges the gap

Avoid This

  • Attempt a big-bang rewrite — the monolith is running the business, you cannot stop the business to rewrite the architecture
  • Extract services before validating the bounded context boundaries — you will move the coupling, not eliminate it
  • Share the monolith's database with the extracted service — that is not extraction, that is a distributed monolith on day one