Introduction

Modernizing legacy systems has become a decisive pillar of competitiveness for many mid-sized companies in Germany. Outdated custom software with high maintenance costs and complicated dependencies ties up resources and stifles innovation power. In view of growing competitive and cost pressure, managing directors and IT leaders are increasingly looking for ways to renew their legacy software in order to gain agility and reduce technical debt.

In this context, the "strangler fig pattern migration" is moving more and more into focus. This model allows legacy systems to be replaced step by step without endangering operational day-to-day business. Instead of carrying out a risky "Big Bang switch," companies can phase out individual function blocks gradually and thus minimize security risks or downtime. As Microsoft Learn outlines, a façade takes over the steering: new services work in parallel with the legacy software until the old system is completely replaced.

We have observed that this approach not only makes technical change smoother but also motivates employees, since they can ease into new methods and processes step by step. In what follows, we show how the Strangler Fig pattern works, what advantages it offers, and what steps must be considered during the migration.

Why the Strangler Fig Pattern?

Many IT leaders underestimate the effort involved in replacing legacy systems. Classic methods often rely on a complete redevelopment followed by an abrupt switchover. This so-called "Big Bang approach," however, frequently leads to long project durations, high investment costs, and enormous risks. This is where the Strangler Fig pattern comes in, putting the gradual replacement strategy in the foreground.

Especially in the German mid-market, heterogeneous IT landscapes and the shortage of skilled workers for old technologies often complicate the rapid replacement of entire systems. Critical software is often based on outdated programming languages and platforms for which only a few experts are still available. The costs for training and transition phases are considerable, while at the same time ongoing operations must remain stable. In our experience, it therefore makes sense to pursue incremental approaches that enable low-disruption modernization.

The Strangler Fig pattern additionally offers the advantage that companies see partial results very early on. New modules that deliver more efficient processes or modern interfaces are put into operation quickly. This often accelerates the overall project, since positive results reinforce the will to change. The iterative approach also relieves project management, since risks can be detected and remedied more quickly. In this way, we reduce hurdles that often arise when modernizing legacy systems and lay the foundation for a future-proof architecture.

How Does the Façade Work?

The pivot point in strangler fig pattern migration is the so-called façade (or proxy). It serves as a mediator between the old monolithic system and the new services that gradually replace the legacy system. As soon as a certain functionality is available in the new system, the façade routes the data traffic there. According to Microsoft Learn, this approach is particularly suitable for designing the transition in a controlled and transparent way for all parties involved.

The actual key: users and customers initially do not even notice that individual parts of the software have already been swapped out in the background. They continue to interact via the same interfaces. The façade sends requests either to the old code or to the newly developed microservices, depending on what has already been completed. From an operational perspective, this enables parallel operation of old and new components until all requirements are covered.

Compared with other modernization approaches, this not only reduces maintenance costs of legacy systems but also minimizes critical bottlenecks such as data inconsistencies. By selectively redirecting calls — piece by piece, function by function — we gain flexibility. In the event of unexpected problems, the façade can simply route the traffic back to the old system. This safety net protects against larger outages, meets the requirements for business continuity, and creates trust with all stakeholders.

Steps for a Successful Strangler Fig Pattern Migration

The strangler fig pattern migration relies on an iterative concept that requires careful planning and clear milestones. We have found the following steps particularly effective in our projects:

1. Goal definition and scope: First, a sharp delimitation of the functional areas to be modernized is needed. Are all processes being replaced or only the particularly critical ones? A precise goal definition is the cornerstone of the project.

2. Setting up the façade: In the second step, we set up the façade, which is responsible for redirecting requests. We thus ensure that both systems (old and new) can coexist.

3. Selection and implementation of new components: Now the first building blocks of the legacy system are replaced by modern services. Functions that have few dependencies and at the same time deliver high added value should be identified.

4. Test phase and monitoring: Once a module is live in the new system, monitoring must observe closely whether all interfaces are working correctly. The façade can also be configured initially so that only a portion of requests is routed to the new service (canary release).

5. Incremental expansion: Once the first services run smoothly, we expand the scope. More and more functions move to the new system. The façade switches over step by step.

6. Decommissioning the legacy system: Once all essential components have been migrated and are stable, the old system can be shut down. The façade then becomes superfluous and can be removed after a final test.

With every step, we reduce dependencies and increase innovation capability. Especially for companies wanting to switch from monolithic applications to a microservice structure, the process creates a clear roadmap. Anyone wanting to delve deeper into increments and overall strategies will find further approaches in our comparison big bang vs. incremental migration.

Practical Benefits with an Example

To make the advantages more tangible, let's look at a fictional example. Imagine a mid-sized trading company that has been operating its inventory management system for years: it is based on an older database and a self-developed core that can only be adapted with great effort. Maintenance efforts are rising and skilled personnel are missing to quickly implement changes. In addition, no unified dashboard exists that displays inventory levels or sales figures in real time.

With the Strangler Fig pattern, we set up a façade proxy that takes in all user requests. Initially, the focus is on implementing contemporary inventory management. We develop a new microservice that draws data from the legacy system but already supports modern analytics for logistics and purchasing. Initially, perhaps only 10 percent of user requests are routed via the new service. If everything runs stably, this value gradually increases until the old code for inventory management is finally replaced.

In parallel, further modules can be modernized, such as invoicing or reporting. Step by step, a new system landscape thus emerges without the day-to-day business standing still or high failure risks arising. According to Thoughtworks, this gradual approach has proven particularly effective in practice projects. The company also benefits from rapid successes, which further increases acceptance in the business units.

Advantages of Iterative Modernization

The Strangler Fig pattern has established itself as one of the most effective methods for modernization strategies for legacy software. We see at least seven clear advantages:

• Lower risk: Instead of renewing everything at once, we change function after function. Errors can thus be more accurately isolated and remedied.
• Better predictability: Sub-projects have clearly defined goals. This facilitates budgeting and personnel planning.
• Faster successes: First results are implemented quickly, and improved customer feedback fosters investment willingness.
• Higher employee acceptance: The team learns to handle new technologies step by step. This reduces resistance.
• Continuous improvement: Progress in each migration phase delivers insights that flow into the next steps.
• Flexibility: New services can be updated or extended independently of one another.
• Stable transition: Ongoing operations remain ensured, since the old system remains functional in parallel.

All these points underscore why we frequently rely on incremental methods for replacing legacy systems in our projects. Especially when we migrate from a monolith to microservices or when data migration in legacy systems is on the agenda, the Strangler Fig strategy provides a great deal of security.

A fitting comparison comes from the natural metaphor itself: just as the strangler fig tree gradually surrounds its host and eventually replaces it, the new system gradually grows around the old one until it can fully take over.

Challenges and Solution Approaches

Despite all the advantages, a strangler fig pattern migration is not a self-runner. Complex dependencies and interfaces between different modules often exist, requiring particular care. We have summarized some common challenges below and illustrated solution approaches from our project experience.

First, a longer transition phase can occur in which both system worlds run in parallel. This sometimes leads to increased coordination effort between teams responsible for the old and the new system. Our advice is to define clear responsibilities from the beginning and set up a governance plan. We thus avoid important updates being delayed or unnecessary conflicts arising.

Second, data quality often poses a hurdle. Old structures sometimes contain incomplete data records, redundant tables, or inconsistent formats. If we don't establish order from the outset, this can slow down the new solution. A dedicated data-cleansing project or targeted workshops to harmonize master data help to remedy problems early.

Third, the human factor should not be underestimated. In companies that have worked with the same tools and processes for a long time, willingness to try new things is often missing. Training, workshops, and regular communication have proven their worth here: we explain why the switch is necessary and what advantages it brings. By celebrating successes and building up engaged employees as "digital champions," we create a cultural change that benefits the project sustainably.

Fourth, resistance sometimes arises in IT security and compliance. As soon as data is exchanged between old and new systems, complexity in permissions management increases. In such cases, we recommend developing a comprehensive security concept that includes encryption, access rights, and monitoring. We also point here to tools for role concepts and to audits that ensure GDPR and corporate guidelines are observed at all times.

Data Migration and Synchronization

In many projects, the path to modernization inevitably leads through data migration. Often the old and new systems share the same data pool for a while or must continuously align data. This is where the Strangler Fig pattern can play to its strengths, since routing can be flexibly controlled: certain transactions continue to run via the old database, while new entries are already stored in the new system.

In our experience, three common strategies help to implement an orderly data migration:

1. Shared database use: Both systems initially access the same database schema. If the risk is too high or the schema is outdated, we rely on synchronization in partial steps.
2. Event-based replication: New data records or changes are published via events and mirrored into the respective other environment. This reduces latency and preserves data consistency.
3. Temporary ETL processes: To handle particularly large data volumes, an ETL layer (Extract, Transform, Load) is suitable, which regularly processes extracts and fills the new system. Microsoft Learn also recommends so-called shadow writes in this context, in which certain operations are executed in parallel in both systems.

The choice of the right strategy always depends on the requirements, such as the necessary real-time processing and the security level. In any case, the façade must be able to recognize where data is being written and read in order to avoid conflicts. This requires a careful monitoring setup. Many teams set up separate dashboards for data flow so that potential problems can be detected in real time.

Comparison: Big Bang vs. Strangler Fig

To clarify the special added value of the Strangler Fig pattern, a brief comparison is helpful. While in the Big Bang approach everything is switched at once, the strangler fig pattern migration involves a gradual replacement of individual components. We summarize this in a table:

| Approach | Risk | Project Duration | Flexibility | |---------------------------|-------------------|--------------------------------------|------------------------------------------| | Big Bang migration | Very high | Short, but very intense upheaval | Low, since everything happens at once | | Strangler Fig migration | Moderate to low | Longer, but with steady progress | High, since step-by-step approach is possible |

As we can see, the Big Bang method requires fewer intermediate stages but carries enormous dangers: if errors occur, the entire operation suffers immediately. The Strangler Fig pattern, in contrast, relies on gradual replacement and thus offers more security. Companies wanting to replace their legacy system can thus focus on individual sub-projects and build up the described expertise more quickly. In the long term, this enables more cost-efficient and stable modernization.

Conclusion

We are convinced that the strangler fig pattern migration is the ideal way for many mid-sized businesses to modernize legacy systems and successfully build on new technologies for the long term. The iterative approach reduces the risk of serious failures and makes it possible to continue proven business processes in a new environment. Instead of putting large budgets into a high-risk complete switchover, both time and financial resources remain better plannable.

Central to this is the smooth interplay between the legacy system and new services. Success therefore stands and falls with clean architectural planning and confident implementation of the façade. Anyone proceeding in a structured way can make adjustments at any time and address complex topics such as data migration in legacy systems or security requirements in a targeted manner. In this way, modernization can take place piece by piece until eventually the entire old structure is replaced by a new, flexible IT landscape.

Last but not least, the staff also benefits: employees learn to get used to the new tools and processes, while familiar workflows are still available in parallel. This results in fewer reservations, and change becomes anchored in everyday work. Supported by training and clear communication, this approach strengthens corporate culture, brings fresh ideas, and helps to defuse the shortage of skilled workers for old technologies.

We have learned that organizations applying such an incremental modernization model react more quickly to customer-side or technological changes and can reduce maintenance costs of legacy systems. They thus remain not only capable of acting but become drivers of innovation. The Strangler Fig pattern impressively shows how IT systems can be renewed responsively without a company taking unnecessary risks. For everyone considering modernization strategies for legacy software, the gradual replacement offers a proven path to confidently meet future challenges.