The Strangler Fig Approach to Legacy Modernization
The strangler fig metaphor for legacy software replacement comes from a botanical observation made during a vacation in Queensland, Australia, in 2001. Strangler figs germinate in the nooks of host trees, drawing nutrients from them as they grow. Once their roots reach the ground and their canopy reaches the sunlight, they become self-sustaining — and the original host may die, leaving the fig as its skeletal echo. That gradual process of replacement struck the observer as an apt analogy for how colleagues were modernizing legacy systems at the time.
The term has since become a standard label for this modernization strategy. Its original author later revised the name to "Strangler Fig Application" to emphasize the botanical roots of the metaphor, rather than the violent connotations of the word "strangler" alone.
Why Full Replacement Fails
Many software systems were built over decades with little ongoing investment in their health. As business needs and technology shift, teams patch these systems repeatedly, and with each patch they become harder to adapt further. Eventually, teams conclude that a wholesale modernization is necessary.
The tempting plan is simple: the old system's behavior is known, so build a new system that replicates it exactly on better technology. In practice, this approach most often fails. Serious IT systems take a long time to rebuild, and users cannot wait for new features in the meantime. Specifying existing behavior is difficult, and much of that behavior is undesirable anyway — reproducing it is wasted effort.
An Incremental Alternative
The preferred alternative is a gradual modernization process that mimics the strangler fig's growth. Small additions, often new features, are built on top of the legacy code base but kept separate from it. Over time, pieces of behavior are shifted from the legacy system into the new code base until it takes over entirely.
Ian Cartwright, Rob Horn, and James Lewis defined four high-level activities required for this incremental approach:
- Understand the outcomes you want to achieve.
- Decide how to break the problem up into smaller parts.
- Successfully deliver the parts.
- Change the organization to allow this to happen on an ongoing basis.
Note that these activities are not ordered — none of them needs to finish before another begins.
Clarity of Purpose
Before starting any modernization effort, the desired outcomes must be crystal clear. Muddled objectives are common, with different stakeholder groups wanting different things. Alignment on the key outcomes should be established early and revisited regularly, both to reinforce the alignment and to check whether priorities have shifted.
Finding Seams
Well-designed software consists of clear, independently replaceable components. Legacy systems rarely do. Considerable work goes into figuring out how to break a legacy system into manageable pieces, which involves identifying seams that can be inserted to allow the system to be split. Identifying how the system supports different business needs is often a useful starting point, as individual needs can be extracted into new components.
Replacing Components and Building Transitional Architecture
Once seams isolate a few components, those components can be replaced. Because each component is small, introducing new software carries much less risk than full replacement. Working new components deliver business value early, providing an earlier return on investment. Each replacement also teaches more about how to replace the legacy system and what that implies for the business, enabling better decisions as the work proceeds.
Teams often resist the necessity of building transitional architecture — code that will disappear once the modernization is complete — to let the new and legacy systems coexist. While it may look wasteful, the reduced risk and earlier value from the gradual approach outweigh the costs.
Organizational Change Is Part of the Work
Threaded through all of this is broader organizational change. Legacy systems become rigid and brittle because the design thinking and organizational processes that produced them made them that way. Without shifts in organizational culture and leadership, the new systems will end up in the same mess. That means introducing new development practices and reorganizing the development organization and its connections with the wider business, in recognition of Conway's Law.
A Gradual Investment with Gradual Returns
Using a strangler fig approach does not make modernization easy. Replacing a software system deeply embedded in business processes is never a simple task. What the approach does do is make both investment and returns gradual and visible. That allows the organization to evolve its software and business processes to fit the current environment — and, perhaps more importantly, to develop a more sustainable way of handling that evolution in the future.
