Engineering
Legacy modernization: incremental replacement or a full rewrite?
Prefer incremental replacement when the existing system must keep serving customers and you can isolate meaningful boundaries. Consider a full rewrite when the scope is genuinely bounded, the replacement contract is understood, and coexistence would be harder than a controlled cutover.
Neither option is automatically cheaper or safer. The decision should follow the business capability you need to improve, not the team's frustration with the current codebase.
1. Incremental replacement
The old system keeps handling what has not moved. New components take over selected responsibilities, often behind a façade that routes requests between the two. You can validate a smaller capability in production before you commit the next slice.
Incremental cons:
- Two systems mean two deployment paths, cross-system calls, and unclear data ownership
- The façade can become a bottleneck, and the old system can stay forever without an exit plan
Best for: large or important systems that must stay up and have boundaries you can intercept. Each slice needs a completion condition: which traffic moved, which dependencies remain, and what can actually be retired.
2. Full rewrite
A rewrite can fit a small, well-understood system, or a component whose boundaries make gradual replacement impractical. The destination can be simpler. The transition concentrates discovery and migration risk into one larger change.
Rewrite cons:
- Undocumented behavior can still be a requirement. A new system can match the happy path and fail on permissions, history, or rare exceptions
Best for: bounded functionality, explicit acceptance criteria, and a team that can keep the current service running while the replacement is finished. Unpleasant code is not, by itself, a reason to rewrite.
Make data ownership the central question
For either option, list who owns writes during the migration, how historical data moves, and how consistency will be checked. Do not treat dual writes as if they were one transaction. A failure can update one side and leave the other unchanged.
Map the important callers, outputs, access rules, background jobs, and external dependencies. Build tests around outcomes the business depends on. Changing a legacy behavior should be a deliberate operating decision.
Ask both proposals the same questions: how long must two systems coexist, who supports them, what proves correctness, how does cutover happen, and what makes reversal possible? My default is incremental modernization with explicit retirement milestones.
If you are deciding how to replace a system, tell me the business constraint, the data boundary, and what must keep working throughout the transition.
Message me