For most Indian companies running an AS/400 (now called IBM i) or a mainframe, the first step is a written, documented gateway in front of the system, with the code left alone. The machine is rarely the problem. The usual problem is that a small number of people can change it, and the rest of the estate talks to it through screens and file layouts. A gateway fixes the second problem at once and buys time for the first.
What these systems carry
IBM i and mainframe systems often sit under core banking, plant accounting, or order and dispatch in a distribution network. They run every night, and other systems assume the nightly run has finished by morning. IBM describes IBM i as an integrated application system that bundles its database, middleware, security and runtime in one licensed stack. Source: IBM i product page. That integration is one reason the systems last. It is also why they are hard to lift out piece by piece.
The real exposure is people
The risk is concentration, and you can measure it for your own estate in an afternoon. Ask four questions:
- How many people can change a program in this system and release it safely?
- How many of them are within five years of retirement?
- Which areas of the code does only one person understand?
- What is the longest period the system has gone without any change, and why?
If the answers are "one or two", "all of them" and "pricing, tax and month-end", you hold a risk with a retirement date on it. The system keeps running when they leave. The ability to change it goes, and you find out when a regulator sets a deadline or a new channel needs data the system holds.
Why replacement plans stall
Three features of these platforms make a rebuild harder than the budget assumes.
- The code is the specification. Decades of decisions sit in the programs, and the documents describe what someone intended long ago. A rebuild from the documents disagrees with the old system on cases nobody listed.
- It cannot stop. A one-weekend switch cannot be allowed to fail when the system sits under payments or plant operations.
- The batch window shapes everything. Downstream systems depend on overnight jobs finishing in order. Plans meet this late, and it forces redesign.
Step one: wrap it in an interface
Build a documented gateway and send every other system through it. IBM i exposes its data through its own database, and teams commonly wrap it in services that other systems call over the web. The wrapper needs its own design, so plan for it as a small project.
Nothing changes inside. Outside, four things change:
- New applications stop reading screens and fixed-format files.
- Each integration uses the same contract instead of a one-off feed.
- Reports can move to a separate store, which takes load off the core.
- A later decision about the platform no longer touches every other system.
One design rule matters. Give the core its own uptime target. Read through a staging layer, so a customer-facing page does not fail when the core is busy with its nightly run.
Step two: move one capability at a time
With the interface in place, you can use the strangler method: a new component takes over one function while the old one keeps serving the rest, and the interface hides which is which. A sensible order:
- Reporting. Reads are safe, and the saving is visible.
- A bounded workflow. One that has few links into the ledger.
- A module that owns its own data.
- The core. By then most of its surface has moved, and what remains is understood.
Run anything that touches the ledger in parallel with the old system, and reconcile every record by program. The log of explained differences is how you recover rules that exist nowhere else; recovering the rules nobody wrote down gives the format.
Step three: capture knowledge now
This step has a deadline. Talk to the operators, not only the programmers. Write a test for each behaviour you cannot explain. Record the reason beside each rule. Where one person holds a critical area, assign a second person to work with them now.
When replacement is the right call
Replace the platform when one of these holds:
- The business is redesigning the process, so copying today's behaviour is not the aim.
- The platform has lost vendor support, nobody can buy the hardware and nobody can compile the code.
- The scope is small enough to finish in months.
- A packaged product covers the function and you do not compete on it.
If none of these applies, the step-by-step route is the one that finishes. The order of systems, and what to leave alone, is covered in which legacy systems to modernise first. The seven approaches are compared in legacy modernisation approaches compared.
What an Indian regulated entity should add
For a bank, NBFC or insurer, outside parties working on the platform fall under the Reserve Bank's outsourcing rules, which include audit rights over the provider. Security and IP for offshore engineering teams quotes the text. Write those rights into the contract for any modernisation partner before work starts.
Questions buyers ask
Can an IBM i system feed a mobile app or a web portal?
Yes. Put an interface in front, read through a staging layer, and let the app call the interface. Avoid connecting the app straight to the production tables.
How long does the first step take?
A scoped interface for one domain, such as customer lookup or balances, is a short project compared with a replacement. Fix the scope by domain and agree the test of success before you start.
Do we need to retrain our own staff?
Keep your programmers engaged. They know the rules. Pair them with engineers building the new components so that knowledge moves across.
Is a mainframe different from IBM i for this purpose?
The method is the same: interface first, then capability by capability. Mainframes usually carry larger batch schedules, so map the job dependencies early.
Where Brihat Infotech fits
Brihat Infotech lists AS/400 among the legacy systems it integrates with in banking and financial services, and its legacy modernisation service covers interface preservation, strangler migration and parallel-run data migration. For the wider subject, see the legacy modernisation guide.