/01
Start with the cost of the problem
A system being old is not, by itself, a business case for replacing it. Document delays in shipping, avoidable incidents, support costs, security exposure and integration constraints. Confirm where the pain occurs and who experiences it. Establish a baseline before proposing new technology.
/02
Map dependencies and recovery
Identify components, data flows, external integrations and operational owners. Include backups, restore procedures and deployment paths. If a database change cannot be reversed, it deserves different handling from a cosmetic UI update. An incomplete dependency map is a reason to investigate, not a reason to guess.
/03
Choose the smallest reversible improvement
A useful first intervention may be a targeted dependency upgrade, an API around a fragile module, query optimization, automated checks or a safer deployment process. Define success criteria and a rollback approach. Measure the result before extending the change.
/04
Reserve rewrites for defensible cases
Some software genuinely needs replacement, for example when it cannot meet essential requirements or viable maintenance paths are exhausted. Compare that path with incremental alternatives, total operating cost, transition risk and the burden of running old and new systems simultaneously.