Modernising a Legacy System — The Strangler Fig Approach

Every business that has been operating for more than a few years has a legacy system. It might be a custom-built ERP written in a language nobody wants to work with anymore. It might be a十年前 的 client-server application running on a server under someone's desk. It might be a monolithic platform that started as a simple tool and grew into a tangled codebase that nobody fully understands.

These systems are not bad because they are old. They are bad because they are hard to change. Every new feature takes longer than it should. Every bug fix risks breaking something unrelated. The team that built it has moved on, and the documentation is either missing or wrong.

The instinctive response is to plan a big bang rewrite. Build a new system from scratch, migrate the data, and switch over on a weekend. This approach has a well-documented failure rate. The new system ends up costing more, taking longer, and delivering less than the old one because the complexity of the existing system is underestimated. The safest, most reliable approach is the strangler fig pattern: replace the legacy system piece by piece while the old system continues to run.

What legacy modernisation is

Legacy modernisation is the process of updating or replacing an existing software system to use modern technology, architecture, and practices while preserving the business functionality it provides. It is not the same as building a new system. A modernisation project starts with an existing system that works, handles real data, and supports real users. The new system must replicate that functionality precisely while improving maintainability, performance, security, and user experience.

The challenge of modernisation is that legacy systems carry years or decades of accumulated business logic, edge case handling, and behavioural quirks. Some of this is documented. Much of it lives in the heads of the people who have been maintaining the system. A big bang rewrite has to capture all of this before the switchover. An incremental approach captures it piece by piece as each component is replaced.

Modernisation can take several forms: rehosting (moving to new infrastructure without changing code), re-platforming (moving to a new platform with minimal code changes), refactoring (restructuring existing code), and replacement (building new components to replace old ones). The strangler fig pattern falls into the replacement category.

The strangler fig pattern explained

The strangler fig pattern takes its name from the tropical fig tree that starts life as a vine on a host tree and gradually grows around it until the host is eventually replaced. Applied to software, it means building new components alongside the legacy system and routing traffic to the new components one piece at a time.

Here is how it works in practice. A routing layer sits in front of both the old and new systems. For each feature or function that has been modernised, the router sends requests to the new component. Everything else continues to go to the legacy system. Over time, more and more features are migrated to the new system until eventually the legacy system has nothing left to do and is decommissioned.

The pattern works because there is never a single cutover moment. Every component is tested in production alongside the legacy system before it takes over. If a new component fails, the router can be reconfigured to send traffic back to the legacy system. The business never stops operating.

Assessment and planning

Before any code is written, the legacy system must be understood. This starts with a discovery phase that maps the system architecture, documents the business logic, identifies all integrations and data flows, and catalogues the pain points that the modernisation is meant to address.

The assessment should answer several questions. What is the actual state of the codebase? Is it maintainable or completely unreadable? What are the dependencies between components? Can they be separated, or are they tightly coupled? What are the data storage and access patterns? What third-party integrations exist, and what contracts govern them?

The planning phase defines the order in which components will be replaced. The ideal approach is to start with a component that is self-contained, has clear boundaries, and delivers visible benefit when replaced. This builds confidence and establishes the pattern for subsequent replacements. Save the most complex and tightly coupled components for later, when the team has experience with the migration process.

A strangler fig migration typically takes 6 to 24 months depending on the size and complexity of the system. Simple two-tier applications can be migrated in 3 to 6 months, while complex distributed enterprise systems with dozens of integrations can take 18 months or more. The cost in Bahrain ranges from BD 8,000 for a focused component replacement to BD 80,000 or more for a full system migration.

Phased replacement

Each phase of the strangler fig migration follows the same cycle. Identify the component to be replaced, build the new version alongside the legacy system, create the routing logic that directs traffic for that component to the new version, test the new version with real traffic while the legacy version remains active, verify that the new version handles all edge cases correctly, and switch the router to send all traffic for that component to the new version.

The cycle is repeated for each component in the order defined during planning. Early phases establish the infrastructure, data access layer, and routing mechanism. Later phases replace the core business logic components. The final phase decommissions the legacy system.

The number of phases depends on the size of the system. A small legacy application might be replaced in three or four phases. A large enterprise system with dozens of modules and integrations might require twenty or more phases spread over two years.

Data migration

Data migration is often the most complex part of a legacy modernisation project. The legacy database schema reflects decisions made years ago that may no longer match the new system's data model. Data quality issues such as missing values, inconsistent formats, and duplicate records accumulate over time and must be resolved during migration.

The strangler fig approach manages data migration incrementally. Each phase migrates only the data needed by the component being replaced. This avoids the risk of a single massive data migration that must complete successfully before the new system can go live.

Data synchronisation between the old and new systems during the transition period is handled by a sync layer that keeps both systems in step. When a record is created or updated in one system, the sync layer propagates the change to the other. This allows the two systems to operate in parallel until the legacy system is fully decommissioned.

Testing strategy

Testing an incremental modernisation involves several layers. Each new component is tested in isolation before it is connected to the routing layer. Integration testing verifies that the new component works correctly with the other components, both new and legacy. Parallel running testing compares the output of the new component with the output of the legacy component for the same input to verify behaviour match.

User acceptance testing is performed by the business users who will work with the new system. Because the strangler fig approach replaces one component at a time, users can provide focused feedback on each component as it is deployed. This is much more effective than presenting them with an entirely new system at the end of a long project.

Regression testing ensures that changes to one component have not broken another. Automated regression tests are essential for a project that runs over months or years, because manual testing of the entire system becomes prohibitively expensive as the number of phases grows.

Choosing a partner

Legacy modernisation is not a project for a generalist development team. It requires experience with the specific challenges of understanding and replacing complex existing systems. The partner you choose should demonstrate experience with strangler fig or similar incremental migration patterns, not just big bang rewrites.

Look for a partner who starts with a thorough assessment phase and resists pressure to begin coding before the existing system is understood. Avoid partners who propose a fixed-price, fixed-scope contract for the entire modernisation, because the scope of a strangler fig migration evolves as you learn more about the legacy system. A time-and-materials or phased fixed-price model is more realistic.

The partner should also have experience with data migration, legacy database technologies, and the specific programming languages and frameworks your legacy system uses. If they have to learn your legacy technology from scratch, that learning cost will show up in the budget and timeline.