Renew the core system that nobody in the building wants to touch, piece by piece.
A generation of rules is hidden inside COBOL, PL/I, Oracle Forms and first-wave Java or .NET applications. We recover that logic, wrap the system in regression tests and shift it across in small pieces behind a façade, with old and new processing the same work until they agree and only then retiring anything.
For Government departments, MFSA licence holders and family businesses in Malta that cannot risk downtime or the loss of rules hidden in old code.
We start by surveying the applications and settling the target. AI helps read the code and draft its business rules, which people then confirm. Regression tests capture today’s behaviour and serve as a safety net. Piece by piece, functions are rebuilt behind a façade and process the same work as the old system; mismatches are investigated and resolved before the business owner signs the switch and that piece of the old system is retired.
Before and after
What shifts in day-to-day work
Today
With the system
Today
Today: Each change feels dangerous
A small amendment prompted by a new Legal Notice or an MFSA circular can drag on for months, because nobody can foresee what else it might disturb.
With the system
With the system: Tests behind every change
Regression tests fix today’s behaviour in place, so the impact of a change is visible before it ships.
Today
Today: Know-how about to leave
The few people who understand the code are nearing retirement, and the documentation stopped describing the real system years ago.
With the system
With the system: Rules documented and signed off
The logic recovered from the code is set out in plain English and signed off by the colleagues who run that part of the business.
Today
Today: All-at-once replacements slip
Programmes that replace everything at once announce a switch-over weekend that is postponed again and again while costs rise.
With the system
With the system: Value delivered in pieces
Behind a façade, functions are moved over in small pieces. Each piece is switched on independently and can be switched back.
Today
Today: Data locked inside old structures
Fresh digital services and AI ideas can only get at the data through fragile file extracts and overnight jobs.
With the system
With the system: Data reachable through APIs
Every renewed area publishes its data through documented APIs, reconciled with the legacy system for as long as that system stays in use.
Workflow
The workflow, step by step
We apply the strangler-fig pattern, in which the new system gradually wraps around the legacy one. In practice the hardest work happens in the loop between the parallel run and the rebuild.
Illustrative workflow
7 steps · 3 human checkpoints
Legend
System
AI agent
Person
Human checkpoint
Exception path
Legacy modernisation with its comparison loop (illustrative)
Read the diagram as text
The main route opens with surveying the applications and recovering the rules, adds a regression safety net and the rebuild of one piece behind a façade, lets old and new process the same work, and closes with the switch and the retirement of the legacy piece.
People approve the target architecture, confirm each rule found and agree to every switch: these are the points where a person decides.
When the parallel run produces mismatches, the piece is taken off the main route for engineers and subject-matter experts to investigate, and goes back to the rebuild step until old and new agree.
01
Step 1: Review the application landscapePerson
Applications are listed, dependencies and data flows charted, and each application gets a verdict: retire, keep, rehost, replatform, rebuild or replace. A domain map shows the natural seams along which the system can be cut into pieces.
Human checkpoint
Your architecture board signs off the target architecture and the order in which pieces will move.
02
Step 2: Bring the business rules to lightAI agent
With AI assistance we read COBOL, PL/I, JCL, Oracle Forms and early Java or .NET code and draft the documentation, the call graphs and a catalogue of business rules.
Human checkpoint
Engineers and subject-matter experts check each rule found before it serves as a specification. Rules nobody has checked are labelled as unconfirmed.
03
Step 3: Build the regression safety netSystem
Regression tests are generated from production inputs and outputs after anonymisation, capturing what the system does today, quirks and all, before a single line is altered.
04
Step 4: Rebuild a piece behind a façadeSystem
A façade, either a router or an API layer, is placed between users and the old system. Behind it one function is written again as a new service, and its data is moved over and kept in step.
05
Step 5: Parallel run and comparisonSystem
Old and new receive identical transactions. Their outputs and stored data are matched by software, and every mismatch is listed against the rule and the record concerned.
06
Step 6: Investigate each mismatchPerson
Engineers and subject-matter experts decide for every mismatch whether the new service is wrong, the old system was wrong all along, or the change was intended, and send the piece back for rework where necessary.
Exception path: Results do not match· Returns to step 4
07
Step 7: Switch across and close downPerson
Through the façade, requests for that function now reach the new service. After a settled period, the legacy code path and its data are archived and retired.
Human checkpoint
Each switch needs the business owner’s signature, based on the comparison results. Until retirement, the façade can send traffic back to the old path.
Components
The building blocks
01
Application and dependency map
An inventory of applications, interfaces and data flows, plus a domain model that marks the seams for cutting the system into pieces.
Salesforce for a new front officePlatformSalesforce
Integration platform and API gateway
Chosen cloud or data centre
Controls
Controls built in from the start
Access boundaries
The code analysis runs inside an environment you govern; source code is never passed to a service you have not approved. Production data destined for tests is anonymised while it is still inside the production zone.
Human review
Engineers and subject-matter experts confirm the rules found before they become specifications. The business owner agrees to each switch on the strength of the comparison results, and a way back remains open.
Auditability
Each rule in the catalogue links back to its origin in the code and to whoever signed it off. The comparison reports behind every switch are retained, which helps when the MFSA or your internal audit asks how a change was controlled.
Data protection
Data moves according to a documented field mapping, verified with record counts and checksums. Test sets are kept lean on personal data, and the retention rules move across together with the records.
AI transparency
Any documentation or code that AI helped to draft is marked, reviewed and version-controlled in the same way as all other engineering work.
Measures
Indicators we would track
These indicators are agreed with you while we survey the applications, and we report them for each piece as well as for the programme in total.
Indicators we would track
Metric
Why it matters
How we would measure it
01Time to deliver a change
Why it mattersThe clearest proof that the system is becoming less painful to change.
How we would measure itElapsed time between a change request being approved and the change reaching production, for legacy and renewed parts alike.
02Comparison results
Why it mattersTells you whether the replacement service actually matches the legacy behaviour where it should.
How we would measure itPercentage of transactions and records that match during the parallel run, with open mismatches sorted by cause.
03Rules confirmed and tested
Why it mattersUndiscovered rules are the single largest risk when replacing a system.
How we would measure itThe share of rules found that subject-matter experts have confirmed and that tests cover.
04Legacy still running
Why it mattersRenewal only pays once old components are really switched off.
How we would measure itRetired functions, code paths, batch jobs and licences, counted per piece.
No targets are set before a baseline exists.
Rollout
A phased rollout
Phase 01
Survey
Applications, dependencies, domains and risks. Together we choose a first piece that the business cares about but that can still be undone.
Exit criteria
Target architecture approved
Order of the pieces settled
Access to test data arranged
Phase 02
First piece
Rules recovered, regression net, façade and one rebuilt function, processing the same work as the legacy system.
Exit criteria
Mismatches below the agreed tolerance
Business owner agrees to the switch
Way back tested
Phase 03
One piece at a time
Each further function follows that path, with a parallel run and a switch decision of its own.
Exit criteria
Every piece matched and switched
Know-how handed to your team
Phase 04
Close-down
Legacy code paths, batch jobs and databases are archived and shut down.
Benefits, licensing and registration systems in Government departments, where years of legislation sit in old code and new Legal Notices keep arriving.
The home-grown ERP of a family business or the custom extensions of a Maltese plant, moved as part of an SAP S/4HANA migration.
Illustrative example
A core system at a credit institution
Situation
A Maltese credit institution keeps its loans and deposits on an ageing core. Changes requested by the MFSA and by the business pile up, and two developers who understand the code will retire soon.
System
Rules are recovered and signed off product by product. A façade routes the calculations for one product to a replacement service first, and both process the same work until their results agree.
Human control
Product specialists confirm their rules. The business owner agrees to each switch, the façade keeps a way back open, and comparison reports are kept as evidence for DORA purposes.
What we would measure
Comparison results per product, the percentage of rules signed off and tested, and the elapsed time for the next regulatory change.
Malta
Renewal under Maltese and EU rules
In Malta the same ageing core often has to absorb new Legal Notices, MFSA requirements and EU rules while staying in service. We order the work so that each piece moves only after old and new agree on Maltese cases, and so that pending amendments are not frozen for years.
Replacement services land on platforms built for the security duties of the NIS2 Order (Legal Notice 71 of 2025), in force since January 2026, and for DORA where an MFSA licence holder owns the system. The Data Act’s rules on switching providers argue for portable data from the very first piece, and where records hold personal data, the mappings and test data respect the GDPR.
One switch-over date loads every risk onto a single weekend, and the business sees nothing for years. Renewing in small pieces means each piece earns its place in a parallel run, goes live independently and can be undone when needed.
02Can AI just rewrite our COBOL as Java?
Mechanical line-by-line rewriting tends to leave you with Java that resists change as much as the COBOL did. We let AI read and explain the legacy code and draft rules and tests; the replacement services are then designed by engineers. Nothing recovered is relied upon until a person has signed it off.
03Our experts will retire soon. How is their knowledge kept?
Through working sessions in which they go over the recovered rules and the regression tests. Their knowledge is captured in documentation and tests that stay inside your organisation, not with an outside supplier.
04Is SAP ECC covered too?
Yes. Custom-code clean-up and an upgrade to SAP S/4HANA follow the same logic: establish what is actually used, recover and test what matters, and move in controlled stages.
05How long will old and new run side by side?
Until the mismatches fall inside the tolerance agreed with the business owner, and at least through the periodic cycles that matter, such as a month-end close or the year-end run.