Strangler Fig pattern
E684901
The Strangler Fig pattern is a software design and migration approach that incrementally replaces legacy systems by building new functionality around them until the old system can be safely retired.
Statements (51)
| Predicate | Object |
|---|---|
| instanceOf |
application migration pattern
ⓘ
incremental modernization approach ⓘ software design pattern ⓘ |
| appliesTo |
API modernization
ⓘ
enterprise legacy systems ⓘ monolithic applications ⓘ on‑premise to cloud migrations ⓘ |
| benefit |
allows partial rollback if issues occur
ⓘ
enables phased rollout of new features ⓘ limits blast radius of changes ⓘ reduces need for full understanding of entire legacy system at once ⓘ spreads migration cost over time ⓘ supports parallel development of new system ⓘ |
| challenge |
can increase temporary system complexity
ⓘ
demands strong observability and testing ⓘ needs clear decomposition of legacy functionality ⓘ requires careful routing and integration design ⓘ |
| hasAlternativeName |
Strangler Fig application pattern
NERFINISHED
ⓘ
Strangler pattern ⓘ |
| hasGoal |
avoid big‑bang system replacement
ⓘ
enable continuous delivery during migration ⓘ minimize downtime during migration ⓘ reduce migration risk ⓘ replace legacy functionality with new implementation incrementally ⓘ |
| inspiredBy | strangler fig tree growth in nature ⓘ |
| keyIdea |
build new functionality around the existing system
ⓘ
coexistence of old and new systems during transition ⓘ retire legacy components once fully replaced ⓘ route traffic gradually from legacy to new components ⓘ |
| relatedTo |
anti‑corruption layer pattern
ⓘ
blue‑green deployment ⓘ branch by abstraction technique ⓘ canary release ⓘ facade pattern ⓘ microservices architecture ⓘ |
| typicallyInvolves |
eventual shutdown of legacy components
ⓘ
facade or routing layer in front of legacy system ⓘ incremental extraction of features from legacy system ⓘ monitoring and rollback mechanisms ⓘ progressive redirection of requests ⓘ |
| typicalStep |
decommission legacy endpoints once fully replaced
ⓘ
gradually reroute specific requests to new components ⓘ implement new functionality behind the facade ⓘ place a proxy or facade in front of the legacy system ⓘ remove the facade when legacy is fully retired ⓘ |
| usedFor |
application modernization
ⓘ
brownfield application development ⓘ gradual monolith to microservices migration ⓘ incremental system migration ⓘ legacy system replacement ⓘ risk‑reduced legacy decommissioning ⓘ |
Referenced by (1)
Full triples — surface form annotated when it differs from this entity's canonical label.