How to Migrate a Live Payment Platform Without Downtime - Lessons from Francophone West Africa

Payment platforms operating in Senegal, Côte d'Ivoire, Mali, and across the WAEMU zone face a migration challenge unlike most markets in the world. Mobile money is not a convenience layer here - for a significant portion of the population it is the primary financial infrastructure. Wave in Senegal, Orange Money and MTN MoMo in Côte d'Ivoire, Free Money across the zone: these platforms process transactions for users who have no bank branch to fall back on. A migration that takes your platform offline for two hours on a Wednesday afternoon in Dakar or Abidjan is not a scheduled inconvenience. It is a hard stop on economic activity for people with no alternative.

This constraint shapes everything about how a migration must be engineered.

Why WAEMU payment platforms are migrating now

Most platforms built in the WAEMU zone between 2016 and 2021 were not designed for what they are processing today. Mobile money penetration in Côte d'Ivoire is among the highest in the world. Wave's entry into Senegal with near-zero fees compressed margins and drove volume growth that most incumbent platforms were not architected to absorb.

Three pressures have converged to make migration unavoidable:

Volume outpaced architecture. A platform designed for 30,000 daily transactions is now handling 400,000. The original synchronous architecture, mutable ledger, and single-region database deployment was not built for this load. Authorization rates drop under peak volume. Reconciliation takes longer each month. The signs are visible - they are just not always connected to the root cause.

BCEAO interoperability requirements. The Banque Centrale des États de l'Afrique de l'Ouest has pushed interoperability mandates across the zone. Platforms now must connect to GIM-UEMOA, support cross-operator transfers, and maintain audit trails that satisfy BCEAO reporting standards. Point-to-point integrations built before these requirements are now liabilities.

Cross-border corridor growth. WAEMU's single currency zone makes intra-regional transfers relatively straightforward, but corridors to France, Spain, Italy, and the Gulf carry significant volume - particularly from the Senegalese and Ivorian diaspora. These corridors have their own upstream dependencies, compliance requirements, and latency profiles that a legacy architecture was not built to manage cleanly.

The strangler fig: the only viable approach in this market

A big-bang migration - schedule a maintenance window, cut over, go live - does not work in the WAEMU context. There is no 3am low-traffic window large enough to safely migrate a complex payment system. Wave processes transactions around the clock. Orange Money agents in rural Côte d'Ivoire operate early morning and late evening. The window does not exist.

The strangler fig pattern is the only viable approach. You build the new architecture alongside the old one, route traffic incrementally, and decommission the old system piece by piece. Nothing goes dark.

Applied specifically to WAEMU platforms:

Phase 1: Dual-write the ledger. Before any traffic moves to the new system, every transaction writes to both the legacy ledger and the new event-sourced ledger simultaneously. Run this for four to six weeks. Compare balance outputs daily. BCEAO reconciliation reporting must be runnable from the new ledger and produce identical figures to the old one before any traffic shifts.

Phase 2: Read operations move first. Balance enquiries, transaction history, and reconciliation exports move to the new system while all writes still go through the legacy path. This validates the new system under real read load with zero risk to transaction processing.

Phase 3: Route low-risk transaction types first. Internal wallet-to-wallet transfers between users on the same platform carry the lowest risk - if something goes wrong, it affects a closed loop and is straightforward to reverse. Route these through the new processing path first and monitor for two to four weeks before expanding.

Phase 4: Rail-by-rail cutover. Migrate one operator integration at a time. Complete the Wave integration migration and validate it fully before touching the Orange Money integration. Each rail is a separate workstream with its own validation criteria and rollback procedure.

Phase 5: Decommission only after full validation. The old system stays running until 100% of traffic has been on the new system for a sustained period with clean reconciliation at every step.

WAEMU-specific complications that standard playbooks miss

The standard zero-downtime migration playbook was written for markets with different characteristics. Several WAEMU-specific realities require specific engineering decisions.

USSD session continuity. A meaningful share of transactions in Senegal and rural Côte d'Ivoire still flow through USSD. A USSD session carries state differently from an HTTP API call. If a user is mid-session during a processing layer cutover, the session must complete on whichever system started it. Migrating the processing layer beneath an active USSD session without handling this creates orphaned sessions and incomplete transactions that do not reconcile cleanly.

Operator API behaviour vs documentation. Wave, Orange Money, and MTN MoMo API behaviour in production is not always consistent with their published documentation. Timeout handling, idempotency key behaviour, and error code meanings are discovered through production traffic, not test environments. The new architecture must be built to handle what these APIs actually do, not what the documentation says they do. This is only learned through progressive exposure to real traffic - which is the argument for the incremental cutover approach.

Related: Building Idempotent Payment APIs

CFA franc settlement timing. The XOF settlement cycle within the BCEAO system has specific timing constraints that affect how a dual-processing architecture must handle end-of-day reconciliation. Both systems must close their daily positions cleanly. A migration that creates ambiguity about which system holds the authoritative position at settlement time creates regulatory exposure, not just an operational problem.

GIM-UEMOA interoperability layer. Platforms that connect to the GIM-UEMOA interbank network have an additional integration that is not straightforward to migrate in isolation. GIM-UEMOA connectivity is a shared infrastructure layer used by multiple institutions, and changes to how your platform connects to it require coordination with GIM-UEMOA directly, not just internal engineering work.

The instrumentation you need before any traffic moves

Zero-downtime migration is not possible without real-time visibility into what is happening on both systems simultaneously. Before Phase 3 starts:

• Authorization rate tracked per operator and per transaction type, not in aggregate - a degradation on the Wave rail is invisible in aggregate figures
• Latency at p95 and p99 on the new processing path from the moment it receives traffic
• Reconciliation running in parallel on both systems with automated alerting on any discrepancy
• Position comparison between old and new ledger running continuously during the dual-write phase
• Rollback procedure for each phase documented, tested in staging, and executable in under 15 minutes

Related: Observability for Transaction-Critical Payment Systems

Rollback is not a safety net - it is a design constraint

If a phase cannot be rolled back quickly, it cannot be run on a live system. This is a design constraint, not a precaution. It means the migration architecture must maintain dual-write capability throughout, which is additional engineering work. It also means every cutover decision is reversible, which is what allows the migration to proceed at all.

Realistic timeline for a WAEMU platform migration

A medium-complexity WAEMU payment platform - connecting three to five operator rails, processing 100,000 to 500,000 daily transactions, with BCEAO reconciliation reporting requirements - takes 18 to 24 weeks to migrate safely. Attempts to compress this are the most common cause of migration failures in this market.

The build phase takes six to eight weeks. The validation phases - dual-write validation, read migration, progressive traffic cutover - take the rest. This is where the actual risk is managed, and it cannot be rushed without accepting risk that the market does not allow.

---

Migrating a live payment platform in the WAEMU zone requires an engineering approach built around the specific constraints of the market - BCEAO requirements, USSD session continuity, operator API realities, and zero tolerance for downtime. Start with a scoped architecture assessment before committing to a migration approach.

Our payment platform re-architecture service covers live migration planning and execution for platforms that cannot accept downtime during the transition.