En un banco, una migración de sistemas no es un evento técnico, sino un riesgo de negocio. Detrás de cada tabla está el dinero de los clientes, y detrás de cada ventana de servicio están el regulador y tu reputación. Por eso una migración de sistemas bancarios sale bien no cuando el sistema nuevo funciona, sino cuando el cliente no notó que algo había cambiado: las transferencias pasan, los saldos cuadran y la app móvil responde igual que ayer.
Por nuestra experiencia, lo difícil no es la conversión de datos en sí, sino mantener el negocio en marcha durante el traslado. Desde 2015 entregamos migraciones de sistemas para clientes de empresa y desarrollo backend en banca, incluido un banco que pertenece a un grupo financiero multinacional, para el que construimos una app móvil de nueva generación. Ahí aprendimos a planificar una migración desde el cliente y desde el rollback, no desde la arquitectura nueva.
¿Por qué es tan arriesgada una migración de sistemas en un banco?
Un banco se diferencia de una empresa cualquiera en tres cosas a la vez: continuidad, cumplimiento e irreversibilidad de sus operaciones. El core funciona las 24 horas, porque los clientes esperan acceso a su dinero a cualquier hora. Los datos financieros tienen que cuadrar al céntimo, y los supervisores exigen pruebas. Una operación contable no se puede «deshacer» como un registro cualquiera: hay que revertirla, y eso ya es de por sí un evento.
Encima está una capa que es fácil olvidar: los sistemas de un banco están profundamente entrelazados. El core habla con el sistema de tarjetas, el antifraude, el reporting regulatorio, la banca móvil y decenas de integraciones acumuladas durante años, así que migrar un elemento plantea preguntas sobre todos los demás. Lo tratamos como cirugía sobre un cuerpo vivo.
¿Cómo planificamos una migración bancaria sin downtime?
Empezamos por un inventario, no por el código. Antes de que nadie toque los datos, mapeamos qué habla con qué, qué flujos son críticos para el cliente y dónde viven los datos que no se pueden perder ni duplicar. Ese mapa nos dice qué puede moverse en segundo plano y qué necesita una ventana ajustada.
En la planificación nos atenemos a unos cuantos principios que más de una vez nos han salvado de un rollback a las 3 de la madrugada:
- diseñamos la migración por etapas en vez de mover todo de una sola vez,
- fijamos criterios duros de éxito y de abandono antes de empezar, no sobre la marcha,
- ensayamos el conjunto sobre una copia de producción, no solo sobre datos de prueba,
- planificamos el rollback como un escenario de primera clase, no como un plan B apuntado en una nota.
¿Qué estrategias de migración usamos: por etapas, en paralelo, rollback?
Rara vez hay una única estrategia correcta: la ajustamos a lo crítico que sea un sistema y a lo doloroso que resultaría su downtime. Lo más habitual es que combinemos tres enfoques dentro de un mismo programa.
Una migración por etapas mueve funciones o grupos de clientes por lotes: el sistema nuevo y el antiguo funcionan en paralelo y desplazamos el tráfico de forma gradual, lo que limita el radio de impacto de cualquier error a una fase en vez de a todo el banco.
Una ejecución en paralelo hace que ambos sistemas procesen durante un tiempo las mismas operaciones para poder comparar resultados. Hasta que cuadran al céntimo, el sistema antiguo sigue siendo la fuente de verdad: nuestra forma favorita de construir confianza antes de un cambio definitivo.
El rollback lo diseñamos siempre. Un cambio definitivo sin una vuelta atrás ensayada es una apuesta, no un plan, así que toda ventana de migración tiene un punto de no retorno definido y un procedimiento de abandono claro antes de él.
¿Cómo garantizamos la integridad de los datos durante la migración de un banco?
Aquí no hay margen para el «casi». La migración de datos de un banco tiene que cuadrar con números: sumas de control, recuentos de registros y saldos en ambos lados deben coincidir antes de que nadie declare el éxito. Por eso construimos un proceso en el que cada lote se verifica de forma automática y las diferencias salen a la luz de inmediato, no tras la queja de un cliente.
En la práctica mantenemos varias capas de control:
- perfilado y limpieza de datos antes de la migración, para no arrastrar basura,
- mapeo de campos y reglas de transformación documentados y versionados, no guardados en la cabeza de alguien,
- conciliación después de cada lote - comparación de sumas, recuentos y saldos clave,
- un rastro de auditoría que muestra de dónde salió cada registro del sistema destino.
¿Cómo probamos y validamos la migración antes de que el cliente la vea?
Probamos una migración tal como se va a ejecutar después: sobre datos y volúmenes cercanos a producción. Un único ensayo no demuestra nada, así que repetimos las pasadas de migración muchas veces hasta que la ejecución se vuelve predecible al minuto y al resultado, y cada ensayo sirve además como prueba del procedimiento de abandono.
Más allá de la corrección de los datos, comprobamos el rendimiento y cómo se comportan las integraciones bajo carga. No basta con que los datos se muevan: tienen que moverse dentro de una ventana que quepa entre la última y la primera operación del cliente, así que ajustamos el tiempo de ejecución hasta que esa ventana sea mínima, idealmente invisible.
¿Cómo mantenemos bajo control la seguridad y el cumplimiento durante la modernización de sistemas heredados?
La modernización de sistemas heredados en banca ocurre bajo la mirada del regulador y de los equipos de riesgo, así que entretejemos el cumplimiento en el proyecto desde el principio en vez de añadirlo al final. Protegemos los datos sensibles en cada paso, restringimos el acceso a lo estrictamente necesario y documentamos el proceso para que se pueda reproducir y justificar ante una auditoría; en entornos que no son de producción trabajamos sobre datos protegidos, no sobre números reales de clientes.
Igual de importante es lo que pasa después: desde el primer día el sistema nuevo tiene que alimentar el reporting regulatorio y los mecanismos de control exactamente igual que el antiguo, así que el cumplimiento es un requisito funcional de la migración y no un proyecto aparte para más adelante.
¿Qué competencias aportamos a un proyecto de migración bancaria?
Formamos el equipo alrededor de la etapa y el sistema concretos, no «por si acaso». En proyectos de migración y backend en banca solemos cubrir perfiles como:
- ingenieros de datos y migración que se ocupan de la conversión y la conciliación,
- desarrolladores backend que construyen e integran sistemas del lado del banco,
- arquitectos que atan el mundo nuevo y el antiguo en un flujo que funciona,
- especialistas de QA y automatización de pruebas que se aseguran de que el resultado cuadra.
Un equipo así puede hacerse cargo por completo de la migración o reforzar a tus propios equipos donde falten manos o conocimiento concreto; qué modelo elegir lo tratamos en nuestro artículo sobre modelos de colaboración en TI.
¿Cómo lo hacemos en RITS?
Lo hacemos como partner nearshore desde Polonia con un recorrido bancario real que se remonta a 2015 - movemos sistemas y datos de forma que el cliente del banco no lo note y el equipo del banco conserve el control del proceso.
Nuestra prueba más clara es el trabajo con un banco perteneciente a un grupo financiero multinacional, para el que además construimos una nueva generación de app móvil. Allí entregamos migración de sistemas para clientes de empresa y desarrollo backend, y esa experiencia entra en cada proyecto posterior. La mayoría de las veces trabajamos como software a medida construido por nuestro equipo y, cuando hay que sumar competencias rápido, como refuerzo de equipo del personal del cliente.
¿Por dónde empezar una migración de sistemas de un banco?
Empieza por una pregunta: ¿qué flujo de cliente no puede caerse ni un minuto? Eso define la estrategia, la duración de la ventana y la forma del rollback. Después inventaría los datos y las integraciones, que suelen decidir el riesgo real, más que el sistema nuevo en sí.
¿Planeas una migración o una modernización de los sistemas de tu banco? Hablemos - planificamos el traslado y formamos un equipo para que el cliente no note nada.
Planifica con nosotros una migración segura de sistemas bancarios