Strangler Fig Modernization: Incrementally Replace a Legacy App Without a Big Bang

Legacy applications rarely fail because one line of code is “old.” They fail because the surrounding world changed: the team changed, the integrations changed, the data grew, the uptime expectations grew, and nobody remembers the original constraints.

That’s why “rewrite it” is tempting. It offers a clean slate and a clean architecture diagram. In practice, big-bang rewrites often stall, overrun, or ship something that matches the new codebase but not the messy reality of production behavior.

The Strangler Fig pattern is a calmer option: you gradually replace parts of the legacy system while keeping it running. You build a controlled path for traffic to move from old to new, slice by slice, until the legacy system is mostly bypassed and eventually retired.

What the Strangler Fig pattern is

The name comes from a vine that grows around a tree. Over time, the vine becomes the primary structure and the original tree becomes less relevant. In software terms: the legacy application continues to exist, but you route certain functionality to new components until the legacy path is no longer used.

The pattern works best when you can introduce a boundary layer that decides, for a given request or workflow, whether the legacy app handles it or the new system does. That boundary can be a reverse proxy, an API gateway, a UI router, a backend-for-frontend, or even a simple “facade service” that calls old code behind a new interface.

Most importantly, Strangler Fig is not a single migration project. It is a series of small migrations that share a few common capabilities: stable contracts, safe routing, reliable monitoring, and a clear way to roll back when something breaks.

Choose your first slice

The first slice sets the tone. If you pick something too big, you recreate the pain of a rewrite. If you pick something too small or invisible, you lose momentum and stakeholders do not feel progress.

A good first slice has these properties

• Clear ownership and purpose: one team can deliver it without waiting on five others.
• Minimal data entanglement: it reads a few tables or calls a couple of endpoints, not the whole database.
• User-visible value: improved speed, fewer clicks, fewer errors, or simpler support handling.
• Easy to validate: you can compare outcomes between old and new (counts, statuses, totals).
• Reversible: you can route back to the old path if needed.

One practical way to choose is to list your top 10 pain points (support tickets, slow pages, fragile integrations), then score each item for “boundary clarity” and “blast radius.” Aim for high clarity, low blast radius.

Build the seam: routing, facades, and data boundaries

The seam is the shared infrastructure that lets old and new coexist. Without it, every slice becomes a custom adventure with unpredictable risk. With it, each slice becomes a repeatable move: define a contract, implement new behavior, route traffic, measure, expand.

At minimum, the seam should answer four questions:

• Routing: How do we decide which system serves which request or workflow?
• Contracts: What exactly does the new component promise to accept and return?
• Observability: How will we detect failures, regressions, and mismatched behavior?
• Data boundaries: Which system is the source of truth for each domain and how do changes flow?

Here is a conceptual structure for the seam. Keep it boring and consistent, because you will use it repeatedly:

Request
  -> Router (rule: path/feature flag/account)
      -> New Service (owns domain slice)
      -> Legacy App (fallback)
  Observability: logs + metrics + trace id across both
  Data: explicit source of truth per entity, with sync rules if needed

Data boundaries deserve special attention. Many “incremental modernization” efforts fail because the data story stays implicit. Decide early whether the new slice will:

• Read legacy data only: safest early move, but limits improvements and can lock you in.
• Write to legacy as system of record: common middle step; the new UI or service writes through a compatibility layer.
• Become the system of record: higher payoff, but requires clear migration, backfills, and integration updates.

It is fine to evolve from “read-only” to “write-through” to “source of truth.” What is not fine is having both systems write the same fields with no arbitration. That is where data drift and reconciliation pain start.

A concrete example: modernizing an order management portal

Imagine a mid-sized distributor with a legacy order management portal used by internal sales and support. The portal is a monolith: server-rendered pages, a shared database, and a tangle of permissions logic. The business wants faster order lookup, fewer accidental edits, and a cleaner audit trail.

Step 1: pick a slice. The team chooses “Order Search and View” as the first slice. It is high-traffic, user-visible, and mostly read-only. Editing orders is postponed for later because it touches invoicing, inventory, and customer notifications.

Step 2: build the seam. They introduce a router at the edge that sends /orders/search and /orders/{id} to a new service, but everything else still goes to the legacy app. The router rule can be toggled per user role, so a small group can trial it first.

Step 3: create a clear contract. The new service exposes an API contract focused on a stable “Order Summary” view model. Internally it reads from the legacy database using a read replica or carefully scoped queries. It also stamps every response with a trace id so support can correlate reports.

Step 4: validate behavior. For two weeks, the team runs “shadow comparisons” for a subset of users: when a user searches, the system retrieves results from both new and legacy and compares counts and key fields. Any mismatch creates a log entry and a review queue.

Step 5: expand scope. Once search and view are stable, the next slice becomes “Order Notes.” Notes are a bounded subdomain with minimal side effects. The new system becomes the source of truth for notes, and the legacy app reads notes through a compatibility API. That reverses the dependency: new owns, old consumes.

After several slices, the portal’s “read experience” is almost entirely new, while sensitive write flows remain legacy until the team is ready. Progress is visible to users, risk is contained, and the team avoids a single giant cutover date.

Implementation checklist

Use this checklist as a reusable playbook for each slice. The goal is consistency: predictable delivery, predictable risk.

1. Define the slice boundary: name the entry points (URLs, API methods, background jobs) that belong to the slice.
2. Write the contract first: inputs, outputs, error behavior, and authorization rules in plain language.
3. Decide data ownership: for each entity and field, specify the source of truth and write path.
4. Add routing controls: feature flag, per-account switch, or percentage rollout with easy rollback.
5. Instrument end to end: logs and metrics for success rate, latency, and key business counts.
6. Run parallel validation: compare old vs new for a subset where feasible (shadow mode or sampling).
7. Prepare support tooling: trace id lookup, clear error messages, and a known escalation path.
8. Document “what changed”: short internal notes for operators and future maintainers.
9. Retire legacy paths: remove routes, disable UI links, and delete dead code when usage reaches zero.

Common mistakes

• Modernizing the architecture before the behavior: new frameworks are not value by themselves. Make sure each slice delivers a user or operator benefit.
• Ignoring permissions and roles: authorization logic is often the most entangled part of legacy systems. Model it explicitly and test it early.
• Letting the seam become a junk drawer: if the router and facade accumulate special cases, you recreate a monolith at the edge. Keep routing rules simple and time-box exceptions.
• Two sources of truth: if both systems can update the same customer record, order status, or pricing field, you will eventually get drift. Pick an owner.
• No plan to delete: incremental replacement is only a win if old code paths are actually retired. Track legacy usage and schedule removals.

When not to use this approach

Strangler Fig is powerful, but not universal. Consider other approaches if:

• You cannot introduce a routing boundary: if the legacy system is a thick client with no controllable gateway, you may need a different migration strategy.
• The system is small and stable: if modernization cost exceeds the risk of leaving it alone, do maintenance instead.
• Hard real-time constraints dominate: some systems need deterministic, tightly coupled behavior where “two systems in parallel” is not acceptable.
• You cannot staff ongoing dual-running: for a period, you will support old and new simultaneously. If you cannot afford that, plan a shorter cutover with heavier testing.

Even when you do use Strangler Fig, be honest about the “two systems tax.” You are trading a single risky leap for a series of smaller, manageable costs.

Measuring progress and knowing when you are done

Incremental modernization can feel endless if you do not define completion. Measure progress using a mix of technical and operational signals:

• Traffic moved: percentage of requests served by the new system for the targeted routes.
• Legacy surface area reduced: number of pages/endpoints/jobs still required for core workflows.
• Operational load: support tickets, mean time to restore, and on-call interruptions.
• Delivery speed: lead time for changes in the modernized slice versus legacy.

Define “done” per domain. For example: “Orders domain is modernized when search, view, notes, and edits are served by new services, the legacy portal no longer touches order tables directly, and the legacy order screens are removed from navigation.”

Finally, schedule a deliberate retirement phase. Archive data as needed, remove routes, decommission servers, and close the loop with finance and security teams so you actually stop paying for the old footprint.

Conclusion

The Strangler Fig pattern is a practical way to modernize software without betting the company on a single cutover. Done well, it produces steady user-facing improvements while reducing risk through routing control, clear contracts, and explicit data ownership.

Start with one slice that matters, build a seam you can reuse, and treat deletion of legacy paths as a first-class deliverable. Incremental does not mean slow. It means measured.

FAQ

How long should a single slice take?

Aim for weeks, not quarters. If a slice consistently takes longer than 6 to 8 weeks, it is likely too large or too entangled. Split it by workflow step, user role, or read versus write behavior.

Do I need an API gateway or reverse proxy to do Strangler Fig?

Not always, but you need some form of controllable boundary. In UI-heavy apps, this might be a frontend router. In service architectures, it might be an edge router or a facade service that keeps the old system behind a stable interface.

When should the new system become the source of truth?

After the new slice is stable in production, well-instrumented, and you have a clear backfill and rollback plan. Many teams succeed by first reading legacy data, then writing through to legacy, and only later switching ownership for a bounded entity.

How do we test without duplicating every test twice?

Focus on contract-level checks and a small set of high-value end-to-end scenarios. Add “parallel validation” where feasible (sampled comparisons between old and new). You do not need identical test suites, but you do need comparable outcomes for critical paths.