Walk into an Indian bank, a steel mill or a large distributor and there is a reasonable chance something important is running on an AS/400 — now IBM i — or a mainframe installed when the business was a different size.
It is worth saying plainly: these systems are not the problem people assume. They are extraordinarily reliable, they hold decades of correct business logic, and they process every day without drama. Plenty of them will outlast the projects proposed to replace them.
What has changed is not the machine. It is the number of people who understand it.
The actual risk
Not obsolescence. Concentration.
RPG and COBOL skills are scarce and becoming scarcer, and the market for them in India is thin outside a handful of employers. In most organisations running these platforms, one or two people can confidently make a change — and much of what the system does exists only in its code and in their memory.
The system will keep running when they leave. What disappears is the ability to change it, and that usually becomes apparent at the worst moment: a regulatory change with a deadline, a new channel that needs data the system holds, a defect nobody can safely locate.
Why replacement so often fails here
Three properties make these systems unusually hostile to rebuild:
- The specification is the system. Thirty years of decisions live in code, and the documentation describes an intent from the second year. Rebuilding from what is written produces something that works and disagrees with the incumbent on cases nobody predicted.
- It cannot stop. These platforms typically sit under core banking, plant operations or distribution. A single cutover has no acceptable failure mode.
- The batch window is load-bearing. Overnight processing that everything downstream assumes has completed by morning is a constraint that shapes any replacement, and it is routinely discovered late.
Encapsulate first
The highest-value first move is not to change the system at all.
Put a documented interface in front of it — modern IBM i supports SQL access to the underlying data and can expose services over HTTP, so this is usually less work than teams expect — and point everything else at that interface.
Nothing inside changes. What changes is substantial:
- New applications stop being written against green screens and file layouts.
- Integrations stop being bespoke each time.
- Reporting can move off the platform, relieving pressure without touching the core.
- Any future decision about the system becomes independent of everything downstream.
Design caution: treat the platform as a system with its own availability obligations. Read through a staging layer rather than letting a customer-facing screen depend directly on the core being up during batch.
Then, capability by capability
With the facade in place, the strangler sequence becomes available. Reporting first, because reads are safe. Then a bounded workflow. Then a module that owns its data. The core last, by which point most of the surface has moved and the remaining risk is understood rather than assumed.
Parallel-run anything touching the ledger, reconciling every record automatically. On systems this old the discrepancy log is where the value is — it recovers rules that exist nowhere else.
Capture the knowledge while you can
This is the part with a deadline attached, and it is the part most programmes treat as a side effect.
Interview the operators as well as the developers. Turn every unexplained behaviour into a test rather than a note. Record the reasoning next to the rule. Where a single person holds a critical area, pair someone with them now rather than after the resignation.
Modernisation is the last structured opportunity to do this, and it only happens if it has a name against it.
When replacement genuinely is right
- The business process is being deliberately redesigned, so parity is not the goal.
- The platform is at true end of life — no support, no hardware path, nobody who can compile it.
- The scope is genuinely small, and the whole replacement is months rather than years.
Where none of those hold, the incremental path is the one that finishes — and the first step on it costs far less than the business case usually assumes.