The Problem
A financial services client was running a core business platform on a 12-year-old monolith. The codebase had 800,000 lines of Python 2. Every deployment required a 6-hour maintenance window. A bug fix in one module could crash an unrelated module. The engineering team was spending 60% of their time on maintenance, 40% on features.
The business was growing. The platform couldn't keep up. A full rewrite was estimated at ₦800 million and 18 months of work.
We proposed a different approach.
The Strangler Fig Pattern
The strangler fig tree grows around an existing tree, gradually taking over until the original tree is fully replaced — often without the original tree ever knowing it's being replaced.
The strangler fig pattern in software engineering works the same way. You route traffic to a new system incrementally, while the legacy system continues to run. You never need a complete cutover. You never need a maintenance window.
The Migration Strategy
Phase 1: Router Layer (Weeks 1–4)
We placed an API gateway in front of the monolith. Initially, it passed all traffic straight through to the existing system. This gave us a control point for the migration without touching any application code.
Phase 2: Identify and Extract
We analysed the monolith to identify modules with clear boundaries, high change frequency, and independent scaling requirements. Four candidates emerged:
- Authentication service (highest change frequency, security-critical)
- Reporting service (CPU-intensive, needed separate scaling)
- Notification service (independently deployable, no database coupling)
- Document management (file-heavy, benefited from dedicated storage infrastructure)
Phase 3: Extract Services
For each service, the process was:
- Build the new service in isolation, with its own database
- Implement a sync mechanism to keep new and old databases in sync
- Route a small percentage of traffic to the new service (5%)
- Monitor for errors, performance regressions, data inconsistencies
- Gradually increase to 100%
- Remove the legacy code path
Each extraction took 3–6 weeks. All four were completed in 5 months, in parallel across two teams.
Phase 4: Remaining Monolith
After extraction, the remaining monolith was smaller, more focused, and more maintainable. Some modules remain in the monolith — and will stay there. Microservices are not a goal. They're a tool. Not everything benefits from extraction.
Results
- Zero downtime during the entire migration
- Deployment frequency increased from monthly (6-hour windows) to daily (blue-green, zero downtime)
- Mean time to recovery for incidents: 4 hours → 22 minutes
- Infrastructure cost: reduced by 30% through right-sized services
- Engineering velocity: feature delivery time halved within 6 months
The projected cost of the full rewrite was ₦800M over 18 months. The actual cost of the strangler fig migration was approximately ₦180M over 5 months.
When Not to Use Microservices
This approach is not appropriate for every situation. A startup with 10,000 users and a 2-person engineering team should not be building microservices. The operational overhead — service discovery, distributed tracing, inter-service authentication, network latency — will consume engineering capacity that should be spent on product.
Microservices are an enterprise tool, appropriate when the complexity of the monolith exceeds the complexity of distribution.
