¿Cuánto tarda realmente una migración de datos de pagos?
Un calendario realista, fase a fase, para trasladar cargas de pago a Nigeria antes del 1 de enero de 2027, con las duraciones que vemos en la práctica y los pasos que no se pueden comprimir.
La directiva del CBN se publicó el 15 de junio de 2026 con fecha de cumplimiento el 1 de enero de 2027. Eso es poco más de seis meses. Las entidades que en septiembre se preguntan "¿cuánto tarda esto?" hacen la pregunta correcta tarde, pero no demasiado tarde. Este artículo ofrece las duraciones por fase que vemos en la práctica para un banco o PSP que traslada cargas de pago desde una nube extranjera a una nube privada nigeriana, e identifica qué pasos pueden ejecutarse en paralelo y cuáles no.
La respuesta corta
Para una entidad mediana con una única plataforma de pagos principal, un puñado de servicios de apoyo y sin dependencias exóticas, una migración completa lleva de 16 a 24 semanas desde la decisión hasta el cut-over. Los grandes bancos con múltiples plataformas, adyacencia a mainframe o servicios gestionados muy personalizados tardan más, y deberían planificar un perímetro aislado de datos de pago como primer hito en lugar de un traslado completo del parque.
El número que importa más que el total es el camino crítico: plazo de entrega del hardware, gestión de claves y cambios de aplicación por dependencias de servicios extranjeros. Todo lo demás encaja alrededor.
Las fases
| Fase | Duración | Qué tiene que ocurrir |
|---|---|---|
| 0. Assessment y mapa de datos | 2–3 semanas | Inventariar cada sistema que toca datos de pago; clasificar como en el país, extranjero o dependiente de extranjero; identificar contratos de proveedor que necesitan cláusulas de localización |
| 1. Arquitectura objetivo y aprovisionamiento | 2–4 semanas | Elegir instalación y patrón; dimensionar cómputo, almacenamiento y red; pedir hardware o reservar colocation; firmar contratos |
| 2. Construcción de la plataforma | 4–6 semanas | Rack, red, virtualización, Kubernetes, almacenamiento, KMS y HSM, identidad, observabilidad, backup; bastionado y runbooks |
| 3. Migración de aplicaciones y datos | 6–10 semanas | Eliminar dependencias de servicios extranjeros; ensayar movimientos de datos; migrar primero servicios no críticos, después servicios de pago; validar |
| 4. Cut-over y desmantelamiento | 1–2 semanas | Sincronización final, ventana de cut-over, hypercare, destruir copias y claves extranjeras, conservar evidencia |
| 5. Evidencia y gobierno | Continuo | Mapa de datos, contratos, prueba de DR, registros de custodia de claves, retención de logs de auditoría; compilar el dossier de cumplimiento |
Las fases 1 y 2 se solapan. La fase 3 comienza en cuanto la plataforma puede alojar una primera carga, no cuando la plataforma está "terminada". La fase 5 se ejecuta durante todo el programa y es la razón para implicar a cumplimiento desde la primera semana.
Fase 0: assessment y mapa de datos (2–3 semanas)
Esta fase es corta, pero es la que las entidades más a menudo se saltan, y saltársela es lo que provoca las sorpresas tardías. El resultado es un mapa de datos: cada almacén de datos, destino de backup, destino de logs, ubicación de claves y plano de control, con un responsable y una clasificación. Las cinco brechas descritas en Cinco lugares por los que sus datos de pago siguen saliendo de Nigeria son la lista de comprobación.
El autodiagnóstico de preparación es una versión de diez minutos del mismo ejercicio y una forma razonable de iniciar la conversación internamente.
Fase 1: arquitectura y aprovisionamiento (2–4 semanas, en parte en paralelo)
Tres decisiones marcan el calendario:
- Instalación. Centro de datos propio, colocation nigeriana o híbrido con perímetro aislado. La colocation en una instalación comercial (OADC, Rack Centre, Kasi Cloud, Galaxy Backbone o Equinix) suele ser lo más rápido porque la potencia, la refrigeración y la conectividad ya existen. Vea Elegir un centro de datos en Nigeria: qué preguntar.
- Hardware. Los plazos de entrega de servidores y almacenamiento son el elemento fijo más largo del plan. Pida en la semana dos, no en la seis. Cuando los plazos sean prohibitivos, algunos operadores ofrecen bare-metal o nube privada alojada que los acortan.
- Segundo emplazamiento. Las réplicas de DR no pueden quedarse en el extranjero. Si un segundo sitio nigeriano forma parte del objetivo, contrátelo ahora, no después del cut-over.
Fase 2: construcción de la plataforma (4–6 semanas)
Una nube privada construida sobre componentes open source (virtualización, Kubernetes, almacenamiento definido por software, KMS autoalojado con sello HSM, identidad autoalojada, pila de observabilidad y sistema de backup) puede levantarse en esta ventana por un equipo que ya lo ha hecho antes. Los equipos que construyen su primera nube privada deberían duplicar la estimación.
El orden importa. La gestión de claves va primero, porque nada puede migrarse hasta que haya un lugar en Nigeria donde custodiar sus claves. La identidad va segunda, porque los ingenieros necesitan autenticarse en la nueva plataforma a través de un proveedor del país. La observabilidad y el backup van antes de que aterrice la primera carga, no después, porque necesita evidencia desde el primer día.
Fase 3: migración de aplicaciones y datos (6–10 semanas)
Es la fase más larga y la de mayor varianza. La varianza procede de las dependencias de servicios extranjeros dentro del código de aplicación:
- Librerías cliente de KMS que hay que reapuntar al servicio del país
- Funcionalidades de bases de datos gestionadas (extensiones propietarias, triggers serverless) que necesitan equivalentes
- Servicios gestionados de mensajería y streaming sustituidos por Kafka o RabbitMQ autoalojados
- Integraciones de identidad trasladadas al proveedor del país
- Exportadores de logs y métricas redirigidos
Cada uno es un cambio de código con un ciclo de pruebas. El orden que recomendamos: migrar primero un servicio interno no crítico para ejercitar la plataforma, después los servicios de apoyo y por último los servicios de pago en orden creciente de radio de impacto.
Para los datos en sí, el método práctico es replicación continua desde el origen extranjero al destino nigeriano con una ventana de cut-over corta, ensayada al menos dos veces. Copia masiva más captura de cambios (CDC) funciona para la mayoría de bases de datos relacionales. El almacenamiento de objetos se mueve con herramientas de copia paralela y validación por checksum. Los ensayos no son opcionales: son la forma de descubrir la tabla de 40 GB con un índice roto o el bucket con la replicación entre regiones todavía activa.
Nuestra solución de repatriación de datos describe los frentes de trabajo en detalle.
Fase 4: cut-over y desmantelamiento (1–2 semanas)
La ventana de cut-over en sí son horas, no semanas. Las semanas son hypercare y desmantelamiento. El desmantelamiento es un paso de cumplimiento, no de limpieza: las copias, réplicas, backups y claves extranjeras deben destruirse, y la destrucción registrarse. Un backup extranjero dejado "por si acaso" es una copia extranjera de datos de pago.
Lo que no se puede comprimir
- El plazo de entrega del hardware. Pida pronto o elija una opción alojada.
- La migración de claves. El recifrado y los cambios de aplicación tardan lo que tardan.
- Dos ensayos de migración. Saltarse el segundo ahorra una semana y cuesta un fin de semana.
- La prueba de DR. Un cut-over sin capacidad de DR probada en el país deja una brecha desde el primer día.
Lo que sí se puede comprimir
- El assessment, si la dirección se compromete con decisiones en lugar de informes
- La construcción de la plataforma, con un equipo experimentado y una arquitectura de referencia
- Las cargas no relacionadas con pagos, que pueden seguir después de la fecha límite si el perímetro de pagos está aislado y cumple
Un inicio en septiembre frente a una fecha límite en enero
Contando desde mediados de septiembre de 2026, quedan unas 15 semanas hasta el 1 de enero de 2027. Es el extremo bajo del rango. Es alcanzable para una entidad que:
- Decide instalación y patrón en dos semanas
- Pide hardware o contrata capacidad alojada de inmediato
- Usa una construcción de plataforma probada en lugar de diseñar desde cero
- Define el primer hito como el perímetro de datos de pago, no todo el parque
Las entidades que no puedan asumir esos cuatro compromisos deben empezar igualmente ahora: un programa documentado con fecha de finalización realista y un perímetro aislado en curso es una posición materialmente mejor ante una inspección que ningún programa en absoluto.
Esto no es asesoramiento legal. Los calendarios anteriores son estimaciones de ingeniería con fines de planificación. Consulte a sus asesores legales y de cumplimiento sobre cómo se aplica la directiva a su entidad.
NuxFamily lleva dos décadas ejecutando migraciones de esta forma para bancos europeos, y aporta arquitecturas de referencia, runbooks y un equipo que ya ha construido la plataforma antes. Si quiere un calendario realista para su parque, empiece por nuestro recurso sobre localización de datos del CBN o contacte con nosotros.
