Rewrite is a funding decision, not a technical emotion
Legacy systems create frustration because every change feels expensive. That does not automatically make a rewrite rational. A rewrite trades known constraints for migration risk, feature parity work, data transition, cutover risk and a long period in which two realities may coexist.
Classify each component separately
| Disposition | Use when |
|---|---|
| Keep | Stable, low-change capability with acceptable operating cost. |
| Retire | Business capability is no longer needed. |
| Replace | Commodity capability is cheaper/safer to buy. |
| Rehost | Infrastructure move gives value without app redesign. |
| Replatform | Runtime/platform is the dominant constraint. |
| Refactor | Architecture debt is localized and business behavior is valuable. |
| Rearchitect | System boundaries or operating model are fundamentally wrong. |
Find the migration seam before the target architecture
A credible modernization plan identifies how old and new behavior coexist, how data moves, how parity is verified and how each wave can stop or roll back. The target architecture is only half the decision.
Use evidence to prioritize waves
Start where business value, change frequency and technical pain overlap. Avoid beginning with the most technically ugly component if it has little business leverage.
One migration wave, with a real stop condition
Fictional scenario: a team wants to replace an entire order platform because reporting releases are slow. Start by testing whether reporting can be separated without changing order writes. This narrows the first question to an observable seam rather than assuming the entire platform needs replacement.
| Wave | Required evidence | Stop condition |
|---|---|---|
| Read-only reporting shadow | Reconciliation of the agreed reports on representative records | Unexplained differences or unclear source of truth |
| Limited reader routing | Latency, correctness and a tested route back | Incorrect results or fallback overload |
| Retire the old reader | No remaining consumers, retention and recovery agreed | Unknown dependencies or missing recovery evidence |
Routing rollback does not automatically reverse a data migration. If a later wave changes writes, define data reconciliation and rollback feasibility separately. Treat irreversible transformations as explicit decision points.
What would justify a wider rewrite?
If no safe seam can be found, key behavior cannot be isolated, or a verified system constraint invalidates the current platform, compare wider options. Record the cost of feature parity, parallel operation and migration as well as new development. A failed first seam is evidence to investigate, not automatic proof that a full rewrite wins.
Source and interpretation
Martin Fowler's Strangler Fig description explains incremental replacement. The reporting scenario and stop conditions here are fictional SYSLUME analysis.