Engineering Practitioner Brief / 18 May 2026

Strangler Fig Migration Cost

The strangler-fig pattern is the most successful long-form migration pattern in software engineering. It avoids the big-bang failure mode by shipping value continuously while replacing the old system one piece at a time. The cost is real and the duration is long, but the published case histories show it works at scale. This page breaks down the per-component cost so a team can size a strangler-fig migration before committing.

The Pattern

Martin Fowler described the pattern in 2004, drawing the name from the strangler-fig tree (a species common in tropical forests, which grows around an existing tree and eventually replaces it). The software analog: build a routing layer in front of the existing system, then progressively implement functionality in a new system, routing traffic to the new implementations as they prove out. Over time, the new system grows until it has replaced the old; the old system is then turned off.

The key insight is that the old and new systems coexist for the duration of the migration. There is no big-bang cutover. There is no period of frozen development. Each new piece of functionality is a self-contained ship-and-verify-and-incrementally-route-traffic cycle. The risk of any one cutover is small because only one piece is changing at a time.

The Cost Components

The Routing Layer

The strangler-fig pattern requires an upstream component that can route requests to either the old or the new system based on rules. The choices in 2026 are well-developed: an API gateway (Kong, AWS API Gateway, GCP Apigee, Azure API Management), a service mesh sidecar (Istio, Linkerd), or a simple reverse proxy (Nginx, Envoy, HAProxy) with feature-flag-driven routing.

Cost ranges: $20,000 to $300,000 per year in infrastructure and licensing for the routing layer, depending on traffic volume and vendor choice. The lower end is a self-hosted Envoy or Nginx; the higher end is a fully-managed enterprise API gateway with high throughput. This cost is paid for the duration of the migration and usually persists afterward, since the routing layer is generally retained for ongoing canary deploys and traffic-management.

Per-Service Extraction

Each piece of functionality extracted from the old system into the new system has its own cost. The range is wide, dominated by domain complexity and data-ownership shape:

A typical monolith decomposition into 15 services lands in the 15,000 to 45,000 hour range for the extraction work alone. See monolith decomposition costfor the full cost arithmetic.

Parallel-Run Verification

For services where correctness is critical (payment, pricing, regulatory reporting), the strangler-fig pattern is typically combined with a parallel-run period. The new implementation runs alongside the old, both produce results, and a comparator flags divergences. Once the divergence rate is below an agreed threshold, the new implementation takes over.

Parallel-run infrastructure costs 100 to 500 engineer-hours per service to set up, plus the runtime cost of running the new service before it carries traffic. For services on the critical path the parallel-run period is non-negotiable; for low-stakes services it can be skipped in favour of a faster canary deploy. See parallel run refactor cost for the deeper treatment.

Coordination and Operational Tax

During the migration, both the old and new systems are in production. Cross-cutting changes (security patches, schema changes, feature flags) have to be applied to both. On-call rotations cover both. The duplication cost is typically 15 to 30 percent of engineering capacity for the duration of the migration. McKinsey 2023 research on engineering productivity confirms this range for transition projects.

The Cutover Decision per Service

For each service, the decision to fully cut over from old to new follows a predictable sequence:

1. Build the new implementation. Tests pass against the documented requirements.
2. Shadow mode. The new implementation runs on production traffic but its responses are discarded. The comparator measures divergence from the old. Run for 2 to 8 weeks depending on traffic patterns.
3. 1 percent traffic. Route a small share of real users to the new implementation. Monitor error rates, latency, business metrics.
4. 10 percent traffic. Confirm the new path scales and does not have failure modes that only emerge at volume.
5. 50 percent traffic. The new path is the primary implementation for half of users. At this point the old path is in standby mode.
6. 100 percent traffic. All users on the new implementation. The old path remains warm for a few weeks in case rollback is needed.
7. Decommission. The old code path is removed. The routing rule for this service is simplified.

Each step typically takes 1 to 4 weeks of calendar time, with engineer attention concentrated at the shadow-mode setup and at the final decommission. Total per-service calendar time from build start to decommission is typically 3 to 9 months.

The Indefinite Middle State Failure Mode

The most common strangler-fig failure pattern is the indefinite middle state. A team migrates 60 to 80 percent of traffic to the new system, then stops. The remaining functionality is the hardest (legacy admin paths, batch jobs, rare endpoints). The team moves on to other priorities. Both systems continue to exist indefinitely. Both have to be maintained, on-called, security-patched, and dependency-upgraded. The operational cost is roughly double the original monolith.

The mitigations are organisational rather than technical. Commit to a hard end-date for the old system before starting the migration. Treat the last-mile services as non-negotiable rather than optional. Assign sunset ownership to a specific team. Track the migration completion percentage in executive-level dashboards so the indefinite middle state becomes visible.

The cost of falling into this trap is high. A migration that stops at 70 percent and then runs both systems indefinitely costs more than either a successful full migration or a deliberate decision to stay on the monolith. The decision to start should include the discipline to finish.

Case Pattern Reference

Three published case histories of successful strangler-fig migrations, with rough dollar references:

• Shopify modular monolith (2016-2020): Reorganized a Rails monolith into bounded contexts using component-isolation rather than service extraction. Reported in Shopify engineering posts as multi-year, multi-million-dollar effort.
• Etsy services extraction (2014-2018): Extracted performance-critical components from a PHP monolith into Scala services. The strangler-fig pattern was explicit; the routing layer was custom. Full migration ran approximately 4 years.
• Stripe API versioning (ongoing): Not a system decomposition but uses strangler-fig logic at the request level: old API versions and new API versions both supported indefinitely, with internal translation, allowing gradual customer migration without forced upgrades. The cost is real (the API translation layer is non-trivial) and the benefit (customers never break) has paid for it many times over.

Related Reading

• Big-bang rewrite cost
• Parallel run refactor cost
• Monolith decomposition cost
• Feature flag refactor cost
• Legacy code refactoring cost

Frequently Asked Questions