Legacy modernisation is the work of changing old business systems without stopping the business that runs on them. Start by naming the pain, because "the system is old" is a symptom. Then rank the systems, pick one of seven approaches for each, and move one capability at a time. This guide follows that order and links to a longer article for each step.
Step 1: name the pain
Write the pain in terms the business already feels:
- A report that takes a team two days to assemble by hand.
- A change request deferred for a year because nobody dares touch the code.
- A rule or an audit finding the system cannot satisfy.
- One person whose retirement would leave nobody able to change it.
Each line should end in a cost or a risk. Boards fund consequences, and a statement about age does not carry one.
Indian rules turn some old systems from a nuisance into a deadline: incident reporting and log keeping under the CERT-In Directions, and correction and deletion duties under the data protection rules. Security and IP for offshore engineering teams quotes the CERT-In text, and the DPDP Act and AI systems covers the data protection duties. A system that cannot produce logs or delete a record is a candidate for early work.
Step 2: rank the estate
An estate holds many systems and you cannot change them all at once. Score each on five questions about running cost, exposure, rule or audit risk, drag on change, and the importance of the process it serves. Start where heavy pain meets an important process. Leave cheap, stable systems alone. Replace or retire the painful ones that serve minor processes.
The scoring sheet, the four-box table and the common mistakes are in which legacy systems to modernise first.
Step 3: choose an approach for each system
Seven approaches exist. They answer different situations and most estates use several.
| Approach | What changes | Use when |
|---|---|---|
| Rehost | Same system, new hosting | The software is sound and the hardware or data centre is the problem |
| Replatform | Same design, newer runtime or database | The platform is out of support but the design works |
| Refactor | Code cleaned up in place | The behaviour is right and the code is hard to change |
| Rearchitect | Structure reworked, often into modules or services | The design blocks the change you need |
| Rebuild | New system written to the same purpose | The system is small, or the technology is beyond repair |
| Replace | Packaged product takes over | The process is standard and you do not compete on it |
| Encapsulate | Interface added in front, inside untouched | The system works and the problem is how others depend on it |
A frequent error is choosing an approach that costs more than the pain warrants, typically rebuild, because age passed for a reason. Test each system against the table starting from the top: rehost is cheaper than rebuild, so use it when it solves the pain. Legacy modernisation approaches compared gives the long version, and cloud migration for Indian companies covers rehosting and replatforming in detail.
Step 4: grow around the old core
The strangler pattern avoids the big rewrite. The new platform begins as a thin shell around the old system and absorbs one capability after another. An interface in front hides which system is answering a given call. The old system is not switched off on a date. It shrinks until switching it off is a small event.
Three rules keep this safe:
- Put the interface first. Before moving anything, publish a documented interface to the old system and route other systems through it.
- Move reads before writes. Reporting is the safest first capability.
- Keep every step reversible. Each move has a rollback plan and a stop point.
Escaping a legacy system without a rewrite shows the sequence. For platforms with a nightly batch, such as IBM i and mainframe systems, the India-focused article adds the batch-window and staffing checks.
Step 5: recover the rules
The old system is the only complete specification. Its code holds decades of decisions, while the documents record what someone intended long ago. A rewrite built from the documents runs correctly and still differs from the old system on cases nobody listed.
The remedy is a parallel run. Feed both systems the same live transactions, reconcile every record by program, explain each difference in writing and write a test for each finding. Finding the business rules nobody documented gives the log format and a sorting table. Do this early, because the people who know the reasons are the people closest to retirement.
Step 6: cut over in stages
Two sequences are possible: a single weekend, or overlapping systems with modules moving one at a time. Ask one question to decide: if the programme stopped at the halfway point, would the business have something worth keeping? Staged cutover passes that test, and a single weekend may not. Big bang or phased rollout sets out the trade-offs.
Data decides most schedules. Effort follows the condition of the master records, not the row count. Duplicate masters, mixed units and opening balances that never matched cause the delays. ERP data migration: where it goes wrong lists the checks.
Specific migrations
India-specific starting points have their own pages:
- Moving off Tally: the Tally migration page
- SAP ECC, whether to convert, replace or build around it: the SAP ECC page
- Business-critical spreadsheets: the spreadsheet migration page
- Hospital systems that do not share a patient record: the hospital systems page
Questions for the first steering meeting
Put these on the agenda before any work starts:
- Which systems are in scope, and which are explicitly out?
- Who owns each system on the business side?
- Which approach has been chosen for the first system, and why that one and not the cheaper option above it?
- What is the measure of success, with today's value written down?
- What is the first stopping point, and what will be usable by then?
- Who can approve a rule difference found in the parallel run?
- What is the evidence required to switch the old system off?
If a question has no answer, add it to the plan as a task with an owner and a date.
What to put in the contract
Modernisation contracts often fail on what happens at the edges. Ask for these in writing:
- Ownership. Code, documentation and tests in a repository under your company's name from day one. The same article explains why the assignment clause must state its term and territory.
- Audit rights. Regulated entities need audit and inspection rights over any provider; the Reserve Bank's outsourcing text is quoted in security and IP for offshore engineering teams.
- Stopping points. Each phase delivers something usable and can be the last.
- Evidence for switching off. The old system is retired when logs show nobody calls it, not on a calendar date.
Why projects fail early
Most of the damage occurs before building: an unclear problem, a plan with no stopping point, and no owner for the decisions. Why software projects fail before the code lists warning signs. If you want a senior outside view on sequencing and vendors, see CTO as a service.
The short version
Name the pain. Rank the estate. Pick the cheapest approach that removes the pain. Put an interface in front of the old core, then move a capability, then check it against the old system's output. Retire a system only when evidence shows it is unused.
Questions buyers ask
Which approach is cheapest?
Encapsulation, usually, since the inside does not change. Rehosting follows. Rebuild costs most, and it is often picked for the wrong reason.
How do we avoid a rewrite that never finishes?
Break the work into stages that each deliver something usable, and set a stopping point in the plan. A rewrite with no stopping point has no checkpoint at which it can be judged.
What if the people who know the system are leaving?
Start knowledge capture now. Pair a second person with each single-person area and begin the parallel-run log early.
Do we need to modernise everything?
No. Some systems can stay as they are until they fail, and some should be retired together with the process they served.
Where Brihat Infotech fits
Brihat Infotech's legacy modernisation service begins with an assessment and a dependency map, picks an approach per system, and moves capability by capability with behaviour tests and parallel-run evidence. Old systems are switched off only when the evidence supports it.