Strangler fig is a sequencing principle, not a migration strategy
The strangler fig pattern describes a way of incrementally replacing a legacy system by routing functionality to a new system piece by piece until the legacy system can be retired. It is elegant as a concept. In practice, it is consistently applied as if choosing the pattern solves the migration problem. It does not. The pattern tells you the sequencing approach. It tells you nothing about what you are building, how you are routing, how you manage the transition period, or what done looks like.
What the pattern actually requires
Implementing the strangler fig pattern requires three things that are harder than they appear: a routing layer that can intercept requests and direct them to either the legacy system or the new system; a clear decomposition of the legacy system into units that can be migrated independently; and a migration sequence that manages dependencies between those units.
The routing layer is often underestimated. Depending on the architecture, it might be an API gateway, a service mesh, a facade layer, or an application-level router. The routing layer itself becomes a dependency that needs to be maintained, monitored, and eventually removed as the migration completes.
Decomposition is where the real work is
Decomposing a legacy system into independently migratable units requires deep understanding of how the system actually works, not how it was designed to work, but how it works now, after years of changes, hotfixes, and undocumented integrations. This is discovery work, and it consistently takes longer and surfaces more complexity than initial estimates allow.
The order of migration is not determined by what is technically convenient. It is determined by what the business can absorb. Migrating the subsystems that generate the least risk while delivering the most learning is a better sequence than migrating in technical dependency order.
The dual-running period is a cost, not just a risk
During the strangler fig transition, both systems are running. Both need to be maintained. Both need to be monitored. Both need support. This is not a transitional inconvenience. It is a sustained cost that should be explicit in the migration business case. Programmes that plan for a short dual-running period consistently find it extending.
Define exit criteria before you start
The strangler fig pattern only works if there is a clear definition of what constitutes complete migration, the criteria that allow the legacy system to be retired. Without exit criteria defined upfront, legacy systems linger indefinitely, dual-running costs accumulate, and the migration never quite reaches done.
