The Strangler Fig Pattern: Modernise Legacy Apps Without Rewrites

The Strangler Fig Pattern: How to Modernise Legacy Applications Without Starting Over

What Is the Strangler Fig Pattern?

The Strangler Fig pattern is a gradual migration approach that lets you modernise legacy applications incrementally by routing traffic to new services while keeping the old system running. Named after the strangler fig vine that grows around trees, this pattern wraps new functionality around existing systems until the legacy code can be safely removed.

For Australian mid-market companies running critical monoliths built on .NET Framework, Java 8, or PHP, the Strangler Fig pattern offers a safer path to modernisation than "big bang" rewrites. Instead of spending 18-24 months rebuilding everything from scratch, you can deliver value every sprint while reducing risk.

When to Use the Strangler Fig Pattern

The Strangler Fig pattern works best for specific scenarios where other modernisation approaches fall short. Use this pattern when your legacy application meets these criteria:

Ideal candidates:

• Mission-critical systems that cannot afford extended downtime
• Large monoliths with complex business logic that's difficult to replicate
• Applications with tight coupling between components
• Systems where a complete rewrite would take 12+ months
• Legacy codebases with limited documentation or institutional knowledge

Consider alternatives when:

• The legacy system is small enough to rewrite in 3-6 months
• You have comprehensive test coverage and clear requirements
• The existing architecture is fundamentally sound
• Budget constraints make gradual migration uneconomical

Strangler Fig vs Other Modernisation Approaches

Approach	Timeline	Risk	Cost	Best For
Strangler Fig	6-18 months	Low	Medium-High	Critical systems, complex domains
Big Bang Rewrite	12-36 months	High	High	Well-documented systems, greenfield
Branch by Abstraction	3-12 months	Medium	Medium	Single responsibility refactoring
Database-First Migration	6-24 months	Medium	High	Data-heavy applications

The Strangler Fig pattern reduces risk by maintaining system availability throughout migration. While it requires more coordination overhead, it delivers value incrementally and provides fallback options if new components fail.

Step-by-Step Implementation Guide

Phase 1: Assessment and Planning (Weeks 1-4)

Before implementing the Strangler Fig pattern, conduct a thorough assessment of your legacy system. Map business capabilities, identify integration points, and understand data flows.

Key activities:

1. Audit existing functionality — Document all features, APIs, and dependencies
2. Identify strangling candidates — Look for loosely coupled modules with clear boundaries
3. Map data dependencies — Understand how data flows between components
4. Assess technical constraints — Evaluate infrastructure, security, and compliance requirements

Deliverable: A migration roadmap prioritising high-value, low-risk components for early strangling.

Phase 2: Infrastructure Setup (Weeks 5-8)

Set up the routing infrastructure that will direct traffic between legacy and new components. This typically involves an API gateway or reverse proxy.

Implementation steps:

1. Deploy an API gateway (Kong, AWS API Gateway, or Azure APIM)
2. Configure routing rules to initially send 100% traffic to legacy system
3. Implement feature flags for gradual traffic shifting
4. Set up monitoring to track request flows and performance
5. Establish CI/CD pipelines for new services

Technical considerations:

• Ensure the gateway can handle your peak traffic load
• Plan for session management across old and new components
• Consider SSL termination and security policies

Phase 3: First Strangler Implementation (Weeks 9-16)

Select your first component to strangle — ideally something with clear inputs/outputs and minimal dependencies. Authentication services, reporting modules, or user management are common starting points.

Implementation workflow:

1. Build the new service using modern technology stack
2. Implement comprehensive testing including integration tests
3. Deploy alongside legacy system without routing traffic
4. Configure parallel execution to compare outputs
5. Gradually shift traffic using canary deployments (5% → 25% → 50% → 100%)
6. Monitor performance and errors at each traffic level
7. Remove legacy code paths once new service is stable

Risk mitigation:

• Keep rollback procedures ready at each traffic shift
• Log all requests for comparison and debugging
• Run both systems in parallel during initial phases

Phase 4: Iterative Strangling (Weeks 17+)

Repeat the strangling process for subsequent components, building on lessons learned from the first implementation.

Prioritisation strategy:

1. High business value, low technical risk — Customer-facing features with clear requirements
2. Supporting services — Components that enable other stranglings
3. Complex core logic — Save the most challenging components for last

Coordination considerations:

• Maintain data consistency across legacy and new systems
• Handle distributed transactions carefully
• Plan for gradual database migration

Data Management Strategies

Data management often presents the biggest challenge in Strangler Fig implementations. Legacy monoliths typically use shared databases, creating tight coupling that complicates migration.

Database Strangling Approaches

1. Database-per-Service Pattern Create separate databases for new services while maintaining read access to legacy data.

2. Event Sourcing Publish domain events from legacy systems to keep new services synchronized.

3. Change Data Capture (CDC) Use tools like Debezium to stream database changes to new services in real-time.

4. API-First Data Access Route all data access through APIs, allowing gradual migration of data storage.

Handling Distributed Transactions

When business operations span legacy and new systems, implement eventual consistency patterns:

• Saga pattern for complex workflows
• Compensating transactions for rollback scenarios
• Event-driven architecture for loose coupling
• Two-phase commit only when absolutely necessary

Real-World Migration Timelines

Based on our experience with Australian mid-market companies, here are typical Strangler Fig migration timelines:

Small monolith (5-10 services): 6-12 months

• Planning: 4-6 weeks
• Infrastructure: 3-4 weeks
• First strangler: 6-8 weeks
• Subsequent services: 3-4 weeks each

Medium monolith (10-25 services): 12-18 months

• Planning: 6-8 weeks
• Infrastructure: 4-6 weeks
• First strangler: 8-10 weeks
• Core services: 4-6 weeks each
• Data migration: 6-12 weeks

Large monolith (25+ services): 18-36 months

• Planning: 8-12 weeks
• Infrastructure: 6-8 weeks
• First strangler: 10-12 weeks
• Complex services: 6-12 weeks each
• Data migration: 12-24 weeks

These timelines assume:

• Dedicated team of 3-5 developers
• Clear business requirements
• Existing CI/CD infrastructure
• Management support for gradual approach

Risk Mitigation and Monitoring

The Strangler Fig pattern reduces migration risk, but requires careful monitoring and rollback procedures.

Essential Monitoring Metrics

Performance indicators:

• Response time comparison (legacy vs new)
• Error rates and types
• Throughput and concurrency
• Memory and CPU utilisation

Business metrics:

• User experience indicators
• Transaction success rates
• Data consistency checks
• Feature adoption rates

Operational metrics:

• Deployment frequency
• Mean time to recovery
• Change failure rate
• Lead time for features

Rollback Procedures

Maintain multiple rollback options at each migration phase:

1. Traffic rollback — Instantly redirect traffic back to legacy
2. Feature flag rollback — Disable new features without deployment
3. Database rollback — Revert data changes using transaction logs
4. Full system rollback — Return to previous stable state

Common Pitfalls and How to Avoid Them

1. Insufficient planning Problem: Starting strangling without understanding system dependencies Solution: Invest 4-8 weeks in thorough system analysis and mapping

2. Data inconsistency Problem: Legacy and new systems showing different data Solution: Implement event sourcing and eventual consistency patterns

3. Performance degradation Problem: Additional network hops slow down system Solution: Optimise routing, implement caching, monitor response times

4. Scope creep Problem: Adding new features during migration Solution: Strict change control, separate enhancement from migration work

5. Incomplete strangling Problem: Leaving legacy components running indefinitely Solution: Set concrete deadlines for legacy code removal

When the Strangler Fig Pattern Makes Sense

The Strangler Fig pattern works best for Australian mid-market companies facing these scenarios:

• ASX-listed companies needing to maintain system availability during modernisation
• Financial services with strict regulatory requirements (APRA CPS 234)
• Healthcare systems handling patient data under Privacy Act 1988
• Government agencies with complex procurement and change management processes

However, this pattern requires discipline and long-term commitment. Teams must resist the temptation to rush or take shortcuts, as these lead to technical debt in both legacy and new systems.

This incremental approach aligns with our application modernisation methodology, where we help organisations migrate legacy systems without business disruption. For organisations planning broader digital transformation, our CTO advisory services provide strategic guidance on modernisation roadmaps and technology decisions.

Getting Started with Your Strangler Fig Migration

If you're considering the Strangler Fig pattern for your legacy modernisation:

1. Assess your current system — Map dependencies and identify candidates for strangling
2. Build a migration roadmap — Prioritise components by value and risk
3. Establish monitoring infrastructure — Set up observability before you start
4. Start small — Choose a simple, low-risk component for your first strangling
5. Plan for the long term — Ensure management commitment to gradual approach

The Strangler Fig pattern isn't the fastest modernisation approach, but it's often the safest for mission-critical systems. By gradually replacing legacy components with modern alternatives, you can modernise complex monoliths without the risks of big-bang rewrites.

---

Ready to modernise your legacy applications without the risks of a complete rewrite? Our team has guided organisations through successful Strangler Fig migrations across various industries. Contact us to discuss how we can help you plan and execute a gradual modernisation strategy that delivers value at every stage.