Modernización de Misión Crítica: Cómo evolucionar sistemas legacy como BASE24 clásico sin caídas de servicio

En la infraestructura de pagos, el motor principal nunca duerme. Sistemas legacy como BASE24 clásico han sostenido el peso transaccional de los bancos durante décadas con una confiabilidad insuperable. Sin embargo, cuando el mercado exige pagos inmediatos, APIs abiertas y elasticidad en la nube, el monolito se convierte en un cuello de botella. El reto de la ingeniería actual no es simplemente cambiar el sistema, sino cómo hacerlo sin que el ecosistema pierda un solo milisegundo de disponibilidad.

En el entorno transaccional, operar un switch heredado (legacy) no es un problema de rendimiento bruto, es un problema de agilidad. Estos sistemas fueron diseñados para arquitecturas cerradas y procesamiento predecible. Hoy, con la llegada de las billeteras digitales y los mandatos de pagos en tiempo real (que operan 24/7/365), la necesidad de modernizar es imperativa.

Pero apagar un switch para encender otro no es una opción. Aquí explicamos cómo abordar esta evolución tecnológica desde la trinchera operativa.

La trampa del “Rip and Replace” (y por qué falla)

La estrategia tradicional de modernización suele ser el “Rip and Replace” (arrancar y reemplazar): un enfoque de “Big Bang” donde se intenta sustituir todo el core o el switch de una sola vez. En el papel, promete una pizarra limpia. En producción, es un riesgo inaceptable.

La evidencia industrial demuestra que un alto porcentaje de las transformaciones a gran escala bajo este modelo fracasan o se desvían masivamente de su presupuesto y tiempo. Cambiar el motor de pagos de golpe en un entorno que procesa millones de transacciones diarias es el equivalente a cambiar el motor de un avión en pleno vuelo. La interrupción operativa y el riesgo de indisponibilidad son demasiado altos.

La vía segura: Modernización Progresiva y “Hollow the Core”

En Kuvasz, abordamos la evolución de plataformas críticas como BASE24, UPF o entornos NonStop mediante una estrategia de Modernización Progresiva. Este enfoque permite introducir nuevas capacidades y mover cargas de trabajo hacia arquitecturas modernas (como cloud-native o microservicios) de forma iterativa y con cero impacto productivo.

La técnica fundamental es el “Hollow the Core” (vaciar el núcleo). En lugar de reescribir todo el sistema, desacoplamos funciones específicas. ¿Cómo lo hacemos operativamente?

1. Desacoplamiento en la capa de integración (Orquestación)

Para evitar que el sistema legacy colapse ante las nuevas demandas de inmediatez y el estándar ISO 20022, implementamos una capa de orquestación transaccional en el borde. Soluciones como nuestra plataforma Brizmo actúan como un amortiguador inteligente. Brizmo gestiona la mensajería moderna (APIs, JSON, ISO 20022), resuelve la lógica de enrutamiento y solo se comunica con el switch legacy (como BASE24) en el formato nativo (ISO 8583) cuando es estrictamente necesario. Esto extiende la vida útil del core mientras se moderniza el ecosistema que lo rodea.

2. Replicación Activo-Activo para el “Cutover”

Cuando llega el momento de migrar bases de datos o actualizar de BASE24 clásico a BASE24-eps, la continuidad del servicio depende de la sincronización de los datos. Utilizamos herramientas de replicación de datos en tiempo real (como GoldenGate en entornos Oracle/NonStop). Esto permite mantener ambos sistemas corriendo en paralelo. Se enruta una fracción controlada del tráfico al nuevo sistema; si los SLAs o los tiempos de respuesta se degradan, el tráfico se devuelve inmediatamente al sistema original (rollback).

3. Pruebas automatizadas bajo carga real (El fin del QA manual)

No se puede salir a producción en un entorno 24/7 esperando que el sistema simplemente funcione. La regresión manual es demasiado lenta y propensa a errores humanos. Dentro de nuestra Engineering Acceleration Suite, utilizamos TestRFlow, un framework diseñado específicamente para automatizar pruebas en plataformas BASE24 y Base24-eps. TestRFlow inyecta transacciones reales de forma controlada, comparando los logs y resultados del sistema antiguo con el nuevo. Esto reduce los tiempos de certificación en más de un 90% y, lo más importante, asegura que la nueva arquitectura responda exactamente igual bajo estrés.

Migrando a la nube sin perder el control

Uno de los destinos naturales de la modernización es la nube. Sin embargo, subir un switch transaccional a la nube pública requiere rediseñar la resiliencia y gestionar la latencia.

Para las instituciones que buscan modernizar su switch hacia un modelo OpEx sin lidiar con la complejidad de la infraestructura subyacente, hemos desarrollado Trafpay (Switch as a Service). Esta plataforma en la nube provee procesamiento transaccional en tiempo real bajo SLAs estrictos, gestionado íntegramente por nuestros equipos de Site Reliability Engineering (SRE). Trafpay permite a los bancos y procesadoras operar con tecnología de punta (como Base24-eps o UPF) en un entorno cloud seguro, acelerando el time-to-market y mitigando el riesgo operativo de mantener el hardware legacy.

Modernizar es una capacidad

Modernizar un sistema de misión crítica no es un proyecto con fecha de fin; es una capacidad organizativa que debe ser continua. Extraer funciones de un sistema monolítico como BASE24 clásico y llevarlas hacia arquitecturas modulares o a la nube requiere rigor técnico.

En Kuvasz Solutions, con años de experiencia operando infraestructuras que no pueden fallar, sabemos que la innovación solo tiene valor si el sistema se mantiene en línea. La agilidad se construye asegurando cada capa, probando cada ruta de manera automatizada y realizando transiciones invisibles para el usuario final.

Fuentes utilizadas

• Documentación técnica y guías operativas sobre modernización progresiva (“Hollow the Core”).
• Buenas prácticas de replicación activo-activo y estrategias de cutover/rollback en entornos transaccionales.
• Referencias de arquitectura para orquestación ISO 20022 y convivencia con ISO 8583.
• Capacidades y enfoque de Kuvasz (Brizmo, TestRFlow, Trafpay, SRE).