What is the strangler fig pattern?

The strangler fig pattern is a software modernization approach that replaces a legacy system gradually instead of rebuilding it from scratch. Rather than migrating everything at once, teams introduce new services or components alongside the existing application and move functionality step by step until the legacy system can be safely retired.

The concept was popularized by software engineer Martin Fowler, who named it after the strangler fig tree. In nature, strangler figs grow around a host tree, gradually expanding until they become strong enough to stand on their own. Eventually, the original tree dies, leaving the fig tree in its place. Fowler used this metaphor to illustrate how a modern application can gradually "grow around" a legacy system, replacing one capability at a time until the old software is no longer needed.

Working with our clients, we have seen that successful modernization does not always require a complete rewrite. For example, the Facta project involved modernizing a financial platform through technical refactoring and UX improvements while keeping the system running. By migrating parts of the solution to Golang without stopping operations, the team reduced the effort required for month-end closing by 80%.

‍

For organizations dealing with aging software, the strangler fig pattern provides a practical approach to legacy system modernization because it balances technical progress with business continuity. If you're still assessing whether your application qualifies as a legacy system, read our guide on what is a legacy system.

Why big bang rewrites fail

Replacing a legacy system from scratch may seem like the cleanest solution. A new architecture, modern technologies, and no limitations caused by years of accumulated changes can be an attractive vision. In our experience, large-scale rewrites often become one of the riskiest approaches to legacy system modernization.

One of the biggest challenges with legacy applications is that they are rarely made up of isolated components. Over time, they evolve into complex ecosystems with tightly coupled code, undocumented dependencies, and critical business logic embedded across the system. As a result, even seemingly small changes can require teams to understand multiple parts of the application, increasing the cognitive load and making further development more difficult.

Miłosz Kusiciel

Head of Technology at Merixstudio

As a result, organizations often face several limitations:

• High maintenance costs: outdated technologies and complex code structures make every change more time-consuming and expensive.
• Limited scalability: monolithic systems often make it difficult to scale individual features or services independently when business needs change.
• Technology constraints: older frameworks, programming languages, and infrastructure choices can slow down development and limit future improvements.
• Growing technical debt: years of accumulated shortcuts and workarounds make the system harder to evolve.
• Increased dependency between components: tightly connected parts of the application create a higher risk that changes in one area will affect others.

A big bang migration replaces the entire system in a single transition, concentrating complexity, uncertainty, and risk into one major release.

During the rewrite, teams often need to maintain the old application while building its replacement. This can slow product development, delay new features, and make rollback difficult if the new system does not meet expectations.

This challenge is especially visible in systems that support ongoing business operations. For example, modernizing a business insurance application built on a legacy ColdFusion stack required replacing outdated technology while keeping active insurance processes running. Instead of treating modernization as a single disruptive event, the project focused on delivering a modern application while maintaining business continuity throughout the transition.

How the strangler fig pattern works

The core idea behind the strangler pattern is to create a controlled transition between the legacy application and the modernized solution. This approach allows teams to validate changes gradually, reduce migration risks, and avoid disrupting business operations.

A typical implementation of the strangler design pattern consists of four main phases:

Phase 1: Introducing a façade layer

The first step is adding a façade or proxy layer between users and the legacy application. It becomes a single entry point that can route requests between the existing system and new components without changing the user experience.

Phase 2: Migrating functionality incrementally

With the proxy layer in place, teams can gradually move individual features or business capabilities to the new architecture. Feature flags can help control releases, test changes safely, and switch back if issues occur.

Phase 3: Retiring legacy components

As more functionality is migrated, outdated components become unnecessary and can be removed. Handling this step gradually helps teams manage dependencies and reduce the risk of unexpected failures.

Phase 4: Removing the façade layer

Once all required functionality has been migrated, the temporary façade or proxy layer can be removed. The result is a modern architecture that no longer depends on the legacy system, without the disruption of a full rewrite.

Migrating a monolith to microservices with the strangler fig pattern

The strangler fig pattern microservices approach helps teams break down complex monoliths gradually instead of replacing them all at once. The first step is identifying the right service boundaries using techniques such as domain-driven design (DDD) and event storming to define clear bounded contexts.

Teams usually start with modules that are loosely coupled, have clear business ownership, and can operate with their own data access patterns. Migration order should be based not only on technical feasibility but also on business value and ROI.

AI can support this process by helping teams analyze existing codebases, understand system dependencies, and identify potential boundaries during monolith decomposition. It can accelerate discovery, but architectural decisions still require domain knowledge and engineering judgment.

The strangler fig pattern is one of several approaches organizations can consider when planning legacy system modernization. Choosing the right strategy depends on factors such as system complexity, business priorities, and migration risks.

Handling data during the migration

Data migration is often the most complex part of applying the strangler approach. While application functionality can be moved gradually, separating data from a shared legacy database requires careful planning to maintain consistency between old and new systems.

A common strategy is database decomposition - gradually moving domain-specific data ownership from the monolith to new services. This typically involves:

• identifying data boundaries,
• creating new data stores,
• synchronizing changes through change data capture (CDC),
• validating consistency,
• and switching traffic to the new implementation when it is ready.

Throughout the process, teams need to manage dependencies between systems and keep rollback options available. This allows organizations to migrate data step by step without disrupting ongoing business operations.

In some cases, modern architectures also introduce polyglot persistence, where different services use databases that best fit their specific requirements rather than relying on one shared data model.

A practical example is the modernization of the SafeEx platform, used for oil and gas inspections. The project involved migrating from MySQL to PostgreSQL while keeping the system available for inspectors working in demanding field conditions, including environments with limited network access. The team approached the migration incrementally, improving the data layer and introducing solutions such as offline synchronization. As a result, the platform achieved significantly better performance, including around 10x fewer database queries and faster data views.

Supporting patterns and tools

The strangler fig pattern rarely works in isolation. Large-scale modernization projects often require additional architectural patterns and tools to manage communication between old and new components, reduce migration risks, and keep the system reliable during the transition.

During a migration, teams may also use supporting platforms for API management, feature flagging, monitoring, and deployment control. The specific tools depend on the technology stack and business requirements, but the goal remains the same: enable controlled change without disrupting existing operations.

Benefits and limitations

The main advantage of the strangler fig pattern is that it reduces migration risk by allowing teams to modernize step by step. Instead of replacing the entire system at once, organizations can introduce changes gradually and validate each transition.

Key benefits include:

• Lower migration risk: changes are introduced incrementally instead of in one high-impact release.
• Business continuity: the legacy system can keep supporting operations while new components are introduced.
• Faster delivery of value: teams can release improvements before the full migration is complete.
• Easier rollback: individual changes can be reverted without restoring the entire system.
• Improved security and maintainability: modernization often enables teams to adopt supported technologies, newer libraries, and more secure components.
• Continuous development: product teams can keep building new features during the transition.

Learn more about how modernization strategies can help organizations reduce time to market when working with outdated software.

However, the strangler fig pattern also introduces additional complexity. Running legacy and modern components in parallel requires careful planning and coordination.

Common limitations include:

• Facade dependency: the routing layer becomes a critical component that requires reliability and monitoring.
• Higher operational costs: teams need to maintain both old and new systems during migration.
• Legacy system knowledge requirements: successful migration depends on understanding existing code and dependencies.
• Limited fit for smaller systems: a full rewrite may be simpler for applications with low complexity.

The strangler fig pattern works best for large, business-critical systems where reducing migration risk and maintaining continuous delivery are priorities.

When to use the strangler fig pattern and when to avoid it

The strangler approach is not suitable for every modernization project. It works best when organizations need to transform a complex system gradually while keeping the business running and continuing to deliver new features.

The strangler fig pattern is a good fit when:
The system is large, complex, and difficult to replace in one step.
Business operations cannot be interrupted during migration.
Teams need to continue delivering new functionality while modernizing the application.
The transformation is expected to take months or years rather than a single release.

However, this legacy migration strategy may not be the right choice when:

• The system cannot support request routing through a façade or proxy layer.
• The team does not have access to the existing codebase or enough knowledge of the legacy application.
• The application is small enough that a complete rewrite would be faster and more cost-effective.
• The business requires the legacy system to be removed immediately.

These decisions are often driven by broader business constraints, not only technical considerations. Understanding the main business challenges of legacy system modernisation can help teams evaluate risks before choosing a migration strategy.

Modernizing critical systems without disrupting delivery

The strangler fig pattern is not just a way to refactor legacy software - it is a strategy for reducing modernization risk while keeping business operations running.

Every legacy system has different constraints, dependencies, and goals. Finding the right modernization path requires a clear understanding of the current architecture and business priorities.

Planning to modernize a legacy system? Our team can help you assess your application, shape the right migration strategy, and move toward a scalable microservices architecture with confidence. Learn more about our software modernization services and how we can help you take the next step.