Every organization with significant software history faces the legacy modernization challenge. Systems that once represented cutting-edge development become obstacles to progress. The architecture that enabled early success constrains future growth. Technology choices made years ago no longer align with current needs or available talent.
The temptation to address this through complete rewrites is strong. A fresh start promises clean architecture, modern technologies, and escape from accumulated technical debt. But rewrite projects carry significant risk. They take longer than expected, cost more than budgeted, and often fail to deliver the promised benefits. Meanwhile, the legacy system must continue operating and evolving, creating a moving target that the rewrite struggles to hit.
The strangler fig pattern offers an alternative. Named after the fig trees that grow around host trees, eventually replacing them while both systems coexist, this pattern enables incremental modernization. New functionality is built in modern systems. Legacy functionality is migrated piece by piece. The legacy system gradually shrinks while the modern system grows, until eventually the legacy system can be retired entirely.
Why Rewrites Fail
Understanding why rewrites fail helps clarify why incremental approaches often succeed.
Second System Syndrome
Rewrite teams see all the flaws in the existing system and attempt to fix everything at once. The scope expands beyond replacement to include improvements, new features, and architectural ambitions that were never part of the original plan. What started as a straightforward replacement becomes an attempt to solve every problem simultaneously.
This expansion extends timelines, increases risk, and often produces systems that are architecturally elegant but do not actually meet user needs as well as the messy original.
Knowledge Loss
Legacy systems encode years of accumulated business knowledge. Much of this knowledge exists only in the code, not in documentation or the memories of current team members. Rewrites must rediscover this knowledge through painful experience, often only learning that certain behaviors were intentional when users complain about their absence.
Edge cases, special handling, and subtle behaviors that users depend on are easily overlooked during rewrites. Each omission creates friction and erodes confidence in the new system.
Moving Target
The legacy system rarely freezes during a rewrite. Business continues, requirements evolve, and the legacy system must adapt. Every change to the legacy system potentially requires corresponding changes to the in-progress rewrite. This moving target makes completion increasingly difficult.
Rewrite teams often discover that by the time they have achieved feature parity with the legacy system from six months ago, the legacy system has evolved in ways they have not replicated.
Big Bang Risk
Rewrites typically culminate in a big-bang cutover where the organization switches from legacy to modern in a single event. This cutover concentrates risk. If problems are discovered post-cutover, the organization must choose between struggling through with the problematic new system or executing an embarrassing rollback.
Neither option is good. The strangler fig pattern avoids this binary choice by enabling gradual transitions.
The Strangler Fig Approach
The strangler fig pattern replaces legacy systems incrementally through three mechanisms.
Intercept
A facade or proxy sits in front of the legacy system, intercepting all requests. Initially, this facade routes all traffic to the legacy system. As modernization progresses, the facade routes specific requests to new services while continuing to route others to the legacy system.
This interception layer is the key enabler. It provides the ability to shift traffic between systems without requiring changes to callers. It also provides visibility into traffic patterns that inform modernization priorities.
Common interception approaches include:
For HTTP-based systems, an API gateway can route requests based on path, header, or content. This is often the simplest approach for web applications and microservices.
For event-driven systems, message routers can direct messages to either legacy or modern consumers. This supports asynchronous patterns common in enterprise systems.
For data-centric systems, database triggers or change data capture can replicate changes to both legacy and modern data stores, enabling gradual migration of data consumers.
Transform
New functionality is built in modern systems from the start. Rather than adding features to the legacy system, new requirements are implemented in the emerging modern architecture. This ensures that modernization effort is cumulative, with each new feature strengthening the modern system.
Transforming also involves migrating existing functionality from legacy to modern implementations. This migration happens function by function, module by module. Each migrated piece reduces the legacy system’s scope while expanding the modern system’s capabilities.
The key insight is that transformation is incremental. You do not need to migrate everything before you can retire anything. Each migration provides immediate value and reduces ongoing legacy maintenance burden.
Terminate
As functionality migrates, the legacy system shrinks. Eventually, all functionality has been migrated or deliberately deprecated. At this point, the legacy system can be retired. This termination happens naturally as a consequence of successful migration, not as a risky cutover event.
Termination may happen in stages. Modules that have been fully migrated can be disabled or removed from the legacy system even while other modules continue operating. This progressive shutdown provides confidence that migrated functionality works correctly before losing the fallback option.
Planning a Strangler Fig Migration
Successful application of the pattern requires thoughtful planning and execution.
Map the Legacy System
Before migration begins, understand what you are migrating. Map the legacy system’s capabilities, dependencies, data flows, and integration points. Identify which parts of the system provide the most business value and which impose the most maintenance burden.
This mapping reveals migration priorities and dependencies. Some components must be migrated before others due to coupling. Some components provide disproportionate value and should be prioritized. Some components may be candidates for deprecation rather than migration.
Define the Target Architecture
Clarity about the target architecture prevents drift and maintains focus. Define what the modern system will look like when migration is complete. This architecture should inform decisions throughout the migration, ensuring that migrated components fit together coherently.
The target architecture need not be fully detailed upfront. It should establish principles, patterns, and boundaries while leaving room for learning during migration. Architectural decisions can be refined as understanding of actual requirements improves.
Identify Seams
Seams are boundaries where the legacy system can be split. Good seams have minimal cross-boundary data flow and clear interfaces. Poor seams have extensive coupling that makes separation difficult.
Identifying seams is crucial because they determine what can be migrated independently. A well-identified seam becomes a migration unit that can be extracted, replaced, and verified without disrupting other parts of the system.
Common seam locations include:
Complete user-facing workflows that can be migrated as units.
Distinct functional areas with limited coupling to other areas.
Data with clear ownership that can be isolated.
External system connections that can be redirected.
Sequence Migrations
Not all seams should be migrated at once. Sequencing considers:
Migrate high-value areas early to demonstrate progress and capture benefits.
Start with lower-risk migrations to build confidence and develop migration capabilities.
Respect coupling that requires certain migrations before others.
Match migration scope to available capacity while maintaining velocity.
A common approach migrates a low-risk, moderate-value area first. This builds migration muscle without excessive risk. Subsequent migrations tackle higher-value areas with increased confidence.
Managing Data During Migration
Data presents particular challenges during strangler fig migrations. Legacy and modern systems often need access to the same data, but with different schemas, storage technologies, or access patterns.
Synchronization Strategies
Capture changes from legacy databases and apply them to modern data stores. This enables modern services to read current data without requiring legacy modification.
Applications write to both legacy and modern data stores. This requires careful handling of failures and consistency.
Publish domain events that both legacy and modern systems can consume. This decouples systems while maintaining data consistency.
Each strategy has tradeoffs involving complexity, consistency guarantees, and performance. Select based on your specific requirements and constraints.
Data Migration
Bulk data migration moves historical data to modern systems. This migration typically happens in phases:
Define how legacy data structures map to modern schemas. Address semantic differences, not just structural differences.
Clean data quality issues that the modern system will not tolerate. Legacy systems often accumulate invalid data that worked due to permissive handling.
Move data with appropriate verification. Large datasets may require incremental approaches that migrate data over time.
Verify that migrated data is correct and complete. Automated comparison between legacy and modern data catches migration errors.
Eventual Consistency
During migration, legacy and modern systems may have temporarily inconsistent data views. Design for this reality. Understand which use cases require strong consistency and which can tolerate eventual consistency. Implement appropriate strategies for each.
Common Challenges and Solutions
Strangler fig migrations encounter predictable challenges.
Legacy System Resistance
Legacy systems were not designed to be strangled. They may lack clear interfaces, have extensive internal coupling, or depend on technologies that do not support interception. Sometimes the legacy system must be modified to enable migration, which requires investment in a system you intend to retire.
Accept that some legacy investment may be necessary. Creating clean interfaces in the legacy system enables cleaner migration. The investment pays off through reduced migration risk.
Organizational Resistance
Stakeholders accustomed to the legacy system may resist change. Users familiar with existing workflows may resist new interfaces. Maintenance teams may resist losing expertise relevance.
Address resistance through communication, involvement, and demonstrated value. Include stakeholders in migration planning. Involve users in defining modern system requirements. Retrain maintenance teams on modern technologies.
Maintaining Momentum
Long-running migrations risk losing momentum. Initial enthusiasm fades. Competing priorities emerge. The legacy system continues operating, reducing urgency.
Maintain momentum through visible progress, celebrated milestones, and continuous value delivery. Each migrated component should provide measurable benefit. Communicate progress regularly to stakeholders.
Testing Complexity
Testing strangler fig systems requires validating both legacy and modern behavior, plus the interaction between them. The interception layer adds testing surface area. Ensuring equivalent behavior across systems requires extensive comparison testing.
Invest in automated testing that validates behavior equivalence. Record and replay traffic from the legacy system against modern implementations. Implement shadow modes where modern systems process requests without affecting users, allowing behavior comparison.
When Strangler Fig Is Not the Right Approach
The strangler fig pattern is powerful but not universal. Consider alternatives when:
If the legacy system lacks any seams, creating them may require more effort than other approaches. Some systems resist incremental migration.
If modernization fundamentally changes the application domain, incremental replacement may not make sense. Sometimes you need to build something new rather than replace something old.
Strangler fig trades speed for safety. If business needs require faster migration than incremental approaches allow, the risks of rewrite may be acceptable.
Very small systems may not justify the overhead of interception layers and parallel operation. Simple replacement may be more efficient.
How VergeOps Can Help
VergeOps has guided numerous organizations through legacy modernization using strangler fig and related patterns.
Modernization Assessment. We evaluate your legacy systems, identify seams, and develop migration strategies that balance risk, cost, and value.
Architecture Design. We design target architectures that serve current needs while enabling future evolution. Our architectures incorporate lessons from previous modernization efforts.
Migration Execution. We execute migrations alongside your teams, building internal capability while delivering results. Our approach transfers knowledge so your organization can sustain momentum independently.
Pattern Guidance. We help teams apply strangler fig and related patterns effectively, avoiding common pitfalls and accelerating successful migration.
Contact us to discuss how we can help modernize your legacy systems incrementally and safely.