How long does a payments data migration really take?

The CBN directive was published on 15 June 2026 with a compliance date of 1 January 2027. That is a little over six months. Institutions that are asking "how long does this take?" in September are asking the right question late, but not too late. This article gives the phase durations we see in practice for a bank or PSP moving payment workloads from a foreign cloud into a Nigerian private cloud, and identifies which steps can run in parallel and which cannot.

The short answer

For a mid-sized institution with a single core payment platform, a handful of supporting services, and no exotic dependencies, a complete migration runs 16 to 24 weeks from decision to cut-over. Large banks with multiple platforms, mainframe adjacency or heavily customised managed services take longer, and should be planning an isolated payment-data perimeter as a first milestone rather than a full estate move.

The number that matters more than the total is the critical path: hardware lead time, key management, and application changes for foreign-service dependencies. Everything else fits around those.

The phases

Phase	Duration	What has to happen
0. Assessment and data mapping	2–3 weeks	Inventory every system touching payment data; classify as in-country, foreign, or foreign-dependent; identify supplier contracts needing localisation clauses
1. Target architecture and procurement	2–4 weeks	Choose facility and pattern; size compute, storage and network; order hardware or reserve colocation; sign contracts
2. Platform build	4–6 weeks	Rack, network, virtualisation, Kubernetes, storage, KMS and HSM, identity, observability, backup; hardening and runbooks
3. Application and data migration	6–10 weeks	Remove foreign-service dependencies; rehearse data moves; migrate non-critical services first, then payment services; validate
4. Cut-over and decommission	1–2 weeks	Final sync, cut-over window, hypercare, destroy foreign copies and keys, retain evidence
5. Evidence and governance	Continuous	Data map, contracts, DR test, key custody records, audit-log retention; compile the compliance pack

Phases 1 and 2 overlap. Phase 3 begins as soon as the platform can host a first workload, not when the platform is "finished". Phase 5 runs throughout and is the reason to involve compliance from week one.

Phase 0: assessment and data mapping (2–3 weeks)

This phase is short but it is the one institutions most often skip, and skipping it is what causes late surprises. The output is a data map: every datastore, backup destination, log destination, key location and control plane, with an owner and a classification. The five gaps described in Five places your payment data is still leaving Nigeria are the checklist.

The readiness assessment is a ten-minute version of the same exercise and is a reasonable way to start the conversation internally.

Phase 1: architecture and procurement (2–4 weeks, partly parallel)

Three decisions drive the calendar:

1. Facility. Own data centre, Nigerian colocation, or hybrid with an isolated perimeter. Colocation in a commercial facility (OADC, Rack Centre, Kasi Cloud, Galaxy Backbone or Equinix) is usually fastest because power, cooling and connectivity already exist. See Choosing a data centre in Nigeria: what to ask.
2. Hardware. Server and storage lead times are the longest fixed item on the plan. Order in week two, not week six. Where lead times are prohibitive, some operators offer bare-metal or hosted private cloud that shortens this.
3. Second site. DR replicas cannot remain abroad. If a second Nigerian site is part of the target, procure it now, not after cut-over.

Phase 2: platform build (4–6 weeks)

A private cloud built on open-source components (virtualisation, Kubernetes, software-defined storage, a self-hosted KMS with HSM seal, self-hosted identity, an observability stack and a backup system) can be stood up in this window by a team that has done it before. Teams building their first private cloud should double the estimate.

The order matters. Key management goes first, because nothing can be migrated until there is somewhere in Nigeria to hold its keys. Identity goes second, because engineers need to authenticate to the new platform through an in-country provider. Observability and backup go before the first workload lands, not after, because you need evidence from day one.

Phase 3: application and data migration (6–10 weeks)

This is the longest phase and the one with the most variance. The variance comes from foreign-service dependencies inside application code:

• KMS client libraries that must be re-pointed to the in-country service
• Managed database features (proprietary extensions, serverless triggers) that need equivalents
• Managed messaging and streaming services replaced with self-hosted Kafka or RabbitMQ
• Identity integrations moved to the in-country provider
• Log and metrics exporters re-targeted

Each of these is a code change with a test cycle. The order we recommend: migrate a non-critical internal service first to exercise the platform, then supporting services, then payment services in order of increasing blast radius.

For the data itself, the practical method is continuous replication from the foreign source to the Nigerian target with a short cut-over window, rehearsed at least twice. Bulk copy plus change-data-capture works for most relational databases. Object storage moves with parallel copy tools and checksum validation. The rehearsals are not optional: they are how you discover the 40 GB table with a broken index or the bucket with cross-region replication still enabled.

Our data repatriation solution describes the workstreams in detail.

Phase 4: cut-over and decommission (1–2 weeks)

The cut-over window itself is hours, not weeks. The weeks are hypercare and decommissioning. Decommissioning is a compliance step, not housekeeping: foreign copies, replicas, backups and keys must be destroyed, and the destruction recorded. A foreign backup left "just in case" is a foreign copy of payment data.

What cannot be compressed

• Hardware lead time. Order early or choose a hosted option.
• Key migration. Re-encryption and application changes take the time they take.
• Two migration rehearsals. Skipping the second rehearsal saves a week and costs a weekend.
• DR test. A cut-over without a tested in-country DR capability leaves a gap on day one.

What can be compressed

• Assessment, if leadership commits to decisions rather than reports
• Platform build, with an experienced team and a reference architecture
• Non-payment workloads, which can follow after the deadline if the payment perimeter is isolated and compliant

A September start against a January deadline

Counting from mid-September 2026, there are roughly 15 weeks to 1 January 2027. That is at the low end of the range. It is achievable for an institution that:

• Decides on facility and pattern within two weeks
• Orders hardware or contracts hosted capacity immediately
• Uses a proven platform build rather than designing from scratch
• Scopes the first milestone as the payment-data perimeter, not the whole estate

Institutions that cannot make those four commitments should still start now: a documented programme with a realistic completion date and an isolated perimeter in progress is a materially better position at inspection than no programme at all.

---

This is not legal advice. The timelines above are engineering estimates for planning purposes. Consult your legal and compliance advisers on how the directive applies to your institution.

NuxFamily has run migrations of this shape for European banks for two decades, and brings reference architectures, runbooks and a team that has built the platform before. If you want a realistic timeline for your estate, start with our CBN data localisation resource or contact us.