A mainframe modernisation programme is not approved once. It is re-approved every budget cycle by people who were not in the room when it started, who have not read the architecture documents, and who are weighing it against a list of competing priorities that grew longer since the last review. The VP of Enterprise Integration’s job in this context is not to explain the strangler fig pattern. It is to anchor the programme in language and metrics the board can evaluate without understanding the technology — and to make sure those metrics are in place before the programme starts, not invented retroactively when the first renewal conversation comes around.
There are four decisions that determine whether the programme survives to completion. Two of them feel like business decisions and are treated as business decisions. Two of them feel like technical decisions but are actually business decisions in disguise. Getting this wrong in Year 1 is expensive; getting it wrong in Year 2 is usually fatal to the programme.
The real cost of the status quo
Every mainframe modernisation conversation begins with the CFO asking what the mainframe costs. The number that usually gets quoted is the IBM software licence — the MLC (Monthly Licence Charge), which is priced on peak MIPS consumption and is the single largest line item in most banks’ technology operating budgets. But the licence cost is only the visible part. The hidden cost is the constraint the mainframe places on delivery velocity: every new product feature that requires a mainframe change goes through a specialised COBOL or RPG development team, a mainframe change window, and a CAB process calibrated for a system where failures are catastrophic. That constraint compounds over years as the bank tries to compete with neobanks that ship weekly.
The business case for modernisation has to capture both costs. The MIPS cost is quantifiable and the CFO will hold you to the projection — so quantify it carefully. The velocity cost is harder to quantify but often larger; frame it in terms of what the bank cannot ship today that competitors already have, and what it would cost to build it under the current constraint versus under an API-native architecture.
Year 1 of a mainframe migration produces no MIPS reduction. Wave 0 — building the façade — adds overhead while the mainframe still runs everything. Set this expectation before the programme starts, not after the first budget review.
Sequencing is a business decision, not a technical one
The sequence in which capabilities migrate from the mainframe to modern services is the most consequential decision the programme makes, and it is almost always framed as a technical decision because it involves architecture, dependency graphs, and migration risk. But the sequencing question is fundamentally a business question: which capabilities are the highest cost to leave on the mainframe, and which capabilities are the lowest risk to migrate first?
The technical team will correctly recommend starting with clean, read-heavy capabilities at low transaction volumes — customer master data, account enquiry, customer address. These are low risk and appropriate as first waves. But the business case depends on migrating the high-MIPS capabilities — payment processing, core account transactions — and those are the ones the technical team will correctly identify as high risk and schedule late. The tension between risk sequencing and payback sequencing is real, and it must be resolved explicitly at the programme level, not left for the architecture team to navigate case-by-case.
The resolution is a phased payback model that the board approves at the start. Year 1 and most of Year 2 are investment: you are building the migration infrastructure and migrating the low-risk capabilities. The MIPS cost stays flat or rises slightly (the façade adds overhead). The major reduction starts in Year 3 when Core Accounts and Payments migrate. If the board is not committed to the full three-year arc, the programme will be cut in Year 2 on the basis that it has not delivered the promised cost reduction — because it was never going to deliver it that early.
What SAMA will ask
SAMA’s Technology Risk Management framework requires notification for material changes to core banking systems. A mainframe migration qualifies as material. The notification starts a 30-day review clock. This is not a blocker; it is a process requirement that, if missed, becomes a finding in the next technology risk examination and complicates the relationship with your examination team for the remainder of the programme.
Beyond notification, SAMA will ask two questions that the board needs to be prepared for. First: what is the audit trail continuity plan? Core banking systems must maintain a complete, unbroken audit trail through any migration event. The answer is not “we will wire it in before cutover” — the answer needs to be that the new service logs to the enterprise audit trail from Day 1 of shadow mode, before any production traffic flows through it. Second: what is the data residency assurance? All customer data must remain within KSA borders through the migration, including shadow copies and staging environments. If the migration uses a cloud provider for any part of the shadow infrastructure, residency must be demonstrated — not assumed from the vendor’s region labelling.
Framing these two points correctly for the board matters because they affect the programme plan in ways the business needs to approve. Audit trail continuity from Day 1 of shadow requires additional engineering work that is not present in a purely technical migration plan. Data residency constraints limit the cloud services and regions the programme can use. Neither is a showstopper, but both need to be funded and scheduled explicitly.
What the team needs from leadership to ship it
The most reliable predictor of whether a mainframe modernisation programme completes is whether the integration engineering team is protected from BAU. The same engineers who understand the mainframe well enough to map its dependencies, design the ACL, and verify the shadow comparison are the engineers who get pulled onto incident bridges, asked to patch the MQ-CICS bridge for the third time this month, and seconded to the next product launch that needs “just one mainframe change.”
The VP needs to make a structural decision at the start of the programme: a dedicated modernisation squad that is not on BAU rotation. This is not a large team — five to eight engineers for a programme of this scope — but it needs to be genuinely dedicated. A team that is “dedicated to the migration except when incidents pull them” is not a dedicated team; it is a team with a migration obligation that competes with an operational obligation, and the operational obligation always wins because it has a live user on the other end.
The second leadership act is to set the tone on gate integrity. The reconciliation gate — 30 consecutive days of zero breaks before cutover — will be challenged under programme pressure. A programme manager whose quarterly target includes the cutover will ask whether 25 days with no breaks is “close enough.” The answer needs to come from the VP, not from the engineer defending the gate against schedule pressure. Setting that precedent in Wave 1 protects the integrity of Wave 2 and Wave 3, which carry far higher stakes.
For the engineering depth behind this programme framework — dependency analysis tooling, IBM IIDR CDC configuration, capability slicing heuristics, reconciliation SQL, and the full pre-cutover checklist — see the companion Lab article: Legacy Integration: Mainframe Modernisation Roadmap.