UNDER CONFIDENTIALITY AGREEMENT
Legacy Modernization at a tier-1 bank
40% reduction in critical computation time and progressive refactoring of the core, while maintaining 24/7 operation throughout the transition.
Sector
Banking · Tier-1 financial institution (Europe)
Technology stack
Oracle, PL/SQL, IBM Spectrum Symphony, integration with Murex / Algorithmics
Project scope
- · Refactoring of critical PL/SQL and decoupling of Oracle monoliths
- · Implementation of DevOps + GitOps pipeline for automated deployments
- · Migration in controlled phases with no operational downtime
Measurable impact
- · -40% time in critical financial computation processes
- · ~99% CPU utilization at peaks
- · 99.9% availability throughout the entire transition
Context
A European tier-1 financial institution runs its critical financial computation (risk, treasury, valuation) on an Oracle core with PL/SQL logic, an IBM Spectrum Symphony grid and market systems such as Murex and Algorithmics. It is a 24/7 operation: there is no window in which the system can stop.
The core had grown over the years into PL/SQL monoliths that were hard to evolve, with manual deployments and processes whose execution time no longer fitted the business windows. The goal was to cut those times and modernise the way software is delivered without touching availability.
The challenge
Three constraints shaped the project:
- Critical financial computation processes with unsustainable run times that blocked business operations.
- Oracle monoliths with tightly coupled critical PL/SQL, where no piece could be changed without putting the whole at risk.
- A 24/7 operation and integrations with Murex and Algorithmics that had to stay intact throughout the transition.
Phased approach
The modernisation ran as a sequence of controlled phases, each with validation and rollback capability.
-
01
Code and grid diagnosis
Identification of the PL/SQL that concentrated compute time and of the real utilisation of grid resources.
-
02
Refactoring and decoupling
Rewriting of the critical PL/SQL and progressive separation of the Oracle monoliths into independently deployable components.
-
03
DevOps and GitOps pipeline
Automated deployments: every change versioned, tested and promoted reproducibly.
-
04
Phased migration with no downtime
Production rollout component by component, keeping the Murex and Algorithmics integrations and the 24/7 operation.
Architecture and strategy
The principle was the same one we apply across tier-1 banking projects: extend and decouple rather than replace. The Symphony grid and the Oracle core stay where they are; what changes is how the work is distributed (grid utilisation) and how the software is delivered (an automated pipeline instead of manual deployments).
Measurable results
Results validated in production:
| Indicator | Before | After |
|---|---|---|
| Critical financial computation time | Unsustainable windows | −40% |
| CPU utilisation at peaks | Fragmented grid, low utilisation | ~99% |
| Availability during the transition | 24/7 operation | 99.9%, no operational downtime |
Aggregated figures, anonymised under a non-disclosure agreement. Source: Vermont Solutions projects.
Lessons that carry over
- In a 24/7 core, phased migration with rollback capability is not optional: it is the only way to move forward without exposing the business.
- Automating delivery (DevOps + GitOps) reduces errors and makes every deployment predictable and auditable.
- Measuring real grid utilisation before expanding it avoids unnecessary investment: the margin was in the distribution, not in the hardware.
Regulatory framework
Risk computation in tier-1 banking is a supervised matter; the modernisation was designed to strengthen the evidence of control.
- Basel III/IV: capital and risk calculations within the required windows.
- DORA (Art. 28): change traceability, operational resilience and ICT third-party management.
- BCBS 239: risk data aggregation with documented, reproducible processes.
Frequently asked questions
Which technologies were involved?
Oracle and PL/SQL in the core, IBM Spectrum Symphony as the calculation grid and integrations with Murex and Algorithmics, plus a DevOps/GitOps pipeline for deployments.
Was there any downtime?
No. The migration ran in controlled phases while keeping the 24/7 operation and 99.9% availability throughout the transition.
How was 99% CPU utilisation achieved without adding hardware?
By reducing the work per process (refactoring the critical PL/SQL) and improving task distribution on the grid: the margin was in the fragmentation, not in the capacity.
Can I know the institution and the full figures?
The case is anonymised under a non-disclosure agreement. Architecture details and full figures are shared after signing an NDA.
Related content
Last updated: 2026-09-12
Full figures and architecture are shared upon NDA signing.
Request detail under NDA →