Replacing a legacy system in one go (rewrite, test, cut over all at once) concentrates an entire migration’s risk into a single event, often after months of development with no real-world validation. The strangler fig pattern flips the problem: a routing facade sits in front of the legacy system from day one, and every feature switches over individually to the new system, until the old one no longer serves any purpose.

The facade, the only new component at the start

The first step writes no new business functionality at all: it installs an entry point (a reverse proxy, an Ingress, a Gateway API) that routes 100% of traffic to the legacy system, exactly as before, but now through a component under your control.

# At the start, the facade routes everything to legacy,
# no visible behavior changes yet
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: strangler-facade
spec:
  rules:
    - backendRefs:
        - name: legacy-monolith
          port: 8080

This step, seemingly pointless since nothing changes for the user, is what makes everything that follows possible: it establishes the single control point every future switch will go through.

Switching one route at a time, never the whole system

Once the facade is in place, every migrated feature (a module, an endpoint, a specific route) gets rewritten independently in the new system, then the facade switches over only the traffic matching that precise feature, without touching the rest.

# A specific route switches to the new system,
# everything else still goes through legacy
rules:
  - matches:
      - path: {value: /api/invoicing}
    backendRefs:
      - name: new-invoicing-service
        port: 8080
  - backendRefs:
      - name: legacy-monolith
        port: 8080

The legacy and the new system then coexist for the entire migration, each handling its share of traffic, without either ever needing to handle the whole thing during the transition.

What this eliminates: all-or-nothing risk

A failed switch on a single migrated feature stays contained to that feature: rolling back (repointing the route to legacy) is a local operation, never calling into question all the work already migrated elsewhere. A single-event replacement doesn’t offer this granularity: a problem discovered after cutover forces either accepting it degraded or rolling back everything, with no middle ground.

The real cost: duration, not technical complexity

The strangler fig pattern generally spans several months, sometimes over a year for a sufficiently large system, a duration with a real organizational cost: maintaining two systems in parallel (the legacy still active, the new one under construction), with the team needing to understand both, an ongoing investment a single-event replacement doesn’t impose the same way, at the much higher price of the risk it concentrates in exchange.

Takeaway

Strangler fig installs a routing facade in front of a legacy system from day one, then switches over feature by feature to the new system, never all at once: every switch stays locally reversible, never putting all the migration work done elsewhere at stake. The real cost of this approach isn’t technical but organizational: maintaining two systems in parallel for a duration often spanning several months. That trade-off, duration against concentrated risk, is what structures the method of a Kubernetes migration that refuses to cut production to replace everything at once.