The Legacy Dilemma
Every company with more than 10 years of IT history knows the problem: a system that is business-critical but nobody wants to touch anymore. The documentation is incomplete, the original developers are gone, the technology is outdated — but the system runs and generates revenue.
The temptation: rebuild everything. The reality: 70% of all big-bang migrations fail or massively exceed budget and timeline.
Why Big-Bang Fails
1. Underestimated Scope
Legacy systems contain years of accumulated business logic that is documented nowhere. Only during the rebuild do you discover edge cases that the old system silently handled.
2. No Business Value During Migration
A rewrite delivers no new business value for months — while competitors roll out features.
3. All-or-Nothing Risk
If the go-live fails, there’s no going back — or falling back to the old system contradicts the new database structure.
The Strangler Fig Pattern
Principle
Instead of replacing the old system, you build new functionality alongside it and gradually redirect traffic:
- Identify — Which function should be modernized first?
- Implement — Build the new version of the function in modern architecture
- Redirect — Route traffic for this function from old to new system
- Verify — Compare behavior and data
- Decommission — Disable the old function in the legacy system
The Proxy as Key
A reverse proxy or API gateway sits between clients and both systems. It decides which requests go to the old system and which to the new one. This enables:
- Gradual migration — route by route
- Canary releases — 5% of traffic to the new system, then 10%, 50%, 100%
- Instant rollback — redirect traffic back if problems arise
Which Functions First?
The order determines success or failure:
Migrate first:
- Functions with high change frequency (where the legacy system slows you down most)
- Functions with clear interfaces (few dependencies to the rest)
- Functions with measurable business impact
Migrate last:
- Core functions with complex, undocumented business logic
- Functions with deep database integration
- Functions that are rarely changed (ROI of migration is low)
Data Migration
The biggest challenge is rarely the code but the data:
Shared Database (Short-term)
Old and new system use the same database. Simple but couples the systems.
Database per Service (Target State)
Each new service has its own database. Requires data synchronization.
Change Data Capture (CDC)
Changes in the old database are captured as events and propagated to new services. Tools: Debezium, AWS DMS, Striim.
Anti-Patterns
| Anti-Pattern | Consequence |
|---|---|
| ”Plan everything first, then build everything” | Back to big-bang |
| Feature parity as the goal | You rebuild the old system instead of improving it |
| No proxy/gateway | No way to gradually redirect traffic |
| Not maintaining the old system | The legacy system must remain stable during migration |
| Too many services at once | More than 2-3 parallel migrations overwhelm the team |
Timeline
Honest expectations:
| Company Size | Legacy Age | Typical Duration |
|---|---|---|
| 50-200 employees | 5-10 years | 12-18 months |
| 200-1,000 employees | 10-20 years | 18-36 months |
| 1,000+ employees | 15+ years | 24-48 months |
Conclusion
Legacy modernization is a marathon, not a sprint. The Strangler Fig Pattern gives you control: you decide what gets migrated when, can stop or change direction at any time, and continuously deliver business value. The alternative — “maintaining” the old system for yet another year — doesn’t get cheaper.