You've inherited a monolithic legacy system that needs to be replaced. Management wants a rewrite. Your instinct says "let's rebuild it from scratch." Stop right there. Full rewrites are where projects go to die. The Strangler Fig pattern gives you a safer path.

Named after strangler fig trees that grow around a host tree and gradually replace it, this pattern works by incrementally replacing pieces of a legacy system while keeping it running. No big bang cutover. No "we'll launch the new system in six months" promises that turn into two years.

How it works in practice:

• Step 1: Insert a facade. Place a routing layer (an API gateway, reverse proxy, or thin abstraction) in front of the legacy system. All traffic flows through it. Initially, it routes everything to the old system unchanged.
• Step 2: Build one new component. Pick a well-bounded piece of functionality — say, the user profile service — and reimplement it in the new stack.
• Step 3: Redirect traffic. Update the facade to route user profile requests to the new service. Everything else still hits the legacy system.
• Step 4: Repeat. Migrate the next piece. Then the next. The legacy system shrinks with each iteration until nothing routes to it.

Real-world example: Suppose you have a legacy PHP monolith handling orders, inventory, users, and reporting. You stand up an Nginx reverse proxy in front of it. You rebuild the reporting module as a new service. You update Nginx so that /api/reports/* routes to the new service while everything else still hits PHP. Users notice nothing. You now have a proven migration path and can tackle inventory next.

Choosing what to migrate first matters. A good rule of thumb: pick the component with the highest change frequency and lowest coupling to the rest of the system. If a module changes 3x more often than average but only shares a database table or two with other modules, it's a strong candidate. High-churn, low-coupling components give you the most return on migration effort with the least risk of breaking something.

Common pitfalls:

• Shared databases. The old and new systems both reading and writing to the same tables creates subtle bugs. Prefer giving the new service its own data store and synchronizing via events or a change data capture pipeline.
• Skipping the facade. Without a routing layer, you end up with clients needing to know which system to call. The facade is what makes the migration invisible to consumers.
• Never finishing. Teams migrate the painful parts and leave a "legacy core" running forever. Set a clear milestone for decommissioning the old system, even if it's a year out.