Most organizations have at least one legacy system that quietly runs something critical – an order engine, billing platform, or internal portal that’s too risky to touch yet too outdated to scale. Modernization is the obvious answer, but complete rewrites rarely go as planned. Projects stretch for years, teams burn out, and by the time the new system launches, it’s already behind.
The strangler fig pattern offers a different path. Instead of replacing your legacy system all at once, you gradually build a modern one around it – piece by piece – until the old system is naturally “strangled” and retired. It’s a strategy that reduces risk, preserves uptime, and delivers measurable wins along the way.
What the Strangler Fig Pattern Is
The term comes from nature: strangler fig trees grow around existing trees, slowly replacing them until the original trunk disappears. Applied to software, the same concept means wrapping a legacy application with new components, routing functionality through modern services until nothing remains of the old core.
Martin Fowler first articulated the strangler fig pattern, and it’s become a go-to approach for enterprises that can’t afford downtime or disruption. Unlike a “big-bang” rewrite, the strangler method enables incremental modernization – small, safe deployments that deliver immediate value and feedback.
Here is a diagram that shows what a mid-flight modernization architecture may look like when using a strangler fig migration approach.
Key benefits
- Reduced business risk; no all-or-nothing cutovers
- Continuous delivery of new capabilities
- Easier rollback and validation at every stage
- Gradual cultural and technical adoption of modern practices
When (and When Not) to Use It
The strangler fig pattern is ideal when your system is large, business-critical, and can’t be taken offline. It shines in environments where change must happen safely, without breaking dependencies or compliance boundaries.
Best Fits
- Monolithic applications with modular boundaries or clear domains
- Systems that require 24/7 uptime or have heavy compliance needs
- Teams capable of continuous delivery and observability
Poor Fits
- Small systems that could be rewritten faster
- Highly entangled legacy code with no identifiable seams
- Environments lacking test coverage or routing control
At a Glance
Compared to other strategies, the strangler fig pattern delivers value sooner, minimizes downtime, and leaves you with reusable, modular components rather than a single new monolith. It’s modernization through evolution – not replacement.
Preparing for Modernization
Before writing a single line of new code, you’ll need a solid foundation. The strangler fig pattern depends on understanding what you have, what you can isolate, and how you’ll observe progress.
1) Define success
Clarify what modernization means for your organization (e.g., faster releases, lower maintenance costs, or improved scalability). These goals will guide which functions to extract first.
2) Map your system
Inventory modules, interfaces, and dependencies. Identify bounded contexts – logical groupings of functionality that can be extracted without massive disruption. Domain-driven design tools (like context mapping) can help reveal these seams.
3) Establish observability
You’ll need reliable logging, metrics, and traces before you start diverting traffic. Without baseline data, it’s impossible to tell if new services perform better or worse.
4) Set up a gateway or proxy
Introduce a layer (e.g., NGINX, Envoy, or an API gateway) that can intercept requests. This will later allow you to reroute specific endpoints to new services without changing clients.
A Step-by-Step Migration Approach
The beauty of the strangler fig pattern lies in its rhythm: proxy, extract, validate, repeat. Each iteration replaces one piece of the old system with a modern counterpart.
1) Introduce a strangler proxy
Start by routing a single endpoint or API call through a proxy that you control. At first, it still forwards everything to the legacy application, but now you have a central control point for metrics, logging, and gradual routing changes.
You can log response times, errors, and payloads from the legacy system to benchmark future replacements. Once the proxy is stable, you have the foundation to begin carving out new functionality.
2) Extract the first service
Pick a function that’s self-contained but valuable; for instance, a read-only catalog or reporting API. Build it as a standalone service using your modern stack (for many teams, that might mean Laravel, Node, or .NET Core).
Use an anti-corruption layer to translate between old data models and the new domain objects.
Deploy it, but keep the legacy version live. Then, configure your proxy to route a small subset of traffic to the new service and compare outputs.
3) Handle data safely
Data is often the most challenging part. You can’t strangle a system if both old and new modules depend on the same database without coordination.
Common strategies include:
- Dual reads/writes: Both systems read and write to validate parity before cutover
- Change Data Capture (CDC): Tools like Debezium replicate database changes to event streams
- Outbox pattern: Capture changes in a transactional outbox and publish asynchronously
The goal is confidence – ensuring the new service produces identical results before full traffic shifts.
4) Gradually shift traffic
Once validated, you can start shifting more requests to the new service using feature flags or weighted routing.
Monitor latency, error rates, and user experience metrics. When parity and performance hold steady, reroute all traffic to the new component.
5) Retire legacy code
After migration, remove the old endpoints and clean up unused dependencies. This step may seem minor, but it’s critical for preventing “zombie code” that clutters repositories and confuses future developers.
Each successful slice builds momentum. Over time, your monolith becomes lighter, your services more autonomous, and your architecture easier to evolve.
Managing Data and Dependencies
Legacy systems are often tangled with shared data stores, batch jobs, and integrations, making modernization tricky. The strangler fig approach doesn’t avoid these problems – it isolates and systematically manages them.
- Shared databases: Start by creating views or APIs that shield new services from direct access. Migrate ownership gradually, one entity at a time.
- Batch processes: Rebuild them as event-driven pipelines instead of nightly exports, stream updates in near real time.
- Reporting: During transition, generate reports from the old database and validate against new tables to ensure parity.
Each dependency you decouple makes future slices easier to migrate and test.
👋 Want to see how the strangler fig pattern could work for your system?
Talk to our modernization experts to learn how Curotec can help.
Trusted by tech leaders at:
Testing, Monitoring, and Rollback
Incremental modernization depends on trust – the confidence that new components behave like the old ones, only better. That trust comes from disciplined testing and observability.
1) Compare outputs
Run “shadow traffic;” duplicate real user requests to both old and new services and compare responses. Any mismatches trigger an investigation before release.
2) Contract testing
Use consumer-driven contract tests to ensure clients interacting with the API aren’t affected by changes behind the proxy.
3) Observability and alerting
Correlate logs, traces, and metrics across both systems. Tools like OpenTelemetry, Prometheus, and Grafana make it easier to spot latency or error deviations early.
4) Rollback strategy
If something breaks, instantly route all traffic back to the legacy component via your proxy. Because both systems run in parallel, rollbacks are fast and low-risk.
Risk Management and Best Practices
Every modernization has risks, but most stem from scope creep and partial migrations that never finish. Avoid those traps by following a few guiding principles:
- Start small and prove the loop. Your first slice should be narrow but representative – something that tests routing, data, and validation end to end.
- Don’t share databases long-term. It’s fine temporarily, but plan for each service to own its data.
- Keep a living migration roadmap. Track what’s been strangled, what’s in progress, and what’s next.
- Measure outcomes. Celebrate each successful cutover; visible progress builds organizational confidence.
- Invest in automation. CI/CD pipelines, canary releases, and feature flags make incremental modernization sustainable.
Culturally, the strangler approach teaches teams to deliver smaller, verifiable chunks of value – a habit that persists long after the legacy system is gone.
Measuring Progress and Success
To maintain buy-in, treat modernization like a product initiative with clear metrics.
Technical KPIs
- Percentage of traffic offloaded from the monolith
- Reduction in deployment risk and downtime
- Improved performance (latency, throughput)
- MTTR for incidents across migrated services
Business KPIs
- Faster release cycles for new features
- Reduced infrastructure or licensing costs
- Improved reliability and customer satisfaction scores
Dashboards that visualize these metrics make progress tangible, and help leadership understand that modernization isn’t an expense, rather a capacity-building investment.
Modernization Without the Meltdown
The strangler fig pattern turns modernization from a massive, high – risk overhaul into a series of controlled, reversible experiments. Each slice delivers new capability while de-risking the next. Over time, your legacy core fades away – not through disruption, but through steady evolution.
The pattern isn’t just about technology; it’s about shifting how teams think about change. By working in small, observable increments, organizations gain confidence, agility, and momentum.
If your team is exploring how to modernize without breaking what works, Curotec can help design and pilot a strangler-based modernization roadmap tailored to your systems and delivery goals. Start small. Measure often. And let the new architecture grow naturally around the old – one slice at a time. Contact us to learn more.
