Onshore by January: moving Nigerian payment data home without breaking a pan-African platform

The situation

A payments company headquartered in Lagos offered merchant collections, payouts and card processing in Nigeria, Kenya and Ghana. Nigeria was its largest market. Everything ran in one overseas public cloud region: one set of databases, one event stream, one analytics warehouse. It was simple to run, and every market shared the same release process.

Why now. The Central Bank of Nigeria directed banks, fintechs and other payment service providers to store payment transaction data generated in Nigeria on servers in Nigeria from 1 January 2027, with vendors that handle that data expected to align¹. Legal commentary noted open questions, such as how "generated in Nigeria" applies to transactions that cross borders². Separately, the federal government adopted a National Digital Cloud Policy in 2026, which commentators describe as classifying data and applying residency rules to defined sensitive and sovereign categories rather than all data³⁴. With only months to the deadline, the company needed a plan it could execute, not a debate about interpretation.

What had to be true

• Nigerian payment transaction data at rest and in processing in Nigeria by the deadline, including backups and logs.
• One platform: the same code, pipelines and on-call for every market.
• Every field classified, so engineers know what may leave a country and in what form.
• No lost or duplicated payments during migration.
• Vendors aligned: fraud, card and support tools that touch Nigerian payment data had to follow it.

Architecture

The data flow, end to end

The hard part: one platform, several homes

The tempting answer was to fork: copy the platform into a Nigerian data centre and run it separately. That doubles releases, on-call and drift. Instead, the team adopted a cell design. Each market runs as a cell with identical services, deployed from the same Git repository. The cells differ only in where they run and in the data rules applied to them.

Cluster API made that practical across very different infrastructure. A management cluster declares the workload clusters, whether they run in a Nigerian colocation facility or a public cloud region, and the same tooling creates, upgrades and replaces them⁵. The management cluster holds no payment data, so it can sit outside Nigeria.

The second hard part was the data no one thinks about: logs, traces, backups, support tickets and fraud vendor feeds. The team classified fields into a short list of classes, from public to payment transaction data, and enforced the classes in code: telemetry carried identifiers as tokens, backups were written to onshore storage only, and export pipelines refused unclassified fields. See data contracts for how to make that stick.

How it ran

Migration ran product by product, starting with payouts, which had the simplest flows. Databases were replicated into the Nigeria cell and both copies ran side by side, with reconciliation reports comparing every transaction, before traffic moved. Payment idempotency mattered here; see idempotent payment pipelines. After each cutover, overseas copies and backups were deleted on a recorded schedule.

Key decisions and trade-offs

What I'd do again, and differently

Again: classify before building. The classes answered most of the hard questions, including which vendors were affected. Differently: involve card and fraud vendors earlier. Their onshore options and timelines set the critical path more than our own engineering did. For related patterns, see a multi-cloud Terraform estate, Kubernetes multi-tenancy and where I work.

If you run payments or financial data across African markets, see my fractional CTO work, or analyse your challenge and bring the result to a call.