The strangler fig pattern applied to frontends

The strangler fig pattern replaces a legacy system piece by piece while it keeps running. This guide shows how it works for a frontend, where the seam goes and what a real sequence looks like.

The idea in one paragraph

A strangler fig grows around a host tree and, over time, takes its place. Martin Fowler used the image to describe a way of replacing legacy systems: build the new system around the edges of the old one, route more and more work to the new parts, and remove the old parts as they become unused. At no point is there a single switch-over day.

For a frontend this means users keep one product, one URL and one login while the code behind each screen changes.

The key decision: where the seam goes

The pattern needs a place where a request can be sent to old code or to new code. In a frontend there are three practical places.

How to choose the seam

• If the old app is AngularJS and the target is Angular, the shell-level seam is usually the better fit, because both sides can share services directly. The details are in How to migrate AngularJS to Angular without downtime.
• If the two sides cannot run in the same page, use the edge. Navigation between old and new is then a full page load, so pick boundaries where users rarely jump back and forth.
• If the old pages are server-rendered with scripts on top, start inside the page and move to whole pages later. The jQuery migration guide follows this route.

What old and new must share

The pattern fails when users can see the seam. Four things need to be shared from the first day:

• Session. One login. Both sides read the same token or cookie and react to expiry the same way.
• Navigation. One menu and one set of URLs. Deep links and the back button behave as before.
• Look. Shared styles or design tokens, so a migrated screen does not look like a different product.
• Data layer. One source for the current user, permissions and settings. Two copies of the same state produce bugs that are hard to reproduce.

An example sequence

Take an order management app with five areas: dashboard, orders, customers, reports and settings.

1. Inventory and seam. List the screens of each area. Choose the shell-level seam. Decide that reports is the pilot, because it is read-only and isolated.
2. Build the shell. The new application starts first and loads the legacy app inside it. Unknown routes fall through to the legacy router. Users notice nothing.
3. Share the plumbing. Move authentication and the HTTP layer to the new side and expose them to the legacy side.
4. Strangle the first route. Rebuild the reports list in the new framework. Put the route behind a switch. Release it to internal users, then to everyone.
5. Delete. Once reports is stable, remove its legacy code. The old app is now smaller.
6. Repeat by area. Settings next, then customers. Each area follows the same steps: rebuild, switch, observe, delete.
7. Take the centre. Orders is the busiest and most complex area. It goes late, when the patterns are proven and the team is fast.
8. Replace the frame. Move the navigation, the layout and the login to the new side.
9. Remove the host. No route reaches the legacy app. Delete it, the old router and the bridge between the two.

Each numbered step is released on its own. Feature work continues in every area that is not being migrated at that moment.

Pitfalls

When the pattern is the wrong tool

For a small app that one developer can rebuild in a few weeks, the seam costs more than it saves. A direct rewrite is simpler. The comparison is in Rewrite, hybrid or micro-frontends.

More in this section

• Feature flags and route switches in an incremental migration
• Leaving AngularJS: Angular or React?
• Migrating a jQuery-heavy app to a component framework
• Migrating Backbone, Knockout and old Ember applications