Architecture Pattern - Strangler Fig Migration¶

Overview¶

The Strangler Fig pattern incrementally migrates a legacy monolithic application to a modern architecture by gradually replacing specific functionality with new services. Named after the strangler fig tree that grows around a host tree and eventually replaces it, this pattern minimizes risk by avoiding "big bang" rewrites.

Pattern Description¶

Problem¶

• Legacy monolithic application is difficult to maintain, scale, and evolve
• A complete rewrite is too risky, expensive, and time-consuming
• Business cannot afford extended downtime during migration
• The legacy system must continue operating while migration proceeds
• Team needs to deliver new features during the migration period

Solution¶

Incrementally replace parts of the legacy system with new services: 1. Place a facade (proxy/gateway) in front of the legacy application 2. Identify bounded contexts or modules to extract 3. Build new services for extracted functionality 4. Route traffic to new services via the facade 5. Decommission legacy components as they are replaced 6. Continue until the legacy system is fully replaced or sufficiently modernized

flowchart LR
  C[Clients] --> F[Strangler facade<br/>routing rules]
  F -- /orders/* --> NEW1[New: orders service]
  F -- /users/* --> NEW2[New: users service]
  F -- "everything else (legacy paths)" --> MONO[Legacy monolith<br/>shrinks over time]
  NEW1 --> DB1[(Orders DB)]
  NEW2 --> DB2[(Users DB)]
  MONO --> DBL[(Legacy DB)]
  NEW1 -. backfill / sync .-> DBL
  NEW2 -. backfill / sync .-> DBL

When to Use¶

• Migrating monoliths to microservices
• Moving from on-premises to cloud
• Replacing legacy platforms with modern technology
• When business continuity is required during migration
• When the legacy system has clear functional boundaries

When to Avoid¶

• The legacy system is too small to justify the migration overhead
• The legacy system cannot be intercepted by a proxy/facade
• Complete data model changes are required simultaneously
• When the legacy codebase is well-maintained and meeting requirements

Migration Phases¶

Phase 1 - Assess and Plan¶

Phase 2 - Set Up the Facade¶

Phase 3 - Extract and Replace¶

Phase 3a: Extract one module
┌──────────┐     ┌──────────────┐     ┌──────────────┐
│  Client   │────>│   Facade     │────>│   Legacy     │
│           │     │  (Gateway)   │     │   Monolith   │
└──────────┘     │              │     │              │
                 │  /orders ────│────>│  Orders      │
                 │  /users  ────│────>│  Users       │
                 │  /products ──│────>│  Products    │
                 └──────────────┘     └──────────────┘

Phase 3b: Replace orders module
┌──────────┐     ┌──────────────┐     ┌──────────────┐
│  Client   │────>│   Facade     │     │   Legacy     │
│           │     │  (Gateway)   │     │   Monolith   │
└──────────┘     │              │     │              │
                 │  /orders ────│──┐  │  [Orders]    │
                 │  /users  ────│──│─>│  Users       │
                 │  /products ──│──│─>│  Products    │
                 └──────────────┘  │  └──────────────┘
                                   │
                              ┌────▼─────┐
                              │  Orders   │
                              │  Service  │
                              │  (new)    │
                              └──────────┘

Phase 4 - Decommission¶

Cloud Implementation¶

AWS Implementation¶

AWS Migration Architecture:

Route 53 (weighted) -> CloudFront -> ALB
                                      |
                        ┌─────────────┼─────────────┐
                        │             │             │
                   ┌────▼────┐  ┌────▼────┐  ┌────▼────┐
                   │ New Svc  │  │ New Svc  │  │ Legacy  │
                   │ (ECS)    │  │ (Lambda) │  │ (EC2)   │
                   └────┬─────┘  └────┬─────┘  └────┬────┘
                        │             │             │
                   ┌────▼─────┐ ┌────▼─────┐ ┌────▼────┐
                   │ DynamoDB  │ │ Aurora   │ │ Legacy  │
                   └───────────┘ │ (new)    │ │ DB      │
                                 └──────────┘ └─────────┘
                                       ↑           │
                                       └───DMS─────┘

Azure Implementation¶

Google Cloud Implementation¶

Data Migration Strategies¶

Shared Database (Transitional)¶

During migration, both legacy and new services may need to access the same data.

Database Decomposition Patterns¶

Data Synchronization¶

Traffic Routing Strategies¶

Gradual Migration¶

Implementation Examples¶

Common Challenges and Solutions¶

Anti-Corruption Layer¶

An anti-corruption layer translates between the legacy and new system models, preventing legacy concepts from leaking into the new architecture.

┌─────────────┐     ┌────────────────────┐     ┌─────────────┐
│  New Service │────>│ Anti-Corruption     │────>│   Legacy    │
│  (clean      │     │ Layer               │     │   System    │
│   model)     │     │  - Model translation│     │  (legacy    │
│              │     │  - Protocol adapting │     │   model)    │
│              │     │  - Data mapping      │     │             │
└─────────────┘     └────────────────────┘     └─────────────┘

Migration Metrics and KPIs¶

Certification Exam Focus Areas¶

AWS¶

• ALB routing rules for traffic splitting
• DMS for database migration during strangler fig
• Route 53 weighted routing for gradual migration
• EventBridge for event-driven data sync
• CloudFormation/CDK for infrastructure automation

Azure¶

• Application Gateway and Front Door for traffic routing
• Azure Migrate for assessment and migration planning
• Data Factory for ETL during data decomposition
• APIM for facade/proxy layer
• App Configuration for feature flags

Google Cloud¶

• Cloud Load Balancing URL maps for path-based routing
• Database Migration Service for data migration
• Pub/Sub for event-driven architecture during migration
• Anthos for hybrid legacy-to-cloud scenarios
• Cloud Run for deploying extracted microservices

Documentation Links¶

• Strangler Fig Pattern (Microsoft): https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig
• AWS Migration Strategies: https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-retiring-applications/
• AWS Database Migration Service: https://docs.aws.amazon.com/dms/latest/userguide/
• Azure Migrate: https://learn.microsoft.com/en-us/azure/migrate/
• Google Cloud Migration Center: https://cloud.google.com/migration-center/docs

Key Takeaways¶

1. Start with the facade/proxy layer - it is the foundation of the entire migration
2. Extract modules with the highest business value or the most pain points first
3. Data migration is the hardest part - plan for it early and use CDC where possible
4. Always maintain rollback capability throughout the migration
5. The anti-corruption layer prevents legacy patterns from infecting the new system
6. Feature flags are essential for controlling traffic routing without deployments
7. Migration is a marathon, not a sprint - expect 12-24 months for a significant monolith
8. Measure and compare performance between legacy and new services continuously