The riskiest sentence in enterprise IT is we will rewrite it from scratch. The second riskiest is the system is old, treated as a diagnosis rather than a symptom.
This is the map. Each section links to the piece that goes into it properly.
1. Name the pain before choosing an approach
Seven options exist — rehost, replatform, refactor, rearchitect, rebuild, replace, encapsulate — and several of them are cheap. The most common mistake is choosing one more expensive than the pain justifies, usually rebuild, usually because age got mistaken for a reason.
→ The seven legacy modernisation approaches, compared
2. Sequence the estate
A large estate cannot be modernised at once and does not need to be. Score each system on cost, security exposure, regulatory risk, change velocity and strategic importance — then start where high pain meets high importance, and genuinely leave the cheap, stable, unimportant systems alone.
→ Which legacy systems to modernise first
3. Grow around rather than replace
The strangler pattern inverts the rewrite: the new platform starts as a thin layer around the legacy core and absorbs one capability at a time, each behind an interface that hides which system is serving it. The legacy system is not switched off — it is hollowed out until switching it off is an anticlimax.
→ Escaping a legacy system without betting the company on a rewrite
4. Sequencing the cutover
One weekend or overlapping systems for a year. The test that settles it: if the programme stopped at sixty per cent, would the organisation have something it could keep?
→ Big bang or phased: sequencing a system replacement
5. Recover the rules before the people leave
The specification is the system. Thirty years of decisions live in code, and the documentation describes an intent from year two. A parallel run reconciling every record is the reliable instrument — and the log of explained discrepancies is the specification you never had.
→ Recovering the rules nobody wrote down
6. Migration is decided by the master data
Effort tracks data quality, not record count. Duplicate masters, units that do not reconcile, opening stock that has never matched — these decide the timeline, and they are cheap to measure before anyone quotes.
→ ERP data migration: the master data decides the timeline
7. The platforms that are genuinely hard
AS/400 and mainframe systems still run banks, mills and distribution networks in India. The risk is not obsolescence but concentration — the skills are scarce and the logic exists in code and in one or two people's memory. Encapsulation is almost always the right first move.
→ AS/400 and mainframe modernisation in India
8. The specific migrations
→ Tally to a custom ERP · SAP ECC: convert, replace or build around · Replacing business-critical spreadsheets · Legacy HIS replacement
The one-paragraph version
Name the pain rather than the vintage. Encapsulate first, because it changes nothing inside and makes every later decision independent. Move capability by capability behind a stable interface so the work can be stopped at any point and still be worth something. Parallel-run anything touching the ledger, and write down every discrepancy — because a rewrite cancelled at eighty per cent is worth nothing at all.