Before a Nigerian bank board approves a core system migration, four questions can predict whether the programme will deliver zero downtime or trigger a regulatory event. Most boards approve migrations without asking any of them.
That is the gap the CBN’s Risk-Based Cybersecurity Framework has made visible. Since the framework came into force on 1 July 2024, unplanned IT outages in regulated institutions are reportable to the CBN within 24 hours, surface in the quarterly board cyber risk return, and feed the annual self-assessment due 28 February. The framework did not invent the operational risk. It changed who answers for it.
The cost of approving migrations without those four questions is documented. In Q4 2024, three Nigerian banks attempted core migrations in the same fortnight. Zenith Bank lost service for more than 48 hours during its Phoenix-to-Oracle Flexcube cutover. GTBank’s move to Finacle disrupted 32.8 million customers for close to ten days; federal government workers banking with GTBank received their October salaries the following month. Sterling Bank kept more than three million customers out of every banking channel for at least five days. Access Bank, scheduled to upgrade in the same fortnight, postponed and did not appear in the press cycle that followed. The difference was governance discipline at the point of approval.
The governance gap
Most technology migration failures do not originate at the technical layer. They originate at the governance layer — specifically, at the point where risk decisions about downtime are made below the threshold where consequences actually land.
I have led core banking migrations and enterprise system transformations across financial services, energy, aviation, government, and public infrastructure in Nigeria and the UK. The pattern that precedes failure is consistent: the downtime risk is known, often documented in the project plan, and then quietly reclassified from “unacceptable” to “manageable” under schedule pressure. The reclassification happens at the programme manager level. By the time it becomes a C-suite conversation, the window to change the approach has closed — and the board is learning about a regulatory event after the fact.
CBN reporting requirements did not create this governance gap. They made the cost of it concrete. Sanctions under the framework run from formal supervisory notices through mandated remediation timelines to public censure — penalties that compound across audit cycles and follow the institution into subsequent regulatory reviews.
The four requirements — and who should verify them
Zero downtime methodology rests on four structural requirements. C-suite and board should be verifying each at defined programme milestones, not receiving them as reassurance in progress reports.
Parallel operation. The legacy platform and the replacement system must run simultaneously for a defined period, processing the same transactions under real production conditions. This is the most expensive requirement and the one most frequently removed under budget pressure. When it is cut, the organisation substitutes synthetic test data for production validation, and production data is not synthetic. It changes. It surfaces edge cases that staged environments never reach. The risk of cutting parallel operations does not appear in the budget savings. It appears on cutover night, when production transactions in the test environment are never modelled, bringing the new system down. Board question: Is parallel operation funded and confirmed in the programme plan?
Continuous data synchronisation. During parallel operation, data must flow between both systems in real time. One-time migration scripts do not account for the records that continue to change in production between the last export and the moment of cutover. That gap is where data loss hides. In a financial institution, it is where regulatory exposure compounds. Continuous synchronisation eliminates the gap. Board question: Has the synchronisation architecture been independently reviewed, and by whom?
Rehearsed cutover. The cutover sequence — the actual transition from legacy to new platform — must be practised, timed, and documented. Not diagrammed on a slide. Practise d. Each rehearsal surfaces something the written plan did not: an approval dependency, a notification sequence with the wrong stakeholders, a validation step that runs long under production load. A rehearsed cutover converts a high-stakes event into a procedure the team has already executed successfully. An unrehearsed one is organised hope. Board question: How many rehearsals are scheduled, who participates from across the organisation, and what changes have each produced?
Tested rollback. If the new system fails post-cutover, the organisation must be able to return to the prior platform within a defined window, preserving every transaction that occurred in the interim. Rollback is not a backup. It is a demonstrated, timed recovery procedure. If the implementation partner cannot show you how rollback works in the staging environment, not describe it, and show it, the programme is not adequately prepared for the scenario that most frequently generates regulatory events. Board question: Can the implementation partner demonstrate rollback, not describe it?
The four requirements represent the minimum governance standard for any technology migration in a regulated environment where operational continuity carries legal and regulatory weight.
What this looks like in practice
The migration I led in 2023 at a CBN-licensed financial institution in Lagos was built on all four. The institution moved from a legacy core banking platform to a modern replacement, with active customers transacting daily and continuous regulatory reporting obligations throughout.
Both platforms ran in parallel for several weeks.
Synchronisation was continuous, not nightly batch exports, but a persistent bridge keeping both systems in agreement throughout the parallel window. The cutover was rehearsed multiple times. Each rehearsal identified something the written plan had not accounted for: a timeout configuration, a notification sequence, and a validation step that ran longer than projected under load. By the time we executed the actual cutover, the team was repeating a procedure they had already completed successfully. We achieved zero service interruption and maintained unbroken regulatory reporting throughout the programme.
That outcome did not result from exceptional technology. It resulted from a methodology that was treated as a governance requirement from day one, not traded off against schedule under pressure.
The board’s responsibility
Operational resilience requirements are tightening across regulated sectors in Nigeria and across Africa. Regulators no longer expect systems to remain static. They expect governance structures that manage change without systemic risk.
Boards operating in this environment have a specific responsibility: to ensure migration risk is not being carried below the level where it can be seen, funded, and enforced. The four questions above are the instruments for that.
The CBN framework is a signal. Across financial services, energy, and public infrastructure, the direction of regulatory travel is consistent: operational resilience is becoming a board-level accountability with explicit audit consequences. Boards that build that institutional oversight now will be the ones whose institutions can demonstrate compliance when it is demanded, rather than explain an event after it has occurred.
The technical methodology for zero-downtime migration is already established. What increasingly differentiates resilient institutions from exposed ones is whether boards are prepared to fund it, enforce it, and treat operational continuity as a governance obligation rather than a project preference.
Samson Adekoya designs and implements enterprise technology systems for regulated industries. Over the past decade, he has led implementations across banking, government, energy, aviation, legal, and public transport in Nigeria and the UK, delivering zero-downtime migrations and multi-agency compliance architectures in environments where failure carries regulatory consequences.
Connect on LinkedIn or reach him at [email protected].
Join BusinessDay whatsapp Channel, to stay up to date
Open In Whatsapp
