The Strangler Fig pattern modernises a legacy system by progressively moving bounded capabilities to replacement applications or services. A façade or other interception mechanism directs each request or event to the appropriate implementation while the old and new systems co-exist.
Described by Martin Fowler and Microsoft as a form of controlled, incremental modernisation, the pattern reduces the risk of a single high-impact cutover by replacing one capability at a time. It does not eliminate delivery risk, however. Teams must still manage data ownership, dependencies, operational continuity, testing and the eventual retirement of the legacy estate.
Its value depends on more than incremental delivery. Successful implementations require clear architectural boundaries, disciplined governance and a defined route to retiring the legacy estate.
What is the Strangler Fig pattern?
Fowler introduced the metaphor in 2004 – a new application grows around the existing system, progressively assumes its responsibilities and ultimately allows the legacy application to be retired.
A common implementation uses a façade or proxy:
Requests pass through a façade or other interception layer before being routed to either the legacy or replacement capability.
Microsoft’s reference architecture shows the façade initially routing most requests to the legacy application before progressively directing traffic to replacement services as they are introduced. Once dependencies have been transferred, the legacy capability and often the façade itself, can be removed.
The Strangler Fig pattern is not simply an API wrapper, a cloud migration or a Minimum Viable Replacement (MVR). Those approaches may form part of a modernisation programme, but the Strangler Fig pattern provides a defined execution approach for progressively replacing legacy functionality until the original system can be retired.
AWS commonly illustrates the pattern through monolith-to-microservices migration, but Fowler and Microsoft define it more broadly. The replacement may be microservices, modular applications or other architectures that suit the business and operating model. Microservices are a common destination, not a requirement.
Before selecting the pattern, first decide whether the system should be modernised, replaced, re-platformed or retired. That is a strategic decision. The Strangler Fig pattern determines how incremental modernisation is executed once that decision has been made.
How the Strangler Fig pattern works
The Strangler Fig pattern is an iterative approach to incremental modernisation. Rather than replacing an entire system at once, it progressively transfers responsibility from the legacy application to a new implementation, validating each step before moving to the next. A credible implementation follows a complete displacement lifecycle:
- Map the system, data, users and dependencies
- Identify where requests, events or data access can be intercepted
- Select a bounded capability to migrate
- Introduce a façade, gateway or other switching point
- Build and validate the replacement implementation
- Shift traffic or operational responsibility progressively
- Reconcile behaviour and data
- Retire the displaced legacy responsibility
- Repeat until the remaining system can be decommissioned
Microsoft’s phased architecture and Fowler and Thoughtworks’ displacement patterns follow this same lifecycle, progressively reducing reliance on the legacy system while building confidence in the replacement.
Fowler and Thoughtworks identify potential seams in APIs, messaging, database connections, triggers, batch jobs and change data capture. Choose the point where responsibility can be redirected, measured and managed safely without creating uncontrolled coupling between the old and new environments.
Fowler and Thoughtworks describe the façade, adapters and synchronisation mechanisms used during migration as transitional architecture. Microsoft highlights the trade-off – without a defined exit strategy, wrappers, synchronisation jobs and compatibility layers can become a new generation of technical debt rather than temporary migration components.
For related guidance on estate discovery, dependency analysis and target-state planning, see Catapult CX’s cloud migration assessment.
When should you use the Strangler Fig pattern?
The Strangler Fig pattern is most effective where a system is too complex or business-critical for a single cutover but can remain operational while responsibilities move incrementally. It is designed to reduce delivery risk by replacing one bounded capability at a time rather than committing the organisation to a high-impact migration event. Microsoft recommends the approach for large systems, key components and complex features where direct replacement would create significant operational risk.
| Good fit | Poor fit |
| Large, complex or business-critical system | Small system that can be replaced directly |
| Full cutover creates unacceptable disruption risk | Original platform must be retired urgently |
| Requests, events or responsibilities can be intercepted | No viable routing, event or integration seam exists |
| Capabilities can be separated meaningfully | Domain boundaries are deeply entangled |
| Parallel operation is manageable | Co-existence creates disproportionate risk or cost |
In Microsoft’s and AWS’s reference implementations, code access may be needed to disable migrated functions or redirect internal calls. Before ruling the pattern out, however, assess whether API gateways, messaging platforms, database events or other external integration points provide viable interception seams.
Determining whether those seams exist is one of the first architectural questions in any legacy modernisation programme. Catapult CX’s Modernisation Readiness Review assesses architecture constraints, dependency boundaries and delivery risks to establish whether controlled incremental modernisation is viable and what should be reused, replaced or retired before a migration approach is selected.
How to choose the first capability to migrate
Choosing the first capability is one of the most important decisions in a Strangler Fig programme. The objective is not simply to deliver the first release quickly, but to prove that the modernisation approach is technically, operationally and commercially viable before larger parts of the estate are displaced.
The easiest component is not automatically the best first slice. A trivial function may demonstrate that the team can deploy code, yet reveal little about the integration, data, operational or governance challenges that determine whether the wider programme will succeed.
Thoughtworks recommends balancing complexity and business value. AWS also identifies test coverage, distinctive scaling requirements and areas of frequent business change as useful selection criteria.
Assess each candidate against:
| Criterion | Question |
| Value | Will migration produce a visible operational or customer benefit? |
| Criticality | What is the impact if it fails? |
| Dependencies | How many systems and teams rely on it? |
| Data | Can its records and ownership be separated? |
| Testability | Can existing behaviour be verified? |
| Observability | Can old and new paths be measured independently? |
| Recovery | Can service continuity and data integrity be maintained if migration pauses or issues emerge? |
| Learning | Will it test assumptions relevant to later slices? |
The best first slice is rarely the simplest. It is a bounded capability that generates meaningful technical, operational and commercial evidence without exposing the programme to its highest delivery risk on the first release. A successful first migration should increase confidence in the overall modernisation approach, not simply demonstrate that code can be deployed.
Where important assumptions remain uncertain, a bounded proof of concept or Minimum Viable Replacement (MVR) can validate integration, data access and operational feasibility before live responsibility moves. Catapult CX uses targeted PoCs to test the highest-risk assumptions before organisations commit to larger delivery programmes.
An MVR is a validation approach, not another name for the first Strangler Fig slice. A successful MVR may inform the first migration, but it does not replace the structured, incremental displacement that defines the Strangler Fig pattern.
Façades, anti-corruption layers and system seams
Successful Strangler Fig implementations depend on more than identifying what to migrate. They also depend on choosing how the legacy and replacement systems interact while they co-exist. Façades, anti-corruption layers and other transitional components help separate responsibilities without forcing the new implementation to inherit the constraints of the old one.
Microsoft distinguishes a façade, which routes requests, from an anti-corruption layer, which translates interfaces or domain models so the replacement does not inherit legacy conventions. They are complementary patterns and are often used together.
| Component | Purpose | Primary risk |
| Façade or proxy | Routes requests or traffic | Becomes a bottleneck, single point of failure or permanent dependency |
| Anti-corruption layer | Translates interfaces and domain models | Legacy semantics leak into the new design |
| Event interceptor | Diverts or duplicates state changes | Duplicate processing or event-ordering failures |
| Legacy adapter | Preserves an existing interface temporarily | Compatibility layer becomes permanent technical debt |
Potential seams include APIs, messaging platforms, database access, batch jobs, user journeys and business capabilities. The objective is not simply to find the easiest place to install a proxy, but to identify where responsibility can be transferred, measured and ultimately removed with minimal coupling between the legacy and replacement environments.
The façade itself must be treated as production infrastructure. Microsoft and AWS both warn that, if poorly designed, it can become a bottleneck or single point of failure. Like the other elements of transitional architecture, it should exist only for as long as it is needed to support controlled migration.
Managing data while old and new systems co-exist
Moving application logic is often simpler than moving the data behind it. In most Strangler Fig programmes, code and data transition at different speeds, making data ownership one of the most significant architectural and operational challenges.
Every extracted capability therefore requires explicit decisions about the current system of record, write ownership, historical migration, ongoing synchronisation, reconciliation and the point at which the replacement system becomes authoritative.
Microsoft’s reference architecture introduces the replacement service first, migrates historical records through ETL, synchronises ongoing changes using Change Data Capture (CDC) and validates consistency before transferring system-of-record responsibility to the new database.
| Approach | Main use | Main trade-off |
| ETL | Move historical records | Needs a plan for changes after extraction |
| Change data capture | Synchronise ongoing legacy changes | Adds ordering and operational complexity |
| Event replication | Feed business changes to the replacement | Depends on complete, re-playable events |
| Dual writes | Keep two stores current | Partial failure can create divergence |
| Shared database | Move code before data | Preserves coupling |
| Reverse synchronisation | Support controlled recovery | Extends duplicated data paths |
Microsoft notes that a shared schema preserves coupling because every structural change must be coordinated across dependent services. Separate data stores reduce that dependency but introduce challenges around data integrity, reconciliation and eventual consistency.
Rollback also becomes progressively more complex as migration advances. Microsoft notes that routing traffic back remains relatively straightforward while legacy tables and synchronisation processes still exist. Once those have been removed, recovery requires historical data to be restored and subsequent business transactions to be reconciled and replayed. AWS similarly distinguishes between routing traffic back to a previous implementation and reversing business transactions that have already been committed.
For complex legacy modernisation programmes, source-to-target mapping, reconciliation and data ownership are architectural decisions that should be designed from the outset rather than deferred until cutover. Data migration is rarely a deployment activity; it is a core part of the modernisation architecture. It also creates the opportunity to improve how organisational data is structured, governed and managed, providing a stronger foundation for analytics, AI and data management aligned with FAIR principles by making information more Findable, Accessible, Interoperable and Reusable.
Testing, traffic shifting and recovery
The safe unit of progress is not code completed. It is a capability that has produced enough evidence to assume live responsibility with confidence.
Start by documenting the legacy behaviour that genuinely matters. Thoughtworks recommends creating a temporary black-box or parity test suite that can be applied to both the legacy and replacement implementations.
This does not mean reproducing every obsolete feature or historical defect. It means preserving the behaviours that users, downstream systems and operational controls still depend on.
Progressive exposure techniques include:
- Dark launching or shadow traffic
- Feature flags
- Canary releases
- Parallel running
- User-group or transaction-based routing
Thoughtworks recommends feature flags, canary releases and dark launches. The UK Government Digital Service (GDS) also recommends dark launching, where responses from the new implementation can be discarded, compared with legacy results or used for performance and resilience testing before assuming live responsibility.
Monitor both technical and business outcomes, including availability, latency, errors, data consistency, transaction completion, control failures and divergence between implementations. A service that remains available but produces different business outcomes has not successfully completed migration.
Recovery planning should also be considered from several perspectives:
| Area | Key question |
| Traffic | Can requests be redirected safely if issues emerge? |
| Application | Can the previous implementation continue supporting the service while defects are resolved? |
| Data | How will data consistency and write ownership be maintained if migration is paused? |
| Operations | Can support, monitoring and operational processes continue without service disruption? |
AWS recommends phased traffic movement and controlled recovery options where appropriate. Once new business transactions have been committed, however, redirecting requests is not the same as reversing business data. Recovery therefore becomes an operational and architectural consideration rather than simply a technical routing decision.
The Strangler Fig pattern supports controlled, low-disruption migration by validating each capability before responsibility moves. It does not remove delivery risk, but it allows that risk to be managed progressively rather than concentrated into a single cutover.
Applying the pattern in FCA and GDS environments
The FCA, PRA and GDS do not prescribe the Strangler Fig pattern or any other migration architecture. Instead, they define the resilience, governance and service outcomes that any modernisation approach must achieve. The architecture is a delivery choice; the regulatory obligations remain the same.
FCA operational resilience rules required in-scope firms to complete mapping and scenario testing by 31 March 2025 so important business services could remain within defined impact tolerances. PRA SS1/21 similarly requires relevant firms to identify important business services, set impact tolerances and demonstrate operational resilience.
For a migration affecting an important business service, delivery teams should be able to produce evidence such as:
| Concern | Evidence to establish |
| Scope | Which important business service and customer outcome does the change support? |
| Dependencies | Which people, processes, technology, information and third parties are involved? |
| Traffic shift | What volume can move without creating intolerable harm if the new implementation experiences issues? |
| Testing | Which severe but plausible disruption scenarios have been exercised? |
| Recovery | Are traffic, data and operational recovery procedures tested? |
| Governance | Are vulnerabilities, decisions and remediation owners visible to accountable leaders? |
This is a practical application of the regulatory requirements, not a regulator-prescribed Strangler Fig framework.
The FCA’s March 2026 observations reinforce that resilience extends beyond technology. Firms should map the people, processes, facilities, information and third parties that support each important business service and scenario testing should generate sufficient evidence for boards to challenge resilience decisions with confidence.
In regulated environments, co-existence introduces additional operational complexity. During migration, organisations must govern duplicate access controls, monitoring, incident management, suppliers, data ownership and operational responsibilities until the legacy environment can be retired.
GDS identifies the Strangler Fig pattern as a common approach to replacing legacy systems, highlighting techniques such as API wrappers, temporary compatibility code and dark launches. The Service Standard also emphasises iterative delivery, live-like testing, continuous monitoring and regular deployment without significant service disruption.
Where Strangler Fig migrations fail
The Strangler Fig pattern reduces the risk of a single large-scale migration, but it does not guarantee a successful outcome. Many programmes fail because temporary migration measures become permanent architecture, legacy responsibilities are never fully retired or incremental releases are managed as isolated projects rather than stages of a single modernisation programme.
| Failure mode | Consequence | Control |
| Wrong capability boundary | Replacement remains coupled to the monolith | Validate domain and dependency boundaries |
| Permanent façade | Routing layer becomes new legacy | Set an owner and removal condition |
| Permanent dual running | Cost and risk remain duplicated | Set retirement dates and exit criteria |
| Blind feature parity | Obsolete processes move into the replacement | Separate compatibility from current value |
| Shared database remains | New services cannot evolve independently | Define data-ownership transition |
| Data divergence | Neither system is trusted | Automate reconciliation and exceptions |
| Weak observability | Users detect failures first | Compare old and new business outcomes |
| Untested recovery procedures | Recovery fails under pressure | Exercise traffic, data and operations |
| Too many slices in flight | Transitional complexity becomes unmanageable | Limit concurrent change |
| No retirement owner | Old assets remain indefinitely | Make decommissioning a governed deliverable |
Transitional architecture is intended to be temporary. Microsoft notes that its risk-reduction benefits must be balanced against the additional infrastructure and operational overhead it introduces. Fowler likewise describe transitional components as software created to support displacement and removed once that purpose has been fulfilled.
GDS also recommends agreeing retirement dates as part of the migration plan. Without defined exit criteria, organisations can defer the final transition, extend legacy support contracts and increase both architectural and operational complexity.
A migrated capability is not complete simply because it has been released into production. It is complete when behaviour has been validated, data ownership is established, operational responsibility has transferred, downstream consumers have moved, recovery arrangements have been exercised and the associated legacy code, infrastructure, data objects and support processes can be retired.
Decommissioning is not a post-project clean-up activity. It is the final stage of the Strangler Fig pattern and the point at which the benefits of incremental modernisation are fully realised.
What controlled incremental modernisation looks like in practice
Catapult CX’s work with the Maritime and Coastguard Agency (MCA) demonstrates the principles of controlled incremental modernisation in practice. The published case studies describe cloud-native delivery, progressive data migration and successive service releases. While they are not presented as canonical Strangler Fig implementations, they illustrate many of the architectural and delivery practices that underpin incremental legacy modernisation.
For the UK Ship Register modernisation, Catapult CX replaced a fragmented, manual service following an earlier unsuccessful data migration programme. The published case describes a cloud-native microservices platform, automated ETL migration, DevSecOps, continuous delivery and Alpha and public Beta assessments.
The UK Ship Register case study reports:
- 89% reduction in data and certification errors
- 625% increase in monthly transactions
- 45% reduction in cost per transaction
- Registration processing reduced from more than 60 minutes to between 8 and 17 minutes
The wider MCA cloud platform also demonstrates the value of delivering change in bounded increments. The Small Ships Register was delivered in nine weeks, followed by the UK Ship Register and the Seafarer Maritime Applications, Registration and Training (SMART) service over subsequent phases, supported by built-in observability, secure CI/CD and multiple deployments each day.
Together, these case studies demonstrate how incremental delivery, reusable platform capability, deliberate data migration and progressive validation can reduce delivery risk while enabling continuous service improvement. They should not, however, be described as direct Strangler Fig implementations unless internal evidence confirms capability-level interception, parallel operation, progressive traffic routing and staged retirement of legacy functionality.
How to decide your next step
Do not start by selecting a façade, proxy or migration technology. First determine whether your legacy estate is capable of supporting controlled incremental modernisation.
Before committing to a delivery approach, establish:
- Which business capability is creating the greatest operational or commercial constraint.
- Whether a viable interception seam exists.
- How the legacy and replacement implementations will coexist.
- How data ownership and system-of-record responsibility will transfer.
- What evidence is required before live responsibility moves.
- How service continuity and operational recovery will be managed throughout the migration.
- Who owns legacy retirement and how success will be measured.
Where those answers remain unclear, Catapult CX’s Modernisation Readiness Review identifies architectural constraints, dependency boundaries and delivery risks to determine what should be reused, replaced or retired before significant delivery investment is committed.
Where the delivery approach is understood, Catapult CX’s legacy modernisation services include targeted proofs of concept, Minimum Viable Replacements (MVRs) and selective component replacement to validate the highest-risk assumptions before wider implementation.
The objective is not to approve a multi-year transformation programme on day one. It is to identify a bounded capability, validate the highest-risk assumptions and establish a credible path from coexistence to legacy retirement. Once that route has been proven, the programme can expand with significantly greater confidence.
Frequently asked questions about the Strangler Fig pattern
What is the Strangler Fig pattern in legacy modernisation?
The Strangler Fig pattern is an incremental legacy modernisation approach that progressively replaces capabilities within an existing system while a façade or other interception mechanism routes requests between the legacy and replacement implementations. The objective is to retire the legacy system over time rather than replace it through a single high-risk cutover.
When should you use the Strangler Fig pattern?
The pattern is most appropriate where a system is large, business-critical or too complex for a single cutover. It works best when capabilities can be separated into meaningful business domains, responsibilities can be intercepted and the legacy and replacement systems can operate alongside one another during migration.
When should you not use the Strangler Fig pattern?
It may be unsuitable where the application is small, must be retired quickly, has no viable interception seams or cannot be meaningfully separated into independent capabilities. In these situations, direct replacement or another modernisation approach may be more appropriate.
Is the Strangler Fig pattern the same as legacy modernisation?
No. Legacy modernisation is the overall strategy for improving or replacing ageing systems. The Strangler Fig pattern is one execution approach for delivering that strategy through controlled, incremental migration.
Does the Strangler Fig pattern require microservices?
No. Although it is commonly associated with monolith-to-microservices migration, the pattern does not require a specific target architecture. Replacement capabilities may be implemented as modular applications, services or APIs that best suit the business and operating model.
Can the Strangler Fig pattern eliminate downtime?
It can significantly reduce disruption by introducing smaller releases, phased traffic movement and progressive validation, but it cannot guarantee zero downtime. Data migration, tightly coupled dependencies and operational constraints may still require carefully planned service transitions.
How is data migrated during a Strangler Fig implementation?
Data migration typically combines techniques such as ETL, Change Data Capture (CDC), event replication and reconciliation before system-of-record responsibility transfers to the replacement application. The appropriate approach depends on the application’s architecture, data model and operational requirements.
What are the disadvantages of the Strangler Fig pattern?
The pattern introduces temporary architecture, duplicated operations and additional governance during migration. Without clear ownership and retirement criteria, façades, adapters and synchronisation processes can become permanent technical debt rather than temporary migration components.
When can a legacy component be decommissioned?
A legacy capability can be retired when the replacement has been validated, data ownership has transferred, downstream dependencies have moved, operational responsibilities have been established and the legacy code, infrastructure and support processes are no longer required.
How long does a Strangler Fig migration take?
There is no fixed timeframe. The duration depends on the size of the legacy estate, the complexity of its dependencies, the number of capabilities being replaced and the organisation’s delivery capacity. Most programmes are delivered as a series of incremental releases rather than a single migration project.
How do you know whether the Strangler Fig pattern is the right approach?
The first step is to assess whether the legacy estate has clear capability boundaries, viable interception seams and an operating model that supports incremental migration. If those conditions are not present, another modernisation approach may be more appropriate.
