Implementing DevOps for Legacy Vendor Systems in a Global Bank: A Continuous Delivery Case Study

Traditional banks often depend on numerous vendor‑supplied systems, many of which are built on outdated architectures and require changes through database updates such as stored procedures, making continuous delivery challenging.

The managed system is a monolithic .NET and Oracle application serving ten Asian and European countries, with more than 20 changes required each month. Releases were performed monthly, covering a large scope, high risk, and constrained to a narrow maintenance window (weekends or weekdays 6 am–8 am), leading to long execution times and overtime.

The company set a clear DevOps goal: double the number of releases and halve the number of incidents, specifically achieving weekday releases without overtime.

Key findings showed that most releases are small data patches affecting a single country or region. Deploying these patches on weekdays dramatically accelerates business value, improves satisfaction, and addresses the “80 % of problems” principle, while the few global‑impact patches remain in the monthly release cycle, now with a reduced overall risk.

Implementation – Test Environment :

Vendor staff push patches to a GitHub test branch, triggering a Jenkins job.

The Jenkins job invokes a custom database deployment tool to apply scripts to the test environment.

Vendors provide validation scripts that run alongside deployment.

Successful validation notifies business for UAT; failures trigger automatic rollback.

Implementation – Production Environment :

After UAT passes, patches are merged into the master branch and a release approval process is started.

A Jenkins job is scheduled for the next appropriate regional maintenance window.

The job triggers the same deployment tool to apply scripts to production.

Validation scripts confirm success; failures generate notifications for manual rollback.

The automation pipeline is illustrated in the following diagram:

Results :

Data patches no longer wait for monthly releases, achieving true continuous delivery and faster business value.

IT staff are freed from repetitive, low‑value deployment tasks.

Release risk is reduced, and both IT and business teams feel more confident.

Overtime is dramatically reduced.

Monthly release frequency rose from 1–2 to dozens, with smaller scope and lower fault rates, meeting the DevOps objectives.

Challenges and Mitigations :

Progress assurance : Daily stand‑ups (odd days for regular work, even days for pipeline implementation) keep the project on track.

Automatic acceptance : Vendors supply both patch and acceptance scripts, enabling automated verification after deployment.

Automatic rollback : Although fully automated rollback proved complex, a manual rollback process was retained for safety.

Failure notification : Current pipeline sends email alerts; a more immediate mobile notification system is still needed.

Conclusion : Most continuous delivery solutions target self‑developed applications, but legacy vendor systems often rely heavily on database changes. By isolating small data patches, automating test and production pipelines, and aligning release windows to regional business hours, a traditional bank can achieve sustainable DevOps practices without excessive overtime.

Example validation script used in the pipeline:

DECLARE
  NumberOfPatch_Actual number;
  NumberOfPatch_Expect int:=2;
BEGIN
  select count(*) into NumberOfPatch_Actual from USERS where a.user_id = 'USERA';
  IF NumberOfPatch_Actual <> NumberOfPatch_Expect THEN
    RAISE_APPLICATION_ERROR(-20001,'Error, This is testing for the log capturing');
  END IF;
END;
/