540
changes a three-year rewrite must chase
If legacy ships 15 changes a month (illustrative), a 36-month rewrite must absorb 15 × 36 = 540, or freeze the business. Then it all rides on one cutover weekend.
One façade, one route at a time
First release: 100% to legacy, just a new hop. Then move one capability’s route to new code, behind a flag that flips back in seconds.
Legacy says WL/017. Your new code should never see it.
An anti-corruption layer translates at the border, both ways, in one place. Unknown codes fail loudly there, not as silent guesses elsewhere.
Refunds are mid-move. Who writes?
Bad: Both accept writes
Legacy cancels, new approves; the last sync silently wins.
Good: One writer at a time
Legacy owns, CDC copies. At the flip, new owns; a back-sync copies back.
Legacy behaviour was never written down. How do you prove the new path matches?
Parallel run
Run both on sampled real traffic. Users get legacy’s answer; mismatches get logged. Some are legacy bugs.
What do you carve first?
- Read-only first: a wrong search costs a retry
- Busy but low-stakes: search, 70% of requests
- A thin slice through façade, ACL and sync
- Core last: seat allocation or the ledger
90% of traffic is on new. The mainframe bill hasn’t moved.
Measure progress in deletion: legacy code, tables and jobs gone. Stop at 70% and you run two systems, two on-calls, two bills, indefinitely.
The interview line
Strangle, don’t rewrite: a façade moves one capability at a time, an ACL translates, and every step stays reversible.