Big bang migration is considered one of the biggest risks in IT projects. The proven alternative: the Strangler Fig Pattern. Instead of a hard system change, legacy software is gradually replaced by new services while operations continue. This guide analyzes how it works technically, compares approaches, and provides a concrete practical example.
-
The most important facts in brief
- What is the Strangler Fig Pattern? An incremental modernization strategy in which legacy software is gradually and modularly replaced by new microservices until the old system is completely replaced.
- How does the technical implementation work? An upstream proxy (routing switch) redirects requests piece by piece from the legacy system to new components, so that both systems run in parallel and fail-safe during migration.
- Why is it better than a big bang migration? The operational risk is massively reduced, as errors are limited to individual modules and the legacy system serves as a fallback at all times, instead of switching everything over in one fell swoop.
- When is it worth using? Especially for business-critical, complex monoliths that do not allow downtime, and when rapid time-to-value is more important than an immediate complete overhaul.
- What are the challenges? Parallel data storage between the old and new systems requires complex synchronization, and there is also a risk that the migration will be interrupted before the old system is finally shut down.
What is the Strangler Fig Pattern?
Modernising software is a demanding project that brings many challenges with it. In particular, abruptly switching from one system to another can lead to many problems.
The solution: Instead of replacing the entire system at once, the individual components are renewed step by step – using the Strangler Fig Pattern.
The Strangler Fig Pattern (also known as the Strangler Pattern) is an incremental method of software modernization in which an old system is gradually replaced by new microservices or modules until the old system is completely replaced. The key advantage is that the existing application remains fully functional throughout the process, while new features are added in a modular fashion.
The Strangler Fig Pattern, also known as the Strangler Pattern, was first described by Martin Fowler and is named after the Australian strangler fig. This plant grows around another tree and eventually replaces it completely.
The Strangler Fig Pattern works in a similar way in software modernisation: the old system remains in place while new functions are added step by step. Gradually, the new system takes over more and more tasks until it finally replaces the old one completely.
This gradual renewal ensures that the application remains functional at all times. There are no sudden outages or major surprises, which significantly minimises risk and ensures a smooth transition.
Big Bang migration vs. Strangler Fig Pattern
A direct comparison illustrates why the Strangler Fig Pattern is the superior alternative to risky big bang migration:
Feature
| Big bang migration
| Strangler fig pattern
|
|---|---|---|
Approach
| Immediate switchover (all at once)
| Gradual replacement (incremental)
|
Risk
| High (errors affect the entire system)
| Low (errors limited to components)
|
Parallel operation
| No (old off, new on)
| Yes (old and new run in parallel)
|
User experience
| Abrupt change (hard cut)
| Continuous, barely noticeable updates
|
Time-to-value
| Late (only after project completion)
| Early (after migration of first features)
|
Expert tip
The Strangler Fig Pattern can be used in web, desktop and mobile apps. It doesn't matter whether the application is written in Java, JavaScript, COBOL or VBA as part of an Excel sheet. The latter simply requires more creative solutions.
How does the Strangler Fig Pattern work?
As a reminder, the Strangler Fig Pattern is a proven method for software modernisation that aims to gradually replace old applications with new ones. But how exactly does the Strangler Fig Pattern work? Let's take a look at the process in detail.
- Set up initial switch (routing): At the beginning, an interception layer is placed in front of the existing system. For web applications, we usually use a reverse proxy or load balancer for this purpose. Desktop applications often require more customized wrapper solutions. Initially, this switch forwards 100% of requests to the legacy system (monolith).
- Develop new component in isolation: Instead of performing open-heart surgery on the system, a single functionality is developed and tested as a new, modern microservice or module.
- Switch the switch (incremental rollout): Once the new module is running stably, the proxy is configured. It now forwards specific requests (e.g., /api/new-function) to the new service. The remaining traffic continues to flow to the legacy system without interruption.
- Continuous repetition: This cycle is repeated for each additional function. In this way, the new architecture gradually "strangles" the old system without causing downtime for users.
- Decommissioning: Once the last function has been migrated and the monolith is no longer receiving any traffic, the legacy system is finally shut down.
What are the advantages of the Strangler Fig Pattern?
-
Risk minimization: The existing application remains fully functional throughout the migration, eliminating the risk of operational downtime.
-
Faster ROI (time-to-value): New features and enhancements are available to users immediately after the release of the respective microservices, not after project completion.
-
Flexibility & prioritization: Modernization proceeds at your own pace; business-critical functions can be prioritized.
-
Cost efficiency: Investment costs are not incurred at a single point in time (as with a big bang approach), but are spread over the duration of the project.
Challenges & Disadvantages
-
Complex data management: Parallel operation often requires complex, continuous synchronization of data between the old and new systems.
-
Discipline in completion: There is a risk that migration will be halted as soon as the most important features are up and running. This leads to permanent double maintenance costs if the old system is not completely shut down.
When is a strangler figure pattern the best option?
The decision to use the Strangler Fig Pattern depends primarily on how quickly a return on investment (ROI) is to be achieved and how complex the legacy system is.
Strategic influencing factors
Four key factors determine whether this method is suitable:
- Criticality: How critical is the component to the business, and how high is the risk in the event of a failure?
- Technical debt: Is the code so outdated that refactoring (transforming) would be uneconomical?
- Coupling: How strongly is the component intertwined with the rest of the monolith?
- Target vision: How clear is the technical understanding for the new architecture?
Ideal scenarios for use
The Strangler Fig Pattern is particularly effective in the following three cases:
- Outdated components: When parts of the software are so technologically obsolete or poorly written that complete replacement is more efficient than repair.
- Isolable functions: When a component can be easily separated from the rest of the system (loose coupling) without jeopardizing overall stability.
- Clearly defined features: When the exact specifications of the new function are known, it can be developed specifically alongside the legacy system.
The Strangler Fig Pattern is a method for replacing components at the system level. If you simply want to clean up existing code, refactoring approaches are often more effective.
Jochen Schweizer – a successful use case
One successful example of application is the relaunch of the Jochen Schweizer mydays Group (JSMDG). The challenge lay in consolidating the heterogeneous system landscapes after the merger of the two companies.
Solution: Using the Strangler Fig pattern, a centralized platform was built around the existing architecture. This new platform gradually replaced the legacy shops and backend systems without jeopardizing ongoing operations.
The Strangler Fig pattern enabled the following measurable results at JSMDG:
- Availability: 100% (zero downtime during migration)
- Performance: 37% reduction in loading times
- Business impact: Significantly higher conversion rate thanks to improved UX
Frequently asked questions about the Strangler Fig Pattern
How is the Strangler Fig Pattern technically implemented?
The technical implementation is primarily carried out by a reverse proxy or an API gateway (the "switch"). This upstream component intercepts all client requests and routes them either to the legacy system or to the new microservices based on URL paths.
As soon as a new function is ready, the switch is adjusted so that requests for this function are directed to the new application. The exact design of this switch varies greatly depending on the application landscape and must be evaluated individually.
What are the main reasons for choosing the Strangler Fig pattern?
The main reasons for choosing the Strangler Fig Pattern are the minimisation of risks, the continuous availability of the application, and the ability to carry out modernisation step by step and cost-effectively.
What does the "cutting process" before migration mean at Strangler Fig?
Slicing is the analytical breakdown of the monolith before starting the Strangler Fig Pattern. The code is broken down into functional components, grouped, and separated from each other. This is necessary in order to decide whether a module should be completely replaced by a new service or simply transformed (refactored).
Richard Gross is Head of Software Archaeology and has been working in IT modernisation since 2013. As a member of the division management team, he drives forward topics such as technical excellence. As a team leader and architect, he supports teams in achieving a return on investment as early and continuously as possible. To achieve this, he coaches teams in code quality, test automation and collective ownership. His technical focus is on hexagonal architectures, test DSLs, hypermedia APIs and the expressive and unambiguous modelling of the domain as code. Richard shares his knowledge through active pair programming, training courses, technical articles and presentations at international conferences. He has also been involved for many years in the open source project CodeCharta, which enables non-developers to gain an understanding of the quality of their software.