Overview
Both are strategies for replacing a legacy system, but they differ in how risk and time are distributed. The Strangler Fig Pattern incrementally routes traffic from old to new components behind a facade until the legacy system is gone, while Big Bang Migration replaces the entire system in one coordinated cutover. The choice shapes how much downtime, rollback flexibility, and sustained engineering effort a team is willing to accept.
Comparison Diagram
Comparison Table
| Aspect | Strangler Fig Pattern | Big Bang Migration |
|---|---|---|
| Core approach | Incrementally replace pieces of the legacy system behind a facade until nothing legacy remains | Replace the entire legacy system with the new system in one coordinated cutover |
| Upfront design | Requires a routing/facade layer and clear service boundaries defined before starting | Requires the new system built to full feature parity before any cutover |
| Traffic routing | A facade or proxy intercepts requests and routes them to legacy or new components as they’re migrated | No intermediate routing layer; all traffic points to legacy until the single cutover moment |
| Execution timeline | Spans weeks to years, delivered as many small, independent releases | Concentrated into a single migration event, often a scheduled outage window |
| Rollback capability | Easy to roll back a single migrated component by routing traffic back to legacy | Rolling back means reverting the entire system, which is costly and often impractical |
| Risk exposure | Risk is distributed across many small, independently testable changes | Risk is concentrated in one high-stakes event where failure affects the whole system |
| Legacy decommissioning | Legacy system shrinks piece by piece until it can be retired entirely | Legacy system is decommissioned immediately once the new system goes live |
Key Differences
- Strangler Fig routes traffic through a facade, letting legacy and new code coexist; Big Bang has no such intermediary.
- Big Bang concentrates all risk into one cutover event, while Strangler Fig spreads it across many small releases.
- Strangler Fig supports granular rollback per component; Big Bang rollback requires reverting the whole system.
- Strangler Fig migrations run for months or years; Big Bang fits a fixed deadline.
- Strangler Fig requires maintaining dual systems temporarily; Big Bang avoids that overhead entirely.
When to Use Each
Strangler Fig Pattern
- Large, business-critical systems: Downtime or full-system risk is unacceptable, so replacing components incrementally keeps the system running throughout.
- Poorly understood legacy systems: Incremental replacement surfaces hidden behavior and dependencies as each piece is migrated, rather than assuming full understanding upfront.
- Long-lived migrations with limited staffing: Work can be spread across many small releases over an extended timeframe without needing a dedicated migration freeze.
Big Bang Migration
- Small, well-scoped systems: Full feature parity is achievable in a single build, making a facade and routing layer unnecessary overhead.
- Systems with a hard deadline: A vendor contract expiration or license end-of-life can force a one-time cutover on a fixed date.
- Short-lived or rarely used systems: Building a facade layer isn’t worth it when the system will only exist briefly or sees infrequent traffic.