Modernise the system nobody dares to touch, one capability at a time.
Decades of business rules live in COBOL, PL/I, Oracle Forms and early Java and .NET. We recover those rules, build a safety net of tests, and move capability by capability behind a façade, with parallel runs and reconciliation before anything is switched off.
For organisations running critical systems across several countries, where downtime and lost rules are not an option.
The portfolio is assessed and the target agreed. Business rules are recovered from the code with AI assistance and verified by people. Characterisation tests form a safety net. Each capability is rebuilt behind a façade and run in parallel with the old system; discrepancies are triaged and fixed before the business owner approves the switch and the old part is retired.
Before and after
What changes in the way you work
Today
With the system
Today
Today: Every change is a risk
Small regulatory changes take months because nobody can predict what else a change will affect.
With the system
With the system: Changes backed by tests
Characterisation tests capture what the system does today, so every change shows its effect before release.
Today
Today: Knowledge is retiring
The people who understand the code are close to retirement, and the documentation stopped matching the system long ago.
With the system
With the system: Rules written down and verified
Business rules recovered from the code are documented in plain language and confirmed by domain experts.
Today
Today: Big-bang plans stall
Full replacement programmes promise a single cut-over date that keeps moving while costs grow.
With the system
With the system: Value released in slices
Capabilities move one at a time behind a façade. Each slice goes live on its own, and can be rolled back.
Today
Today: Data locked in old structures
New services and AI use cases cannot reach the data without fragile extracts and overnight batches.
With the system
With the system: Data available through APIs
Migrated domains expose their data through documented APIs, reconciled with the old system until it is retired.
Workflow
How the workflow runs
A strangler-fig approach: the new system grows around the old one, capability by capability. The loop between parallel run and rebuild is where most of the real work happens.
Illustrative workflow
7 steps · 3 human checkpoints
Legend
System
AI agent
Person
Human checkpoint
Exception path
Legacy modernisation: illustrative workflow with reconciliation loop
Read the diagram as text
The main path runs from assessing the portfolio and recovering the business rules, through building a safety net of characterisation tests and rebuilding one capability behind a façade, to running old and new in parallel and finally switching over and retiring the old part.
People sign off the target architecture, verify every recovered rule and approve each switch-over: those are the human checkpoints.
When the parallel run shows that outputs differ, the slice leaves the main path for triage by engineers and domain experts, and loops back to the rebuild step until old and new reconcile.
01
Step 1: Assess the portfolioPerson
Application inventory, dependency and data-flow mapping, and a decision per application: retire, retain, rehost, replatform, rebuild or replace. Domains are mapped to find the seams where slicing is possible.
Human checkpoint
Your architecture board signs off the target architecture and the order of the slices.
02
Step 2: Recover the business rulesAI agent
AI-assisted code comprehension reads COBOL, PL/I, JCL, Oracle Forms and older Java or .NET, and drafts documentation, call graphs and a catalogue of business rules.
Human checkpoint
Engineers and domain experts verify every extracted rule before it is used as a specification. Unverified rules are marked as such.
03
Step 3: Build the safety netSystem
Characterisation tests are generated from anonymised production inputs and outputs, so the current behaviour, including its quirks, is captured before anything changes.
04
Step 4: Rebuild a slice behind a façadeSystem
A routing façade or API layer is placed in front of the old system. One capability is rebuilt as a new service, with its data migrated and kept in sync.
05
Step 5: Run in parallel and reconcileSystem
Old and new process the same transactions. Outputs and data are compared automatically and every difference is reported per rule and per record.
06
Step 6: Triage discrepanciesPerson
Engineers and domain experts decide whether each difference is a defect in the new service, a defect in the old one, or an intended change, and send the slice back for rework.
Exception path: Outputs differ· Returns to step 4
07
Step 7: Switch over and retirePerson
Traffic for the capability moves to the new service through the façade. After a stable period the old code path and its data are retired and archived.
Human checkpoint
The business owner approves each switch on the basis of reconciliation results. Rollback through the façade stays available until retirement.
Components
What we would build
01
Portfolio and dependency map
Inventory, interface and data-flow mapping, and a domain model that shows where the system can be cut into slices.
Salesforce as a new front officePlatformSalesforce
Integration platform and API gateway
Target cloud or data centre
Controls
Controls designed in
Access boundaries
Code analysis runs in an environment you control, with no source code sent to services you have not approved. Production data used for tests is anonymised before it leaves the production zone.
Human review
Recovered rules are verified by engineers and domain experts before they become specifications. Every switch-over is approved by the business owner on the basis of reconciliation results, with rollback available.
Auditability
Each rule in the catalogue traces back to the code it came from and the person who verified it. Reconciliation reports are kept as evidence for every switch-over.
Data protection
Data migration follows a documented mapping with record counts and checksums, and personal data is minimised in test sets. Retention rules move with the data.
AI transparency
Where AI drafts documentation or code, the output is labelled, reviewed and versioned like any other engineering artefact.
Measures
What we would measure
We agree these measures with you during the assessment and track them per slice, not only for the programme as a whole.
What we would measure
Metric
Why it matters
How we would measure it
01Lead time for change
Why it mattersThe clearest sign that the system is becoming easier to change.
How we would measure itTime from approved change request to production, for the old and the modernised parts.
02Reconciliation status
Why it mattersShows whether the new service really behaves like the old one where it should.
How we would measure itShare of transactions and records that match during the parallel run, with open differences by cause.
03Rule coverage
Why it mattersUnknown rules are the main risk in any replacement.
How we would measure itShare of recovered business rules verified by domain experts and covered by tests.
04Legacy footprint
Why it mattersModernisation pays off when old components are actually switched off.
How we would measure itCapabilities, code paths, batch jobs and licences retired, tracked per slice.
No targets are set before a baseline exists.
Rollout
How we would roll it out
Phase 01
Assessment
Portfolio, dependencies, domains and risks. We choose a first slice that matters to the business but can be rolled back.
Exit criteria
Target architecture approved
Slice order agreed
Test and data access arranged
Phase 02
First slice
Rule recovery, safety net, façade and one rebuilt capability, run in parallel with the old system.
Exit criteria
Reconciliation within agreed tolerance
Business owner approves the switch
Rollback tested
Phase 03
Slice by slice
Further capabilities follow the same path, each with its own parallel run and switch-over decision.
Exit criteria
Each slice reconciled and switched
Knowledge transferred to your team
Phase 04
Retirement
Old code paths, batch jobs and data stores are archived and switched off.
Custom ERP extensions and plant systems, moved alongside an SAP S/4HANA migration.
Illustrative example
A shared core system serving three countries
Situation
A mainframe system calculates contributions for three national subsidiaries. Each country has pending rule changes, and two of the developers who know the code are retiring.
System
Rules are recovered and verified per country. A façade routes one country’s calculations to a new service first, running in parallel with the mainframe until the results reconcile.
Human control
Domain experts in each country verify their rules. The business owner per country approves the switch; rollback through the façade remains available.
What we would measure
Reconciliation status per country, rule coverage, and lead time for the next regulatory change.
International
Modernising under European rules
Large European organisations often run the same legacy core for several countries, each with its own regulatory changes queued up. We sequence modernisation so national variants move one slice at a time, with the old and new reconciled for each jurisdiction before anything is switched off.
Modernised services land on platforms designed with NIS2 security duties in mind, and the Data Act’s switching rules are a reason to keep data portable from the first slice. Where records hold personal data, migration mappings and test data follow the GDPR.
Because a single cut-over concentrates all the risk on one date, and the business waits years for any benefit. Moving capability by capability lets each slice prove itself in a parallel run, go live on its own and be rolled back if needed.
02Can AI translate our COBOL into Java?
Line-by-line translation tends to produce code that is as hard to change as the original. We use AI to read and document the old code and to draft rules and tests, then design the new services properly. Every recovered rule is verified by people before it is used.
03Our experts are retiring. How do you capture what they know?
Through structured sessions in which experts review the recovered rules and the characterisation tests. Their knowledge ends up in documentation and tests that stay with your team, not in our heads.
04Does this apply to SAP ECC as well?
Yes. The same principles apply to custom code remediation and an SAP S/4HANA migration: assess what is still used, recover and test what matters, and move in controlled steps.
05How long do old and new run side by side?
Until the reconciliation results meet the tolerance agreed with the business owner, and long enough to cover periodic processes such as month-end or annual runs.