Skip to content
CBN data localisation deadline, 1 Jan 2027: 99d 00h 31m left.Talk to us →
NuxFamily

Move payment data from AWS, Azure or GCP to a Nigerian private cloud, wave by wave, without stopping payments.

Bring your payment data home without a single failed transaction

A wave-based migration from the hyperscaler to a private cloud in Nigeria, with coexistence, defined rollback and regulatory evidence at every step. Run by people who have done this in production, in banking, under audit.

Book a Discovery SessionSee the CBN compliance path

The challenge

The challenge

The CBN directive sets 1 January 2027 as the date by which payment transaction data must be stored and processed in Nigeria, with no replication abroad. Most institutions have that data across dozens of managed services in a foreign cloud region: databases, queues, caches, object storage, logs and the identity systems that guard them. The statement is context, not legal advice.

The journey with NuxFamily

  1. 01Assess
  2. 02Design
  3. 03Build
  4. 04Migrate
  5. 05Operate
  6. 06Evolve

Every family is delivered through the same six-stage journey, with official 24×7 support and knowledge transfer built in.

Our approach

How we migrate

  1. 01

    Discover and map

    Automated discovery of every data store, queue and bucket that touches payment data. Classification, owner, dependency graph and residency status recorded in a catalogue that becomes the evidence base.

  2. 02

    Plan the waves

    Systems grouped into waves by dependency and risk. Early waves prove the method on lower-risk services; core processing moves once replication and rollback have been rehearsed.

  3. 03

    Prepare the landing zone

    Target services stood up in the Nigerian private cloud with matching versions and configuration: PostgreSQL, Kafka, Valkey, S3-compatible storage, Kubernetes namespaces and secrets.

  4. 04

    Replicate and coexist

    Logical replication for databases, mirrored topics for Kafka, dual-write or replay for caches, object sync for storage. Both sides run in parallel until parity is verified.

  5. 05

    Cut over with rollback

    Each wave is switched during a short, agreed window with a checked rollback path. The hyperscaler side stays warm until sign-off, then is purged and the purge is documented.

  6. 06

    Evidence and close

    Residency report per system, key custody in Nigeria, audit logs and backup locations verified. The compliance team receives a dossier, not a slide.

Outcomes

Outcomes

0

payment downtime

Coexistence and per-wave cutover mean the payment service never stops for the migration.

< 30 min

cutover window per wave

Replication runs ahead of time; the switch itself is a short, rehearsed change.

100 %

residency evidence

Every migrated system carries its own proof of location, backup and key custody.

Use cases

Use cases

Use case 01

Payment processing from AWS to a Nigerian private cloud

A payment service provider runs its switch integration, ledger and notification services on EKS, RDS PostgreSQL, MSK and ElastiCache in eu-west-1. It must be fully in Nigeria before the deadline with no interruption to merchants.

Technologies

  • OpenShift
  • PostgreSQL
  • Patroni
  • Apache Kafka
  • MirrorMaker 2
  • Valkey
  • MinIO
  • OpenMetadata
  • Argo CD

Expected outcome

All payment data, processing and backups in Nigeria, with merchants unaware a migration took place.

Metric: 0 failed transactions across 3 waves

Payment processing from AWS to a Nigerian private cloudA payment service provider runs its switch integration, ledger and notification services on EKS, RDS PostgreSQL, MSK and ElastiCache in eu-west-1. It must be fully in Nigeria before the deadline with no interruption to merchants. All payment data, processing and backups in Nigeria, with merchants unaware a migration took place.1Catalogue every dependencyOpenMetadata2Stand up target servicesOpenShift · PostgreSQL · Kafka3Replicate databasesPostgreSQL logical replication4Mirror event streamsMirrorMaker 25Wave 1: notificationsArgo CD6Wave 3: ledger and switch7Purge and evidence
  1. 1Catalogue every dependency. Services, schemas, topics and buckets mapped with data classification and residency status.
  2. 2Stand up target services. PostgreSQL with Patroni, Kafka, Valkey and MinIO deployed on Kubernetes in a Lagos data centre.
  3. 3Replicate databases. Logical replication from RDS to on-prem PostgreSQL, running until lag is near zero and row counts match.
  4. 4Mirror event streams. Topics mirrored from MSK to the local Kafka cluster; consumers migrated with offset translation.
  5. 5Wave 1: notifications. Low-risk services switched first to prove the runbook and the rollback path.
  6. 6Wave 3: ledger and switch. Core processing cut over in a 20-minute window with dual verification before the old side is frozen.
  7. 7Purge and evidence. AWS resources deleted, snapshots verified gone, dossier issued with residency and backup proof.

Use case 02

Cloud data warehouse to an on-prem lakehouse

Built on these families

Built on these families

FAQ

FAQ

It depends on the number of systems and how tangled their dependencies are. The assessment produces a wave plan with dates. Early waves start within weeks of the landing zone being ready; the deadline drives the ordering of the rest.

Over two decades

Built by the team behind the platforms of Santander, ING, Bankinter, Mapfre and Inditex

More than twenty years designing, building and operating private clouds for institutions that cannot afford to fail, and a delivery model where we stay with you from assessment to operation.

See our track record

20+

Years building private clouds

40+

Private clouds delivered

Start with a Discovery Session

Sixty minutes with an architect who has delivered this before. No slideware.

No mailing lists, no automated follow-ups. We reply personally within one working day.