“Legacy” does not mean old. A system becomes a liability when it prevents safe change, creates unacceptable operational risk, or costs more to maintain than the value it supports.
A rewrite can be the correct decision, but it is not automatically the brave one.
Diagnose the constraint
Identify the business problem before selecting a technical strategy. Is delivery slow because the code is coupled, because requirements are unclear, or because releases require several approvals? Is downtime caused by the application, infrastructure, or a fragile external integration?
Measure change lead time, incident frequency, recovery time, infrastructure cost, and areas nobody feels safe editing. The diagnosis should point to a constraint, not simply produce a list of disliked technologies.
Know when not to rebuild
If the system is stable, rarely changes, and supports a predictable process, leaving it alone may be rational. Place a modern interface or integration layer around it if necessary and invest elsewhere.
Rewriting stable business rules can reintroduce years of solved edge cases. New code starts with fewer known defects partly because it has met fewer real situations.
Prefer incremental boundaries
When modernization is justified, isolate one capability behind a clear interface. Route new behavior to the replacement while the rest remains operational. This strangler approach creates checkpoints and allows rollback.
Good first boundaries have visible value, manageable dependencies, and enough traffic to prove the new operational model.
Treat data migration as a product
Inventory sources, ownership, identifiers, retention rules, and quality problems. Build repeatable migration scripts and reconciliation reports. Rehearse with production-shaped data and define how the team will handle records that cannot be mapped automatically.
The migration is not complete when rows move. It is complete when users and downstream systems can trust the result.
Create evidence before commitment
Add characterization tests around critical behavior, improve observability, and run a technical spike through the riskiest dependency. Compare the cost and risk of incremental modernization with a full rewrite using the same business outcomes.
Choose the smallest safe strategy
The right answer may be a rewrite, but it may also be replacing one module, moving infrastructure, improving deployment, or documenting a stable system.
Modernization succeeds when each step reduces risk while preserving business continuity. Architecture should create options, not force the company into one irreversible bet.