Modernization almost always happens while the old system is still serving real users. That means you usually cannot switch it off and start over. A full rewrite asks the team to recreate years of behavior, data rules, permissions, edge cases, and integrations before users see any of it. That puts a huge amount of risk into one big launch.

The Strangler Fig Pattern, named after a vine that slowly grows around a tree until it replaces it, takes a safer path. You put a routing layer in front of the old application, then move one feature or business area at a time to a new service. Everything else keeps running in the old system until it is ready to move.

The goal is to keep the client entry point stable while the old system slowly shrinks. When the old system has no remaining responsibility, you can retire it. This chapter explains how the routing layer works and how to plan a safe migration.

A full rewrite can work for a small system with clear behavior and few integrations. It becomes risky when the old system is large, important to the business, and poorly documented.

The usual failure mode is uncertainty: hidden rules, changing requirements, and feedback that arrives too late.

Large rewrites run into predictable problems. The legacy system often contains hidden behavior and business rules that exist only in code, data, or operator habits.

Requirements keep moving because the old system changes while the replacement is being built. The feedback cycle is long because the new system learns from production late in the project. The all-at-once launch puts most of the risk into one release window.

Data can mismatch when the new system uses the wrong owner for a piece of data or misses old edge cases. Teams can also drift away from shipping value because everyone is busy preparing for the rewrite.

The Strangler Fig pattern reduces this risk by turning one large replacement into many smaller replacements.