Retire the core system everyone avoids changing, one function after another.
Years of business logic sit in mainframe COBOL and PL/I, in Oracle Forms screens and in early Java and .NET code. We would recover that logic, wrap it in tests that record how it behaves today, and move functions one by one behind a routing layer, comparing old and new results before any part is switched off.
For Indian banks, business groups and government departments whose core systems cannot afford downtime or lost business rules.
04Rebuild one function behind a routing layerSystem
05Run side by side and compareSystem
06Investigate differencesPerson
07Switch and decommissionPerson
The application landscape is assessed and a target agreed. Business logic is extracted from the code with AI support and confirmed by people. Tests that record current behaviour act as a safety net. Each function is rebuilt behind a routing layer and run alongside the old system; differences are investigated and fixed until the business owner signs off the switch and the old part is decommissioned.
Before and after
How the way you work changes
Today
With the system
Today
Today: Each amendment is a gamble
Even a small change asked for by a regulator takes months, because no one can predict what else in the code it will disturb.
With the system
With the system: Every change tested first
Tests that record how the system behaves today show the effect of each change before it reaches production.
Today
Today: Expertise close to retirement
The few developers who understand the code are nearing superannuation, and the documentation stopped describing the system years ago.
With the system
With the system: Logic documented and confirmed
Business logic recovered from the code is written up in plain English and confirmed by the people who know the domain.
Today
Today: One-shot replacements drift
Programmes that promise a single cut-over date keep moving that date, while the budget keeps growing.
With the system
With the system: Benefits delivered in stages
Functions move one at a time behind a routing layer. Each stage goes live by itself and can be reversed.
Today
Today: Data trapped in old formats
New digital services, analytics and AI use cases reach the data only through brittle extracts and overnight batch files.
With the system
With the system: Data reachable through APIs
Each migrated domain publishes its data through documented APIs and is compared with the old system until that system is retired.
Workflow
Step by step
We follow the strangler-fig pattern, in which new services gradually take over from the old system one function at a time. The loop between comparison and rebuild absorbs most of the effort.
Illustrative workflow
7 steps · 3 human checkpoints
Legend
System
AI agent
Person
Human checkpoint
Exception path
Legacy modernisation: illustrative path with a comparison loop
Read the diagram as text
The main line goes from assessing the landscape and recovering business logic, through recording current behaviour in tests and rebuilding one function behind a routing layer, to running both systems side by side, and finally to switching over and decommissioning the old part.
People decide at three points: approving the target architecture, confirming each recovered rule and signing off each switch.
If the side-by-side run shows different results, the stage leaves the main line for investigation by engineers and domain specialists and returns to the rebuild step until both systems agree.
01
Step 1: Assess the landscapePerson
Applications are inventoried, their dependencies and data flows mapped, and each one is given a decision: retire, retain, rehost, replatform, rebuild or replace. Mapping the business domains shows where the system can be divided into stages.
Human checkpoint
Your architecture review board approves the target architecture and the sequence of stages.
02
Step 2: Recover the business logicAI agent
Code-reading tools supported by AI go through the old programs, job streams and screens, and produce draft documentation, maps of which routine calls which, and a list of candidate business rules. Typical sources are early Java or .NET, Oracle Forms, PL/I, and COBOL with its JCL.
Human checkpoint
Engineers and domain specialists confirm every extracted rule before it serves as a specification; rules not yet confirmed carry a label saying so.
03
Step 3: Record today’s behaviourSystem
Anonymised inputs and outputs from production are turned into tests that pin down present behaviour, oddities included, before any code is touched.
04
Step 4: Rebuild one function behind a routing layerSystem
An API gateway or routing layer goes in ahead of the old system. A single function is then rewritten as a new service, its data moved across and kept in sync.
05
Step 5: Run side by side and compareSystem
The old and new paths process identical transactions. Results and data are compared automatically, and each difference is reported by rule and by record.
06
Step 6: Investigate differencesPerson
For each mismatch, engineers and domain specialists judge whether the new service is wrong, the old system was wrong all along, or the change is deliberate, and send the stage back for rework where needed.
Exception path: Results differ· Returns to step 4
07
Step 7: Switch and decommissionPerson
The routing layer sends the function’s traffic to the new service. After an agreed stable period, the old code path and its data are archived and decommissioned.
Human checkpoint
The business owner signs off each switch on the strength of the comparison results, and the routing layer keeps rollback available until decommissioning.
Components
Components we would deliver
01
Landscape and dependency map
An inventory of applications, interfaces and data flows, plus a domain model showing where the system can be split into stages.
Landing zone, CI/CD and observability for the new services in the cloud or data centre of your choice, with log retention and clock synchronisation set up as the CERT-In Directions require.
Salesforce as the new customer front endPlatformSalesforce
API gateway and integration middleware
Destination cloud or data centre
Controls
Controls built in
Access boundaries
The code is analysed inside infrastructure you govern; none of it is passed to a service you have not cleared. Test data drawn from production is anonymised while still inside the production zone.
Human review
Engineers and domain specialists confirm each recovered rule before anyone builds on it. The business owner signs off every switch based on the comparison results, and rollback remains possible.
Auditability
Every rule in the catalogue links back to the code it came from and to the person who confirmed it. Comparison reports are retained as evidence for each switch, which helps when an internal auditor or a regulator’s inspection team asks how a change was controlled.
Data protection
Migration follows a documented field mapping with record counts and checksums, and personal data in test sets is kept to the minimum. Retention rules travel with the data, and the security safeguards the DPDP Rules require from May 2027 cover migrated records as much as the old ones.
AI transparency
Where AI drafts documentation, tests or code, the output is labelled, reviewed and version-controlled like any other engineering work product.
Measures
How success would be measured
These are agreed during the assessment and reported for every stage, in addition to the programme totals.
How success would be measured
Metric
Why it matters
How we would measure it
01Time to release a change
Why it mattersThe clearest proof that changing the system is getting easier.
How we would measure itDays from an approved change request to production, compared between the old and the modernised parts.
02Comparison results
Why it mattersShows whether the new service matches the old one wherever it is meant to.
How we would measure itShare of transactions and records that agree during the side-by-side run, with open differences grouped by cause.
03Rule coverage
Why it mattersUndiscovered rules are the biggest risk in any replacement.
How we would measure itShare of recovered rules that domain specialists have confirmed and that tests cover.
04What has been switched off
Why it mattersModernisation only pays when old components are actually decommissioned.
How we would measure itPer stage, the functions, code paths, batch jobs and licences that have been retired.
No targets are set before a baseline exists.
Rollout
Phased rollout
Phase 01
Assessment
Landscape, dependencies, domains and risks. We pick a first stage that matters to the business but can still be reversed.
Exit criteria
Target architecture signed off
Order of stages agreed
Access to test data arranged
Phase 02
First stage
Logic recovery, behaviour tests, routing layer and one rebuilt function, run side by side with the old system.
Exit criteria
Comparison within the agreed tolerance
Business owner signs off the switch
Rollback rehearsed
Phase 03
Stage by stage
Further functions follow the same route, each with its own side-by-side run and switch decision.
Exit criteria
Every stage compared and switched
Knowledge handed to your team
Phase 04
Decommissioning
Old code paths, batch jobs and data stores are archived and then shut down for good.
Licensing, registration and scheme systems at State departments, where years of government orders are encoded in old code and amendments keep arriving.
In-house ERP and plant systems at business groups, moved in step with an SAP S/4HANA programme.
Illustrative example
Replacing a co-operative bank’s core, module by module
Situation
A co-operative bank runs deposits, loans and interest calculation on an ageing core system. Regulatory changes are queued, and two of the developers who know the code are close to superannuation.
System
Rules would be recovered and confirmed module by module. A routing layer would send interest calculation to a new service first, running alongside the old core until the results agree.
Human control
The bank’s domain specialists would confirm each recovered rule, and the business owner would sign off each switch; rollback through the routing layer would remain available.
What we would measure
Comparison results per module, the share of rules confirmed and covered by tests, and the time taken to release the next regulatory change.
India
Modernising under Indian and EU rules
Co-operative banks, NBFCs and insurers in India often run cores that predate today’s regulatory reporting, and every new RBI or SEBI requirement lands on that code. Business groups run in-house ERPs alongside SAP, and State departments keep licensing logic in systems built decades ago. We sequence modernisation so each function moves on its own and is compared against the old system before anything is switched off.
The new platform retains logs and synchronises clocks as the CERT-In Directions of 2022 require, and service contracts can reflect RBI’s directions on managing risks in outsourcing, including IT services. Where the core also serves European subsidiaries, NIS2 security duties can apply there through national law, and the switching rules of the Data Act favour portable data from the first stage. Personal data in mappings and test sets is handled as the DPDP Act and, for EU data, the GDPR require.
A single cut-over puts all of the risk on one weekend, and the business sees no benefit for years. Moving one function at a time lets each stage prove itself in a side-by-side run, go live by itself and be reversed if necessary.
02Can AI convert our COBOL into Java?
A line-by-line conversion tends to leave you with Java that is just as rigid as the COBOL it replaced. AI earns its place earlier: reading and documenting the old programs and drafting rules and tests, after which the new services are designed on their own merits. A person confirms every recovered rule before anyone relies on it.
03Our senior developers retire soon. How is their knowledge kept?
In working sessions where they go through the recovered rules and the behaviour tests. Their knowledge is captured in documentation and tests that remain with your team after we leave.
04Does this apply to an SAP ECC estate too?
Yes. The same approach suits custom code clean-up and a move to SAP S/4HANA: find out what is still used, recover and test what matters, and move in controlled stages.
05How long do the two systems run side by side?
Until the comparison results meet the tolerance the business owner has agreed, and long enough to cover periodic runs such as month-end, quarter-end and the closing of the financial year.
Name the system that slows you down and the processes that rely on it. We will suggest a first stage and a safe way to prove it, in India and in any European entity the system serves.