Renew the system everyone avoids changing, one capability after another.
Years of business rules are buried in COBOL, PL/I, Oracle Forms and first-generation Java and .NET code. We bring those rules to the surface, protect current behaviour with tests and move capabilities one by one behind a façade, with both systems processing the same work and reconciled before any old part is turned off.
For organisations in Malaysia whose critical systems cannot stop or lose their rules, and must stand up to supervisory review at every step.
The application landscape is reviewed and a target agreed. With AI support, the business rules hidden in the code are brought out, and people confirm them. Characterisation tests give a safety net. Each capability gets a new implementation behind a façade and runs alongside the old system; differences are investigated and fixed, the switch needs the business owner’s approval, and only then is the old part retired.
Before and after
How your way of working changes
Today
With the system
Today
Today: Each change carries risk
Even a minor regulatory amendment can take months, since nobody can predict which other functions it will disturb.
With the system
With the system: Tests behind every change
Characterisation tests record today’s behaviour, so the effect of each change is visible before release.
Today
Today: Knowledge is leaving
Those who still understand the code are near retirement, and the documentation stopped describing the system long ago.
With the system
With the system: Rules recorded and confirmed
Rules taken out of the code are written up in plain wording, then checked by business domain experts.
Today
Today: Single cut-over plans stall
Programmes that replace everything at once promise one go-live date that keeps slipping while the budget grows.
With the system
With the system: Benefits delivered in slices
Capabilities move behind a façade one by one. Each slice goes live separately, with a way back if needed.
Today
Today: Data trapped in old structures
Reporting, new digital services and AI reach the data only through brittle extracts and overnight batch jobs.
With the system
With the system: Data reachable through APIs
Domains that have moved publish their data through documented APIs and stay in agreement with the old system until that system is retired.
Workflow
How the flow runs
This follows the strangler-fig pattern, in which new services gradually take over from the old system. The loop between parallel run and rebuild is where most of the effort goes.
Illustrative workflow
7 steps · 3 human checkpoints
Legend
System
AI agent
Person
Human checkpoint
Exception path
Legacy modernisation: illustrative flow with a reconciliation loop
Read the diagram as text
The main path begins with reviewing the landscape and recovering business rules, continues with a safety net of characterisation tests and a new slice behind a façade, and moves through the parallel run to the switch and the retirement of the old part.
People approve the target design, confirm each recovered rule and give their approval before any switch: these are the human checkpoints.
If the parallel run shows different results, engineers and domain experts take the slice off the main path to investigate it. It goes back to the rebuild step and repeats the loop until both systems agree.
01
Step 1: Review the landscapePerson
An inventory of applications, a map of dependencies and data flows, and a choice for each application, from keeping it or moving it as it is to rebuilding, replacing or retiring it. A domain model shows the natural boundaries along which slices can be cut.
Human checkpoint
Your architecture board approves the target design and the sequence of slices.
02
Step 2: Recover business rulesAI agent
Code analysis supported by AI works through COBOL, PL/I, JCL, Oracle Forms and older Java or .NET programs, producing draft documentation, call graphs and a rule catalogue.
Human checkpoint
Engineers and domain experts confirm each recovered rule before it serves as a specification. Rules not yet confirmed carry a clear mark.
03
Step 3: Set up a safety netSystem
Characterisation tests are built from production inputs and outputs with personal data removed, capturing today’s behaviour, oddities included, before anything changes.
04
Step 4: New slice behind a façadeSystem
A façade or API layer starts to route the requests that used to reach the old system directly. One capability is built again as a separate service; its data is migrated and synchronised with the old store.
05
Step 5: Parallel run and reconciliationSystem
Both systems process identical transactions. Results and records are compared by machine, and every difference is reported by rule and by record.
06
Step 6: Investigate differencesPerson
Engineers and domain experts classify each difference: a fault introduced by the rebuild, a fault that was always present in the legacy code, or a deliberate change. The slice then returns for rework.
Exception path: Results disagree· Returns to step 4
07
Step 7: Switch and retirePerson
The façade sends traffic for the capability to its replacement. After a stable period, the legacy code path is retired and its records archived.
Human checkpoint
Each switch needs the approval of the business owner, given on the reconciliation results. The façade keeps a route back open until the legacy part is retired.
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 divided.
Landing zone, deployment pipelines and observability for the replacement services, in a cloud or data centre you select, at a hosting location recorded in the contract.
Salesforce as the new front officePlatformSalesforce
API gateway and integration platform
Chosen cloud or data centre
Controls
Controls built in
Access boundaries
We analyse code in an environment you control, and no source code is sent to a service you have not cleared. Test data taken from production has personal data stripped out inside the production zone.
Human review
Engineers and domain experts confirm recovered rules before they become specifications. The business owner approves every switch on the strength of reconciliation results, and a rollback route stays open.
Auditability
Every catalogue entry points to the lines of code behind it and names the person who confirmed it. Reconciliation reports form the evidence for each switch, which helps when a supervisor or auditor asks how a change was tested.
Data protection
Migration runs on a written mapping, checked with record counts and checksums, and test sets hold as little personal data as possible, in line with the Personal Data Protection Act 2010 (PDPA). Retention rules travel with the data.
AI transparency
Documentation or code drafted with AI is marked as such, reviewed by an engineer and kept under version control in the same way as everything else we deliver.
Measures
Measures we would agree
We agree the measures with you in the assessment phase and follow them for each slice as well as for the whole programme.
Measures we would agree
Metric
Why it matters
How we would measure it
01Time to deliver a change
Why it mattersThe plainest evidence that changes are becoming easier to make.
How we would measure itTime between approval of a change request and its release to production, measured for old and modernised parts.
02Reconciliation status
Why it mattersTells you whether the replacement behaves as the legacy code does wherever it should.
How we would measure itShare of transactions and records that agree while both systems run, with open differences grouped by cause.
03Rule coverage
Why it mattersRules nobody knows about are what usually breaks a replacement.
How we would measure itShare of recovered rules that domain experts have confirmed and tests cover.
04Remaining legacy
Why it mattersThe investment pays back only once old parts are really switched off.
How we would measure itNumber of batch jobs, code paths, capabilities and software licences retired in each slice.
No targets are set before a baseline exists.
Rollout
Rollout in stages
Phase 01
Assessment
Landscape, dependencies, domains and risks. We pick a first slice that the business cares about and that can still be rolled back.
Exit criteria
Target architecture approved
Order of slices agreed
Access to tests and data arranged
Phase 02
First slice
Rule recovery, the safety net, the façade and a first rebuilt capability, running alongside the old system.
Exit criteria
Reconciliation inside the agreed tolerance
Switch approved by the owner
Rollback rehearsed
Phase 03
Further slices
Further capabilities take the same route, each with a parallel run and a switch decision of its own.
Exit criteria
Every slice reconciled and switched
Knowledge handed over to your team
Phase 04
Retirement
Legacy batch jobs, code paths and data stores are archived, then shut down.
Core policy, takaful and payment systems at insurers and banks, opened up through APIs while the accounts stay reconciled and the work is documented for supervisory review.
Bespoke ERP add-ons and plant systems at manufacturers and exporters, moved together with a move to SAP S/4HANA.
Illustrative example
Back office of a stockbroking firm
Situation
A stockbroking firm could run settlement, contract notes and client accounting on an in-house system built up over many years. Rule changes would queue up, and the two people who understand the code best would be close to retirement.
System
Rules would be recovered and confirmed module by module. Contract-note generation would move first: the façade would pass it to a replacement service, and both would process the same trades until the results reconcile.
Human control
Operations and compliance staff confirm the recovered rules. The business owner signs off each switch, the façade keeps a route back, and the evidence is kept for review against the SC Guidelines on Technology Risk Management.
What we would measure
Reconciliation status per module, rule coverage, and time to deliver the next regulatory change.
Malaysia
Modernising under RMiT and Act 854
Banks, insurers and takaful operators modernise core systems under the revised Risk Management in Technology (RMiT) policy document of Bank Negara Malaysia (BNM), in effect since 28 November 2025. Capital market intermediaries work under the Guidelines on Technology Risk Management of the Securities Commission Malaysia (SC), in effect since 19 August 2024. We plan each slice so that testing, reconciliation and the switch decision are documented and can be shown to supervisors.
Where a system belongs to a National Critical Information Infrastructure (NCII) entity under the Cyber Security Act 2024 (Act 854), in operation since 26 August 2024, the new platform is built so that incidents can be notified within six hours. Test data and migration mappings follow the Personal Data Protection Act 2010 (PDPA). For services sold to EU customers, NIS2 supply-chain clauses and the switching rules of the EU Data Act are reasons to design for portable data from the start.
Because a single cut-over date puts all the risk on one day, and the business can wait years for any benefit. When capabilities move separately, each slice proves itself while both systems run, goes live by itself and can be reversed.
02Can AI convert our COBOL into Java?
A line-by-line translation usually leaves code just as difficult to change as before. AI helps us read the legacy programs, document them and draft rules and tests; the new services are then designed properly by engineers. People confirm each recovered rule before anyone builds on it.
03Our experts are close to retirement. How is their knowledge kept?
In structured sessions, the experts go through the recovered rules and the characterisation tests with our engineers. Their knowledge is written into documentation and tests that your team keeps, rather than staying with us.
04Does the same apply to SAP ECC?
Yes. The same principles hold for custom code remediation and a move to SAP S/4HANA: establish which code is still used, recover and test the parts that matter, and move step by step under control.
05How long do both systems run side by side?
Until reconciliation results fall inside the tolerance the business owner accepted, and for long enough to include periodic runs such as month-end and the close of the financial year.
Tell us about the system and the processes that rely on it. We will propose a first slice and a safe way to prove it, with the evidence your supervisors and auditors will expect.