There’s a plant called the strangler fig that has an unusual growth pattern. It starts as a seed in the canopy of another tree, sends roots down to the ground, and gradually grows its own trunk around the host. Eventually, the fig can stand on its own, and the original tree—no longer needed—decays away.
It’s not a hostile takeover. It’s a gradual transition where the new structure supports itself before the old one disappears.
This is exactly how you should modernize a legacy platform.
Why This Works for Established Businesses
If you’re running a platform that’s been making money for a decade, you can’t afford to stop. You have customers who depend on you. You have revenue you need to protect. You have employees whose salaries come from that system working.
The strangler pattern lets you modernize while the existing system keeps running. No “big bang” cutover. No praying that the new system handles all the edge cases. No months of parallel running and data reconciliation.
Instead, you gradually route traffic from the old system to new components, one piece at a time. The old monolith gets smaller. The new architecture grows. At no point do you bet the company on a single migration weekend.
The Playbook: Step by Step
Step 1: Put a Front Door in Place
Before you change anything else, put a proxy or API gateway in front of your existing system. This becomes your “front door”—the single entry point that can route requests to either the old system or new services.
At first, this front door just passes everything through to your existing monolith. Nothing changes for users. But now you have a control point.
This might be as simple as an nginx configuration, or as sophisticated as a proper API gateway like Kong or AWS API Gateway. The complexity should match your needs.
Step 2: Pick Your First Slice
Choose one part of your system to extract. Not the most important part—the most extractable part.
Good candidates for your first slice:
- Reporting or analytics: Usually read-only, well-defined inputs and outputs, low risk if something goes wrong
- File exports: PDF generation, CSV exports, invoice creation—isolated functionality that doesn’t touch core data
- Notification services: Email sending, SMS alerts—easy to test, easy to roll back
- Authentication: Often worth extracting early because it enables better security and can be reused by new services
Bad candidates for your first slice:
- Payment processing (too critical)
- Core transaction engine (too complex)
- Anything that’s deeply entangled with five other systems (too risky)
Step 3: Build the New Service
Build a new service that handles your chosen slice. This service should:
- Be completely independent—its own codebase, its own database if needed
- Have comprehensive tests, especially around the contract with the rest of your system
- Include proper monitoring and logging from day one
- Support easy rollback by keeping the old code path available
This is where AI can genuinely help. Use it to accelerate development of the new service. Generate boilerplate. Suggest implementations. But don’t skip the testing—AI-generated code needs testing just as much as human-written code.
Step 4: Route and Verify
Once your new service is built and tested, update your front door to route that slice of traffic to the new service. Start small:
- Route 1% of traffic to the new service
- Compare results with the old system
- Look for discrepancies, errors, performance issues
- Gradually increase to 10%, then 50%, then 100%
Keep the old code path available. If something goes wrong, you can route traffic back immediately.
Step 5: Repeat
Once your first slice is stable, pick the next one. Each successful extraction builds confidence and expertise. Your team gets better at this. Your architecture gets cleaner. Your old monolith gets smaller.
How to Decide What to Extract Next
After your first success, you have choices. Here’s a framework for prioritizing:
| Factor | Extract Sooner | Extract Later |
|---|---|---|
| Business impact | Causing pain for customers or team | Working fine, just ugly |
| Risk level | Can be tested independently | Deeply entangled with core systems |
| Complexity | Clear boundaries and interfaces | Unclear scope, many dependencies |
| Value | Enables new features customers want | Nice to have, not requested |
The Math That Makes This Work
Let’s say a full rewrite would cost $500,000 and take 18 months (and probably still fail). Instead:
- First slice: $40,000, 6 weeks, delivers immediately
- Second slice: $35,000, 5 weeks
- Third slice: $50,000, 8 weeks
After three slices and $125,000, you have a partially modernized system that’s already delivering value. You can stop anytime. Each investment pays for itself independently.
This is how you sell modernization to a price-conscious CFO: not as a massive bet on the future, but as a series of small, valuable improvements with clear before-and-after states.
Key Takeaways
- The strangler pattern lets you modernize while your system keeps making money. No big-bang cutover required.
- Start with a front door (proxy/gateway) that gives you control over routing.
- Pick extractable slices—low risk, clear boundaries, independent value.
- Build new services with comprehensive testing and monitoring before routing traffic.
- Each slice delivers value independently. You can stop anytime and still have gained something.
Questions to Ask Your Team
- If we could only modernize one part of our system this year, which would deliver the most value with the least risk?
- Do we have a “front door” that would let us route traffic between old and new components?
- What would it cost to extract our first slice, and what would we gain?
