The platforms my teams built support operations contributing more than ₹1,000 crore in revenue. None of them got a big-bang rewrite. Every upgrade happened while the businesses running on them kept trading.
A rewrite looks clean on a whiteboard. In production it means two systems, one frozen, and a cut-over weekend nobody can rehearse. Here's what works instead.
1. Strangle, don't replace
Martin Fowler's strangler fig pattern moves behaviour from the legacy system into new code a piece at a time, instead of replacing it in one go (Fowler, 2024). Put a routing layer in front, send one screen or one API to the new code, and grow from there.
2. Change data in three steps
Schema changes break live systems more often than code does. Parallel change splits a breaking change into expand, migrate and contract (Sato, 2014): add the new column, move readers and writers across, then drop the old one. Every step is reversible on its own.
3. Ship dark, switch on later
Feature toggles let a team change system behaviour without deploying new code (Hodgson, 2017). Deploy on Tuesday, switch on for one branch on Thursday, roll back with a click. Remove each toggle once it has done its job, or they become debt.
4. Protect the revenue path first
Map the few flows that move money, such as orders, invoices and payouts. In my experience, those deserve the most tests, the slowest rollout and someone awake when they change. Reports and admin screens can move fast.
| Change | Technique | Rollback |
|---|---|---|
| Replace a module | Strangler fig | Route back to legacy |
| Rename or split a column | Expand, migrate, contract | Stop before contract |
| New behaviour, same screen | Feature toggle | Switch it off |
Is your system ready to change safely?
Score each 0 (no), 1 (partly) or 2 (yes):
- Routing: you can send one path to new code without touching the rest.
- Schema: breaking changes go through expand and contract.
- Toggles: new behaviour ships switched off, with an owner.
- Revenue map: money-moving flows are listed and tested.
- Rollback: every release can be undone in minutes.
| Score | Next move |
|---|---|
| 8–10 | Start strangling the riskiest module. |
| 5–7 | Build rollback and the revenue map before big changes. |
| 0–4 | No refactors yet. Add tests around revenue flows first. |
Your next step
Pick the legacy module your team fears most. Write down the one route that would let you send ten percent of its traffic to new code. That route is your first sprint.
Sources
- Fowler (2024). Strangler Fig. Martin Fowler, updated 22 August 2024.
- Sato (2014). Parallel Change. Danilo Sato, 13 May 2014.
- Hodgson (2017). Feature Toggles (aka Feature Flags). Pete Hodgson, 9 October 2017.