Start with the system that scores high on both pain and importance. Pain is what it costs you today. Importance is how much of your advantage runs through it. Age is not a score: a twenty-year-old ledger that is cheap, stable and patched can wait, while a six-year-old integration that nobody can change may not.
A large estate holds dozens of systems. You cannot touch them all at once, and you do not need to. The work is to rank them, give each a different action, and fund the first one on a case the business already feels.
Five questions that produce the score
Score each system from 1 to 5 on the first four questions, and add them for a pain score. The fifth question gives the importance score.
| # | Question | What to count |
|---|---|---|
| 1 | What does it cost to keep running? | Licences, hosting, the support contract, and the engineering days spent keeping it alive |
| 2 | How exposed is it? | Unpatched runtime, hardware you cannot replace, one person who understands it |
| 3 | What rule or audit does it put at risk? | Personal data it cannot correct or delete, reports a regulator reads, missing audit trail |
| 4 | How much does it slow change? | Requests shelved because nobody dared change the code |
| 5 | How much of your advantage runs through it? | Pricing, credit, production planning versus payroll or general ledger |
Two notes on scoring.
Question 2 can override the rest. A platform that no longer receives security updates and holds customer data is a risk with a date on it. Move it up whatever else it scores.
Question 4 is the score teams skip. Ask the operations and product leads what they gave up: the report they stopped asking for, the pricing change they shelved. Write the list down. It is usually the strongest part of the case.
What to do with each result
Plot the pain score against importance. Each quadrant gets a different action.
| Pain against importance | Important process | Minor process |
|---|---|---|
| Heavy pain | Modernise first. The saving or the risk removed funds the work. | Replace with a packaged product, or retire it. |
| Light pain | Put an interface in front of it so nothing depends on its internals. Review each year. | Leave it alone. |
The lower-right box is where budgets leak. A system that is cheap, stable and unimportant is not a problem. Replacing it because it is old moves money and delivers nothing the business can see.
Retire before you replace
Every estate review turns up systems that serve a process nobody runs any more. A report with no readers. An integration to a partner you stopped trading with. A module for a product the firm stopped selling.
Find out which process each system serves before you pick a successor. Switching a system off after you have checked who reads its output costs less than any other option on the list. It rarely makes the first list because nobody owns it.
Check before you switch off. Read the logs for the last quarter, list who or what calls the system, and keep a backup for the period your auditor or tax authority may ask for records.
Put an interface in front first
The cheapest first step on most systems changes nothing inside them. You publish an interface with written documentation, and every other system calls that.
Inside, the old code runs as before. Outside, new applications stop depending on screen layouts and file formats, each integration stops being a one-off, and a later decision to replace the system no longer touches anything else. The seven options for each system, and when each one fits, are laid out in legacy modernisation approaches compared.
Build the case in the cost of the pain
A board funds consequences. "The platform is out of support" is a fact, and "we cannot delete a customer's record on request" is a case. A system built before correction and deletion rights existed may not be able to honour them under India's data protection rules, and that gap is a legal reason to act. The duties and penalties are set out in the DPDP Act and AI systems, and the legacy modernisation guide lists the other rules that make old systems urgent.
Turn each criterion into a line the finance lead can read:
- The yearly cost of the workarounds the system forces.
- The change the business requested and never received.
- The audit finding, or the rule the system cannot meet.
- The date the only engineer who knows it retires.
That last line persuades more readers than any other, and it is the one teams skip.
Four mistakes in scoring
- Scoring by age. Age correlates weakly with pain. Score the evidence in each row instead.
- Letting the vendor score. A supplier selling the replacement will rate the old system high. Score internally, then share the sheet.
- Averaging across systems. A single high score on exposure matters more than five middling ones elsewhere. Read the rows, not the totals.
- Skipping the owner. A system with no business owner scores low on importance by default. Find the owner before you accept the score.
A scoring sheet you can copy
One row per system, one line of evidence per score. Keep it to a page.
- System name and the process it supports.
- Owner on the business side, and the person who can change it.
- Scores 1 to 5 for cost, exposure, regulatory risk and change friction.
- Importance score, with the process it supports named.
- Action from the table: modernise, replace or retire, interface, or leave.
- The evidence behind the highest score.
Review the sheet each quarter. A system moves when its supplier drops support, a rule changes, or the business changes direction.
Questions buyers ask
How many systems should the first phase cover?
One or two. A first phase that touches six systems has no single owner and no single result to report. Pick the highest-scoring system, finish it, and let the result fund the next.
Who should fill in the scoring sheet?
The business owner of the process scores importance and change friction. Engineering scores exposure and running cost. Finance checks the cost lines. Compliance scores regulatory risk. Scores made by one team alone tend to rank that team's own systems high.
What if two systems tie?
Take the one with the stronger regulatory or security score, because that risk has a date. If both are equal, take the one with fewer dependants, since it is quicker to finish and proves the method.
Where Brihat Infotech fits
Brihat Infotech's legacy modernisation work starts with an assessment of each system and a dependency map across the estate. The plan then moves one capability at a time, and each step can stop without leaving the estate half-built. For the whole subject in one place, see the legacy modernisation guide.