Strangler Fig Migration diagram template

Builds a new scene in your browser. Your existing scenes are not touched.

About this design

Rewriting a large system from scratch rarely ends well; the strangler fig approach replaces it a slice at a time while production keeps running. A routing layer sits in front of the legacy application and decides, per URL or feature, whether a request goes to the old monolith or to a new service. Initially everything goes to the monolith. Each time the team extracts a capability, they build the new service, send a small share of traffic to it, compare behaviour and then move the route fully across. Data is the hard part, so the diagram shows the new service reading through an anti-corruption layer and syncing changes from the old database. Use it to plan the order of extraction, feature flags for gradual cutover, how to retire the old code safely, and how to know when the monolith is small enough to turn off.

Diagram as text

This is the source of the diagram, in the ArchBoard diagram DSL. Paste it into Tools, Diagram from text to rebuild or change it.

title "Strangler fig migration"
direction LR
user "Users" -> proxy nginx "Routing proxy"
routing-proxy -> service legacy "Legacy monolith" -> db mysql "Legacy database"
routing-proxy -[new routes]-> microservice billing "Billing service" -> db postgres "Billing DB"
legacy-database -[CDC sync]-> worker sync "Sync worker" -> billing-db
flags "Feature flags" -> routing-proxy