Test the case for a rewrite
Check whether the interfaces are stable, whether the team can run both systems at once and whether output can be validated continuously. If business rules are undocumented, a rewrite usually turns hidden complexity into expensive rework.
Price the hidden work
A rewrite carries work that is easy to leave out of the estimate: data migration, parallel running, integration changes, training and the period when both systems need support. Add those costs before comparing the options.
Compare capacity and continuity
A rewrite asks the team to build the new system while the old one still needs support. Compare the people, review capacity and operating knowledge available for both. If the team cannot run the two paths in parallel, an incremental change is usually safer even when the target architecture is more attractive.
- Who can support the current system during the build?
- Which interfaces can remain stable while internals change?
- How will outputs be compared during parallel running?
- What happens if the rewrite stops before cutover?
Choose the smallest reversible step
Prefer bounded replacement of one capability at a time until the evidence supports a larger change. A sequence of reversible steps gives the business useful improvements and keeps the option to stop or change direction.
Rewrite when the old design blocks the rules you must keep, not when delivery merely feels slow.