Pattern Name: Strangler Fig Migration Category: Migration Architecture / Legacy Modernisation Complexity: Medium to High Stability: High: widely proven in large-scale legacy modernisation programs
Legacy systems are rarely replaced in a single cutover. They accumulate decades of business logic, data, and integrations; their full scope is often poorly documented; and their failure risk is high enough that organizations cannot afford to “big bang” a replacement. Yet the cost of maintaining them: in licensing, skilled personnel, technical debt, and lost agility: is significant and growing.
The pattern is named after the strangler fig, a plant that grows around an existing tree, gradually replacing it over years until the original host is gone.
How do you replace a large, complex legacy system with a modern alternative without a high-risk “big bang” cutover, without running two parallel systems indefinitely, and without disrupting live operations?
The fundamental tension in legacy migration is between risk and speed. A complete, parallel-build replacement minimises operational disruption but maximises build risk and requires maintaining two systems for an extended period. Incremental replacement reduces build risk but creates complexity at the boundary between old and new, and risks the migration stalling partway through if organisational will fades.
Incrementally build new functionality alongside the legacy system, routing traffic to the new system for completed capabilities and to the legacy system for capabilities not yet migrated. Over time, the new system grows to cover all capabilities and the legacy system is decommissioned.
The pattern operates in three phases:
Phase 1: Intercept: Introduce a routing layer (typically a facade, API gateway, or adapter) in front of the legacy system. All traffic flows through this layer. Initially, the layer passes everything to the legacy system. The key is that consumers now communicate with the facade, not directly with the legacy system.
Phase 2: Migrate: Build new capabilities in the target system. As each capability is completed, update the routing layer to direct relevant traffic to the new system. The legacy system continues to handle unmigrated capabilities. Data synchronisation between old and new systems is the primary technical challenge during this phase.
Phase 3: Extinguish: Once all capabilities have been migrated and validated, decommission the legacy system and remove the routing layer (or promote it to a permanent API gateway).
The pace of migration can be varied: capabilities can be migrated in any order, and the program can be paused and resumed. This flexibility is the strangler fig’s greatest advantage.
Element types to use:
Diagram types: ArchiMate Application Architecture diagram showing the three-system topology (legacy, facade, new); roadmap diagram showing migration sequence; data flow diagrams for synchronisation patterns
MDG considerations: Create a «MigrationState» tagged value set on Application Component and Application Function elements: {Legacy | Facade | Target | Decommissioned}. Add a «MigrationPhase» tagged value with quarter/year of planned migration. These tags make portfolio-level migration status reporting straightforward and enable model-driven roadmaps.
Package structure: Maintain a Migration Architecture package with sub-packages for Legacy Inventory, Target Architecture, and Transition Architecture. The Transition Architecture package captures the intermediate states: the configurations at each phase of migration that are technically transient but architecturally important to document.
EA GraphLink and AI integration: Migration programs generate governance questions that AI can answer quickly from the model: “Which legacy capabilities are still unmigrated?”, “What applications depend on the facade?”, “How many capabilities are currently In Migration?”. With EA GraphLink and Kernaro, program managers can query migration status directly without requesting reports from the EA team. This reduces the EA team’s reporting burden while improving stakeholder visibility. AI tools can also flag migration risks: for example, identifying dependencies on legacy capabilities that have not been scheduled for migration.
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.