Replace the system everyone is afraid to change, a piece at a time.
Years of policy and business logic sit inside COBOL, PL/I, Oracle Forms and early Java or .NET. We bring those rules to the surface, put a test harness around them and move one function after another behind a façade, running old and new together and reconciling the results before any part is turned off.
For Irish public bodies, insurers and manufacturers whose critical systems cannot afford downtime or lost rules.
We review the application estate and agree the target. AI helps draw the business rules out of the code, and people confirm them. Tests that record today’s behaviour act as a safety net. Each function is rebuilt behind a façade and runs alongside the old system; differences are investigated and fixed before the business owner signs off the switch and the old part is decommissioned.
Before and after
How your way of working changes
Today
With the system
Today
Today: Any change could break something
Even a minor change after a new Statutory Instrument drags on for months, since no one can tell what else it might disturb.
With the system
With the system: Tests behind each change
Tests capture how the system behaves now, so the effect of any change is visible before it is released.
Today
Today: The experts are leaving
The few people who know the code are near retirement, and the documents describing it went out of date years ago.
With the system
With the system: Rules on paper and confirmed
Rules drawn out of the code are described in plain English and checked by the people who know the subject.
Today
Today: The big switch never comes
Programmes to replace everything at once name a go-live date that keeps slipping while the budget keeps rising.
With the system
With the system: Benefits arrive in stages
Functions move across one by one behind a façade. Each goes live separately and can be reversed.
Today
Today: Data trapped in old formats
New online services and AI projects can only get at the data through brittle exports and nightly batch runs.
With the system
With the system: Data reachable over APIs
Each migrated area offers its data through documented APIs and is reconciled against the old system until that system is gone.
Workflow
The workflow, step by step
This is the strangler-fig pattern: the new system grows up around the old one, function by function. Most of the hard work happens in the loop between running both systems and rebuilding.
Illustrative workflow
7 steps · 3 human checkpoints
Legend
System
AI agent
Person
Human checkpoint
Exception path
Legacy modernisation: illustrative workflow and reconciliation loop
Read the diagram as text
The usual route goes from reviewing the estate and drawing out the rules, through building a test safety net and rebuilding one function behind a façade, to running both systems together and then switching over and decommissioning the old part.
People approve the target architecture, confirm every rule drawn out of the code and sign off each switch: these are the points where a person steps in.
If running both systems shows different results, the section is taken off the usual route so engineers and subject experts can investigate, and it goes back to the rebuild step until the two systems agree.
01
Step 1: Review the estatePerson
An inventory of applications, a map of dependencies and data flows, and a call on each application: retire, retain, rehost, replatform, rebuild or replace. Mapping the domains shows where the system can be divided.
Human checkpoint
The target architecture and the sequence of sections are signed off by your architecture board.
02
Step 2: Draw out the rulesAI agent
AI-supported code analysis reads COBOL, PL/I, JCL, Oracle Forms and older Java or .NET, and produces draft documentation, call graphs and a catalogue of the business rules it finds.
Human checkpoint
Every rule found is checked by engineers and subject experts before anyone builds from it. A rule nobody has confirmed is labelled as unconfirmed.
03
Step 3: Put the safety net in placeSystem
Tests are generated from anonymised live inputs and outputs, so today’s behaviour, oddities and all, is recorded before any change is made.
04
Step 4: Rebuild one section behind a façadeSystem
A routing façade or API layer goes in front of the old system. One function is rebuilt as a new service, and its data is migrated and kept synchronised.
05
Step 5: Run both and reconcileSystem
The old and new systems handle the same transactions. Results and data are compared automatically, and each difference is reported by rule and by record.
06
Step 6: Investigate differencesPerson
Engineers and subject experts decide if a difference is a fault in the new service, a fault in the old one or a deliberate change, and return the section for further work.
Exception path: Results differ· Returns to step 4
07
Step 7: Switch and decommissionPerson
The façade sends traffic for that function to the new service. Once it has run steadily for a while, the old code path and its data are archived and decommissioned.
Human checkpoint
Each switch is approved by the business owner based on the reconciliation results. Until decommissioning, the façade can still send traffic back to the old system.
Components
What we would put in place
01
Estate and dependency map
An inventory, a map of interfaces and data flows, and a domain model showing where the system can be split into sections.
A landing zone, CI/CD and monitoring for the new services, in an EU cloud region or the data centre you choose, in line with a cloud-first policy where one applies.
Salesforce as the new front officePlatformSalesforce
API gateway and integration platform
The target cloud region or data centre
Controls
Safeguards built in
Access boundaries
Code is analysed in an environment under your control, and no source code goes to a service you have not approved. Live data used for testing is anonymised before it leaves the production environment.
Human review
Engineers and subject experts confirm the rules drawn from the code before they become a specification. The business owner approves each switch based on the reconciliation results, and the switch can be reversed.
Auditability
Every rule in the catalogue links back to the code it came from and to the person who confirmed it. Reconciliation reports are kept as the evidence for each switch.
Data protection
Migration follows a written mapping with record counts and checksums, and test sets hold as little personal data as possible. Retention rules travel with the data, in line with the GDPR and the Data Protection Act 2018.
AI transparency
Documentation or code drafted with AI is labelled, reviewed and kept under version control like every other piece of engineering work.
Measures
How we would judge it
We set these measures with you during the review and follow them for every section, not only across the programme.
How we would judge it
Metric
Why it matters
How we would measure it
01Time to make a change
Why it mattersThe best sign that the system is getting easier to change.
How we would measure itTime from an approved change request to production, compared between old and modernised parts.
02Reconciliation results
Why it mattersShows if the new service truly behaves like the old one wherever it is meant to.
How we would measure itProportion of transactions and records that agree while both systems run, with open differences grouped by cause.
03Rules confirmed and tested
Why it mattersRules no one knows about are the biggest danger in any replacement.
How we would measure itProportion of rules drawn from the code that subject experts have confirmed and tests cover.
04What is left of the old system
Why it mattersModernisation only pays off once old parts are really turned off.
How we would measure itFunctions, code paths, batch jobs and licences decommissioned, followed section by section.
No targets are set before a baseline exists.
Rollout
How we would introduce it
Phase 01
Review
Estate, dependencies, domains and risks. We pick a first section that matters to the business yet can be reversed.
Exit criteria
Target architecture signed off
Order of sections settled
Access to test data organised
Phase 02
First section
Rules drawn out, safety net built, façade in place and one function rebuilt, running alongside the old system.
Exit criteria
Results agree within the set tolerance
Switch signed off by the business owner
Rollback rehearsed
Phase 03
One section after another
Other functions take the same route, each with its own period of running both and its own switch decision.
Exit criteria
Every section reconciled and switched
Your team has the know-how
Phase 04
Decommissioning
Old code paths, batch jobs and data stores are archived and turned off.
Grant, licensing and registration systems at State agencies and local authorities, where Acts and Statutory Instruments are coded into old software and amendments keep arriving.
In-house ERP add-ons and site systems at pharma, medtech and electronics manufacturers, moved during an SAP S/4HANA migration.
Illustrative example
A grant-payments system at a State agency
Situation
A State agency pays several grant schemes from an Oracle Forms system built over two decades. Every scheme change waits months for a release, and two of the developers who understand the payment rules are due to retire.
System
Rules are drawn out of the code and confirmed scheme by scheme. A façade sends one scheme’s payment calculations to a new service first, which runs alongside the old system until the figures agree.
Human control
Scheme managers confirm the rules for their scheme. The business owner signs off each switch, and the façade can send payments back to the old system until it is decommissioned.
What we would measure
Reconciliation results per scheme, the share of rules confirmed and tested, and the time needed for the next scheme change.
Ireland
New platforms while Irish cyber law is in transition
As of autumn 2026, Ireland has not yet transposed NIS2: the General Scheme of the National Cyber Security Bill was published in August 2024 and drafting continues, while S.I. No. 360 of 2018 stays in force until the new Act. The NCSC, planned as lead authority, has published draft risk-management guidance. We design each new platform with that draft guidance in mind, so the Act does not catch you out when it comes.
For public bodies, Connecting Government 2030 sets cloud-first and secure by design as principles, which suits replacing an old system in stages. The EU Data Act’s switching rules are another reason to keep data portable from the first section, and migration mappings and test data that touch personal data follow the GDPR.
A single go-live puts all the risk on one day, and the organisation waits years to see any return. Moving one function at a time lets each section prove itself while both systems run, go live separately and be reversed if it has to be.
02Could AI simply convert our COBOL to Java?
Converting line by line usually gives you code just as hard to change as before. We use AI to read and document the old code and to draft rules and tests, and then design the new services properly. People confirm every rule before it is used.
03The people who know the system are retiring. How do we keep what they know?
In structured sessions where they review the rules drawn from the code and the tests of today’s behaviour. What they know ends up in documentation and tests that your team keeps, rather than in our consultants’ memory.
04Does the same approach work for SAP ECC?
It does. Cleaning up custom code and moving to SAP S/4HANA follow the same logic: find out what is still used, draw out and test what matters, and move in controlled stages.
05How long do both systems run together?
Until the reconciliation results are within the tolerance the business owner agreed, and for long enough to include periodic runs such as month-end or year-end processing.