Modernization
COBOL, mainframe and IBM i: modernize without switching off what works
Core systems in COBOL or RPG are often the most reliable in the company and, at the same time, the hardest to change. Rewriting them is not always the right call: we measure first and then decide what gets documented, what gets opened through APIs and what gets migrated.
The problem
The risk is not the technology, it's the knowledge
Business rules have been piling up for decades in batch programs, copybooks and files, and the people who know them are retiring. Every change needs a specialist who is harder and harder to find, and the cost of running the system keeps growing.
How we do it
From the legacy core to data-driven decisions
Inventory of programs and data
Programs, copybooks, batch jobs, files and DB2 tables are inventoried and linked to each other.
Rules extracted into a specification
The behavior of each process is written down as a verifiable specification, with tests that check it.
APIs around the core
When rewriting is not yet worth it, the core is opened through APIs so new channels can use it without changing it.
Gradual migration
What does get migrated moves out module by module, with reversible switch-over and results compared against the core system.
We work with IBM as a technology partner.
Illustrative scenario
An insurer with its policy core in COBOL
Imagine a COBOL policy system on a mainframe, with nightly batch processes and a web portal that needs to query data online.
- The inventory identifies which programs and files are involved in policy inquiry and issuance.
- The calculation rules in those programs are documented as a specification with tests.
- An inquiry API is published on top of the current core, without modifying it, for the portal to use.
- With the specification in hand, you decide module by module what stays on the mainframe and what gets migrated.
Illustrative scenario: A hypothetical example to explain the method: it does not describe a client or a measured result.
What you keep
A documented core and a data-driven plan
An inventory, a rules specification and a wave plan that separates what is worth keeping from what is worth migrating.
Frequently asked questions
Do we have to leave the mainframe?
Not necessarily. It is often better to keep the core and modernize around it: documentation, APIs and new interfaces. The decision is made with the measured inventory.
Does it also apply to IBM i (AS/400) and RPG?
Yes, with the same method: an inventory of programs, files and tables, a rules specification and tests. The measured sample checks it on your system.
Do you have your own COBOL case?
We don't have a published own case in COBOL; our documented case is a migration from GeneXus. That is why we propose starting with a measured sample on your system.
Next step
Start with a measured sample: 5 to 10 screens of your system turned into a verifiable specification, with tests and an inventory of differences.