Home›Perspectivas›Artículos›Interventoría técnica en migraciones del core bancario: por qué una segunda mirada reduce el riesgo

Blog · Consultoría · Banca

Interventoría técnica en migraciones del core bancario: por qué una segunda mirada reduce el riesgo

Cuando el core de un banco cambia de servidor, cada ventana de corte es una decisión de alto impacto. Lo que aprendimos como interventores técnicos de la migración a IBM Power10 del banco más grande de Colombia.

Un sistema financiero grande, un core que no puede fallar

Los establecimientos bancarios colombianos administran cerca de $1.000 billones de pesos en activos, según el ranking de las empresas más grandes del país publicado por La República con cifras de cierre de 2024. Buena parte de esa operación pasa, en algún momento, por plataformas de misión crítica como IBM i sobre IBM Power, que los grandes bancos de América Latina eligen por su estabilidad y su capacidad para procesar altos volúmenes transaccionales.

Renovar esas plataformas es necesario: cada generación de procesadores trae más capacidad, mejor eficiencia y nuevas funciones de seguridad. IBM, por ejemplo, destaca en Power10 el cifrado transparente de memoria y cuatro veces más motores criptográficos por núcleo que Power9. Pero migrar no es solo cambiar de caja. La partición del core arrastra consigo almacenamiento, red SAN, multipathing, zonificación y replicación hacia el centro de datos alterno. Un error en cualquiera de esas piezas puede arruinar una ventana de corte perfectamente planeada en el lado del cómputo.

Qué es (y qué no es) una interventoría técnica

El interventor técnico es un tercero independiente que revisa, supervisa, analiza y alerta sobre el trabajo de quien ejecuta el proyecto. Su valor está en la independencia de criterio: no construye la solución ni compite con el ejecutor, y tampoco reemplaza al dueño del proyecto en la toma de decisiones.

En el caso que nos ocupa, el modelo quedó definido desde el principio:

  • El ejecutor hace la migración, mantiene los planes de migración, cutover y rollback, y entrega evidencias.
  • El interventor revisa esas evidencias, identifica riesgos, emite alertas y conceptos técnicos sustentados.
  • El banco decide: acepta, rechaza, da el go/no-go y libera hitos.

Esa separación de roles parece obvia en el papel, pero en la práctica es lo que evita dos extremos igualmente costosos: un interventor que se vuelve un obstáculo burocrático y uno que termina haciendo el trabajo del ejecutor sin asumir su responsabilidad.

La interventoría no está para frenar la migración, sino para que el banco llegue a cada ventana de corte sabiendo exactamente qué está aprobando.
Equipo de Consultoría e Infraestructura, Redsis

Entrar a un proyecto que ya va en 70 %

Un rasgo particular de este servicio fue el momento: la migración ya estaba aprobada y cerca del 70 % ejecutada, con 20 particiones migradas previamente a Power10 y una meta de 54 % más de capacidad de cómputo para el core. Faltaba lo más delicado, la partición del core bancario, y el servicio debía entregar valor en un solo mes.

Llegar tarde a un proyecto tiene una ventaja y un riesgo. La ventaja es que hay historia: pruebas ejecutadas, lecciones aprendidas y un equipo que conoce la plataforma. El riesgo es asumir que todo lo anterior está bien sin verificarlo. Por eso la primera tarea fue acordar con el banco los criterios técnicos contra los que se iban a revisar las evidencias, y levantar una matriz de la información requerida frente a la recibida.

Seis prácticas que hacen útil una interventoría técnica

1. Acordar los criterios antes de opinar

Un concepto técnico solo es defendible si se sabe contra qué se compara. Si el banco tiene criterios formales de aceptación, se adoptan; si no, el interventor propone un conjunto estándar para migraciones IBM Power y lo deja acordado desde la primera o segunda semana.

2. Llevar la cuenta de la información

Una matriz de información requerida y recibida parece un detalle administrativo, pero es la mejor defensa contra las zonas grises. Si una evidencia no llegó, queda registrado, y el riesgo se gestiona en lugar de ignorarse.

3. Mirar más allá del servidor

En una migración de core, el cómputo suele ser la parte mejor documentada. Almacenamiento, SAN, multipathing, zonificación y replicación hacia DR merecen la misma atención, porque es ahí donde suelen esconderse las sorpresas de la noche de corte.

4. Revisar el rollback con la misma seriedad que el cutover

Todo el mundo revisa el plan para avanzar. Pocos prueban con el mismo rigor el plan para devolverse. Un rollback claro, con criterios de activación y tiempos realistas, es lo que permite tomar la decisión de ir a la ventana con tranquilidad.

5. Dejar todo por escrito, y a tiempo

En este servicio se definieron 15 entregables formales: acta de inicio, plan de trabajo, informe de línea base, matriz de riesgos con actualización semanal, tablero de seguimiento de indicadores, informes semanales, conceptos técnicos por evento, alertas formales, concepto de conformidad sobre la ventana de cutover, informe final, matriz final de riesgos y hallazgos, recomendaciones y acta de cierre. La trazabilidad es lo que convierte una opinión en un insumo de gobierno.

6. Estar presente cuando importa

Buena parte del trabajo de revisión puede hacerse de forma remota. Pero en los hitos críticos, como la sesión preparatoria del cutover o la propia ventana, la presencia en sitio marca la diferencia en la calidad de la conversación técnica.

Qué gana el banco

Una interventoría técnica bien planteada no agrega capas, agrega claridad. El banco llega a cada decisión de corte con un concepto independiente, sustentado y documentado; el ejecutor recibe retroalimentación temprana sobre vacíos que es mejor cerrar antes que durante la ventana; y la organización queda con un registro de riesgos, hallazgos y recomendaciones útil para las siguientes migraciones.

Todo eso sin tocar la cadena de mando: la decisión final siempre fue del banco, que es exactamente donde debe estar.

¿Por dónde empezar?

Si su entidad tiene en curso una migración de plataforma crítica, sea de servidores, almacenamiento o centro de datos, vale la pena preguntarse quién está revisando las evidencias con independencia antes de cada ventana. En Redsis combinamos más de 25 años de experiencia en infraestructura de misión crítica para la banca latinoamericana con un conocimiento profundo de IBM Power e IBM i, y ponemos ese conocimiento al servicio del banco, no de la herramienta.

Lea el caso completo

Conozca cómo Redsis dio aseguramiento técnico independiente a la migración del core del banco más grande de Colombia a IBM Power10.

Ver caso de éxitoHablar con un especialista