Legacy modernization projects fail for a predictable reason: teams commit to replacing an entire system at once, spend a year building the replacement, and discover on launch day that it's missing behavior nobody documented — because it only existed as institutional knowledge about how the old system actually worked.
Why full rewrites are riskier than they look
A legacy system, however ugly its code, encodes years of accumulated business rules and edge cases — many of which were never written down anywhere except in the system's actual behavior. A rewrite has to rediscover all of that, usually under time pressure, usually while the business keeps changing requirements on the old system in parallel.
The incremental alternative: the strangler fig pattern
Named after a vine that grows around a host tree and gradually replaces it, this pattern means routing traffic for one specific piece of functionality to a new system while the legacy system continues handling everything else — then gradually expanding what the new system covers until the old one can be retired.
In practice this looks like:
- Identify one well-bounded piece of functionality — often the part causing the most pain, like a specific reporting module or an API integration.
- Build the replacement for just that piece, running alongside the legacy system.
- Route traffic to the new implementation, with the ability to roll back if something's wrong.
- Repeat for the next piece, expanding the new system's footprint over time.
This means the business keeps running throughout, each migrated piece is independently testable and reversible, and you discover undocumented behavior in small pieces instead of all at once at the end of a year-long project.
When a full rewrite actually makes sense
Incremental migration isn't always the right call. A full rewrite is justified when the underlying platform is genuinely unsupportable — end-of-life technology with no security patches, a database that fundamentally can't be extended to meet new requirements — or when the system is small enough that incremental migration adds more coordination overhead than it saves.
What makes incremental migration hard
Data consistency across two systems
During the transition, both systems may need to read and write the same data. This requires careful thought about which system is the source of truth for what, and how changes sync between them without creating conflicts.
Identifying true boundaries
Legacy systems built without clear module boundaries make it hard to find a piece that can be extracted cleanly. Sometimes the first real work of modernization is untangling those boundaries within the legacy system before extracting anything.
Organizational patience
Incremental migration takes visible discipline — it's slower to show a "finished" result than a rewrite roadmap promises, even though it's usually faster to reach a genuinely stable outcome. Stakeholders need to understand this trade-off upfront.
Common mistakes
- Migrating the easiest piece first instead of the highest-value piece. Early wins that don't reduce real pain don't build the organizational confidence needed to sustain the project.
- No rollback plan per migrated piece. Every migration step should be reversible independently — if it isn't, you've just built a smaller version of the all-or-nothing rewrite risk.
- Underestimating undocumented business logic. Budget real time for discovering behavior that only exists in the old system, not just the time to build the replacement.
Recommended approach
Default to incremental migration using the strangler fig pattern unless there's a specific, concrete technical reason it won't work (unsupportable platform, system too small to benefit). Start with the piece causing the most operational pain, not the easiest piece to build. Build in rollback capability at every step.
Conclusion
Modernization isn't a single decision between "keep the old system" and "replace everything." It's a series of smaller, reversible decisions about which pieces to replace first — and that's what actually reduces risk, not the size of the rewrite you're brave enough to attempt.
Kiaanlab modernizes legacy systems incrementally — replacing what's actually broken, not forcing a risky rewrite you didn't ask for. Tell us what's holding your system back and we'll help you find the highest-value starting point.