Legacy System Modernization for Nigerian Banks and Government Agencies: What It Actually Takes in 2026 | Blog

# Legacy System Modernization for Nigerian Banks and Government Agencies: What It Actually Takes in 2026

TL;DR: Nigerian banks and government agencies are being forced off decades-old core systems by regulators, outages, and data-localization deadlines — but the last wave of core banking migrations (Zenith, GTBank, Sterling) shows that rip-and-replace without disciplined engineering causes the exact outages regulators are trying to prevent.

Why "legacy modernization" is suddenly urgent, not optional

For years, legacy modernization in Nigeria was a slow-burn IT conversation — something CTOs wanted to do but never had the budget or political cover to prioritize. That changed in 2024–2026 for two unrelated but compounding reasons.

First, several tier-1 banks tried to replace their core banking systems and it went badly in public. In mid-2024, at least four major commercial banks began core platform migrations: Zenith Bank moved from Finastra's Phoenix to Oracle's FLEXCUBE, GTBank migrated from ICS Financial Systems' (ICSFS) BASIS/ICS BANKS to Infosys Finacle, and Sterling Bank moved off Temenos T24 onto a locally built platform called SEABaaS (Nairametrics, TheRadar). Customers of several of these banks experienced multi-day disruptions — failed transfers, inaccessible balances, card declines — during cutover windows. The fallout was severe enough that the Central Bank of Nigeria (CBN) now requires banks to obtain regulatory approval before changing their core banking systems, specifically to prevent uncoordinated migrations from disrupting the payments ecosystem again (Techpoint Africa, ConsumerConnect).

Second, a hard compliance deadline landed. A CBN circular dated 15 June 2026 requires all payment system participants — licensed banks, mobile money operators, payment service providers, and switching companies — to store payment transaction data on servers physically located in Nigeria by 1 January 2027 (Mondaq). That's a firm date, and it directly collides with architectures that were built assuming offshore hosting, foreign disaster-recovery sites, or vendor-managed cloud regions outside Nigeria.

On the government side, the push is coming from NITDA rather than CBN. NITDA's National Cloud Policy 2025 classifies government data by sensitivity tier and requires higher-sensitivity data to sit on Nigerian-certified, resident infrastructure, backed by a new Certified Cloud Register under the National Sovereign Cloud Initiative (Techpoint Africa, Mondaq above). NITDA also formally took over the Nigeria Government Enterprise Architecture (NGEA) portal in March 2026, a Korea-supported initiative (with KOICA) that's meant to standardize digital infrastructure across ministries, departments, and agencies (MDAs) that currently run wildly inconsistent, often decade-old systems (TechAfrica News, Leadership).

In short: regulation has caught up to the technical debt at the same moment several public failures made "modernize carefully" a boardroom mandate rather than an engineering nice-to-have.

What's actually running under the hood

Understanding why migrations break requires understanding what's being replaced. Nigerian banks run a fairly small set of core banking platforms, and most of them are old, heavily customized, and tightly coupled to surrounding systems:

Platform	Vendor	Common in
Finacle	Infosys (India)	Tier-1 banks (e.g., GTBank post-migration)
FLEXCUBE	Oracle Financial Services	Tier-1 banks (e.g., Zenith post-migration)
T24	Temenos	Multiple mid-tier and tier-1 banks
BASIS / ICS BANKS	ICS Financial Systems (ICSFS)	Older tier-1 deployments
Phoenix	Finastra	Older tier-1 deployments
Locally built cores (e.g. SEABaaS)	In-house / local vendors	A small but growing number of banks going custom

(Platform list per Adedeji Olowe's 2024 core banking survey and TheRadar.)

The pattern across the 2024 migrations was the same regardless of which vendor was involved: these cores aren't standalone. Over 15-20 years, banks bolt on card switching, USSD banking, NIBSS Instant Payment (NIP) connectivity, BVN verification, internet banking, mobile apps, and reconciliation jobs — all wired directly into the core's database or batch jobs. A "core banking migration" is never really one system swap; it's dozens of integration points that all have to be re-pointed, re-tested, and re-reconciled in the same cutover window. BusinessDay's analysis of the 2024 disruptions points to exactly this: teams underestimating the surrounding integration surface, not the core swap itself.

Government MDAs have a parallel but worse version of this problem: instead of one core system with known integrations, they typically have dozens of siloed, agency-specific systems with no shared architecture at all — which is precisely the gap the Nigeria Government Enterprise Architecture (NGEA) programme is trying to close (TechAfrica News).

Where legacy modernization actually goes wrong

Based on the pattern across the recent bank migrations, three failure modes show up repeatedly:

1. Big-bang cutover instead of parallel-run. Switching an entire customer base to a new core in one weekend maximizes blast radius. When something's wrong with reconciliation or a downstream integration, there's no fallback — customers feel it immediately, and it plays out publicly on social media and in the press.

2. Underestimating downstream integrations. NIP connectivity through NIBSS, USSD banking, card switch (Interswitch/Verve/Mastercard rails), BVN checks, and mobile/internet banking channels all assume specific data shapes and response times from the core. Migrating the core without a rigorous integration test matrix against every one of these is how "the core migration worked" turns into "customers can't see their balance."

3. Treating compliance as a bolt-on instead of a design constraint. With the January 2027 data localization deadline now fixed, any modernization plan that doesn't design for Nigeria-resident hosting and audit trails from day one will need a second, rushed migration in a year.

This is why CBN now requires pre-approval for core banking changes — it's a direct regulatory response to migrations that were executed as pure vendor-led technical projects instead of coordinated, tested, and phased programs (Techpoint Africa).

What a disciplined modernization approach looks like

For a bank, PSP, or MDA planning a legacy modernization effort in this environment, a few principles matter more than the choice of vendor:

Map the integration graph before touching the core. Every downstream consumer — NIP, USSD, card switch, mobile app, internal reporting, AML/sanctions screening — needs to be inventoried with its data contract, before deciding on migration sequencing.
Strangle, don't swap. Where possible, route new functionality through an integration layer or API gateway in front of the legacy core, and migrate modules incrementally behind that layer, rather than a single hard cutover. This gives you a rollback path at every stage instead of one.
Run parallel reconciliation, not parallel hope. Old and new systems should process the same transactions side by side, with automated reconciliation, for a defined period before the legacy system is retired — not just a manual spot-check.
Design for data residency from the start. Given the CBN's 1 January 2027 localization deadline, any new architecture — cloud or on-prem — should default to Nigeria-resident data storage for payment and transaction data, with cross-border transfer treated as the exception requiring NITDA/NDPA justification, not the default.
Treat regulatory engagement as a workstream, not a formality. Since core banking changes now require CBN pre-approval, the regulatory submission and evidence package (test results, rollback plan, customer communication plan) needs to be built alongside the technical plan, not after it.

For government MDAs, the same discipline applies, but the starting point is usually earlier: many agencies need a shared enterprise architecture and a common data exchange layer — the explicit aim of NITDA's NGEA programme (TechAfrica News) — before individual legacy applications can even be sequenced for replacement.

This is the kind of phased, integration-first modernization work we do with clients through our legacy system modernization service — assessing what's actually coupled to a legacy system before proposing how (and whether) to replace it, rather than defaulting to a full rebuild.

FAQ

Does every Nigerian bank need CBN approval to modernize its systems?

Yes, for core banking application changes specifically. Following the disruptions from the 2024 migrations, the CBN now requires banks to obtain regulatory approval before changing their core banking system, to reduce the risk of uncoordinated migrations disrupting customers (Techpoint Africa).

What is the actual deadline for data localization, and who does it apply to?

The CBN's 15 June 2026 circular requires all payment system participants — banks, mobile money operators, PSPs, and switching companies — to store payment transaction data on servers located in Nigeria by 1 January 2027 (Mondaq).

Why did recent Nigerian bank core migrations cause outages?

The common thread across the 2024 migrations (Zenith to FLEXCUBE, GTBank to Finacle, Sterling to SEABaaS) was underestimating the number and complexity of downstream integrations — NIP, USSD, card switching, mobile/internet banking — that all depend on the core, combined with tight cutover windows that left little room for issues to surface before customers were affected (BusinessDay, Nairametrics).

Is legacy modernization only a banking sector issue in Nigeria?

No. Government MDAs face a parallel challenge, which is why NITDA is driving the Nigeria Government Enterprise Architecture (NGEA) initiative — a Korea-backed program to standardize fragmented, agency-specific legacy systems across ministries and agencies into a shared, interoperable architecture (TechAfrica News).