Migrating Core Banking Off the Mainframe: An Illustrative Scenario

This is an illustrative scenario that combines common patterns from large-scale modernisation programmes. It does not describe a specific client or reported results.

Picture a bank whose core systems run on decades-old mainframe technology. Change is slow and expensive, regulatory demands keep growing, and digital-first competitors ship new features in days.

The constraint: no downtime

Banking systems cannot simply be switched off. Payments, balances and trading must keep working throughout, so a one-weekend "big bang" cutover is rarely an acceptable risk.

The approach: strangle, don't replace

The safer pattern is incremental. New services are built around the legacy core and take over one capability at a time, while the old system keeps running until each piece is proven.

• Map the estate: document dependencies before moving anything.
• Put an API layer in front: new channels talk to the layer, not directly to the mainframe.
• Move capability by capability: start with low-risk, high-value functions such as read-only views.
• Run in parallel: compare old and new outputs before switching traffic over.
• Keep a rollback path: every step must be reversible.

What good looks like

Success is measured by outcomes the business cares about, agreed up front: availability through the migration, time to ship a change, run cost, and unbroken regulatory compliance. Teams should baseline each of these before the work begins so progress is provable.

Lessons that carry over

• Data migration and reconciliation take longer than the code. Plan for it early.
• Involve risk and compliance teams from day one, not at the end.
• Invest in observability so problems are caught during parallel running, not after cutover.