Strangler Fig

The Strangler Fig pattern is a way to modernise a legacy system incrementally, by growing a new system around the edges of the old one until the old system can be retired. The name comes from the strangler fig vine, which germinates in the canopy of a host tree and grows down around it, eventually replacing it. Applied to software, the new implementation takes over one capability at a time while the legacy system keeps serving everything that has not been migrated yet.

Context and problem

Replacing a large legacy system in a single step is risky. A full rewrite ships no value until it is finished, the cutover is hard to reverse, and undocumented behaviour in the old system tends to surface late. Teams need a way to deliver the migration in small increments, keep both systems running side by side during the transition, and roll individual changes back without taking the whole platform down.

Solution

Instead of replacing everything at once, you migrate one capability at a time. A common way to do this is to place a facade in front of the legacy system that intercepts incoming requests and routes each one to either the legacy implementation or its new replacement. As more functionality moves to the new system, more traffic flows through the new path. When nothing is left pointing at the legacy system, it can be removed and the facade simplified or dropped.

Because the facade owns the routing decision, the migration stays incremental and reversible: a newly migrated route can be sent back to the legacy system at any time, and clients keep using the same address throughout.

Implementation with HARP

HARP is an API Forward Proxy that sits between your applications and the remote APIs they call. That position makes it a natural interception point for a strangler fig migration: applications keep calling the same HARP endpoint throughout, so the address they use never changes while the implementation behind it does.

This gives you one place to intercept and migrate traffic, route by route, without modifying the callers. HARP's rules engine runs Python at well-defined stages of the request lifecycle (on_request, on_remote_request, on_remote_response, on_response); on a route you have already migrated, a rule can inspect the request and short-circuit it, returning a response directly instead of forwarding it to the legacy remote.

During the cutover, HARP's remote pools and fallbacks keep the legacy system available as a safety net while the new path stabilises.

Conclusion

The Strangler Fig pattern turns a high-risk rewrite into a series of small, reversible steps. Running the migration behind HARP keeps the cutover point in one place, lets the legacy and new systems coexist during the transition, and leaves client code untouched until the old system can finally be removed.