Modernización de sistemas legacy en banca y retail mexicano: cómo arrancar sin romper la operación

Cuando un CIO mexicano de banca o retail dice "tenemos un proyecto de modernización", normalmente quiere decir tres cosas distintas: hay un core en COBOL o un AS/400 que nadie quiere tocar; hay un ERP heredado (SAP R/3, JD Edwards, Aspel monumental) con personalizaciones de hace 20 años; y hay una maraña de integraciones por SFTP, archivos planos y procesos batch nocturnos que nadie documentó completo. Las tres realidades coexisten y el equipo que las opera empieza a jubilarse.

A mediados de 2024 vemos dos tipos de empresas. Las que siguieron posponiendo la modernización y ahora pagan en agilidad perdida, talento que se va y costos crecientes de mantenimiento. Y las que en los últimos 24-36 meses arrancaron con un patrón disciplinado y empiezan a recoger resultados. Este artículo es la versión corta del marco que estamos usando con los segundos.

Por qué se pospone (y por qué eso ya no funciona)

Las razones para posponer modernización son siempre las mismas:

• "El sistema funciona". Hasta que deja de funcionar y nadie sabe arreglarlo.
• "Es muy caro". Lo es, pero el costo de no hacerlo crece geométricamente.
• "No tenemos presupuesto este año". Ningún año lo tendrás si se trata como un solo gran proyecto.
• "Nos exponemos a romper la operación". Real, pero manejable con patrones probados.

Lo que cambió en 2024 es la combinación de tres presiones que ya no permite seguir esperando:

1. Talento en COBOL, RPG, sistemas viejos: cada vez más caro y escaso. Las generaciones que los dominan se están retirando.
2. Integraciones modernas (open banking, marketplaces, IA conversacional) que asumen APIs decentes; los cores legacy no las tienen.
3. Compliance creciente (CNBV, regulación de datos, requisitos de exportación) que pide trazabilidad y auditoría que los sistemas viejos no entregan.

Tres patrones que funcionan

No hay receta única, pero hay patrones probados que reducen riesgo dramáticamente. Los tres más útiles:

Strangler Fig

Concepto popularizado por Martin Fowler. La idea: en lugar de reemplazar el sistema viejo de un golpe, vas envolviendo funcionalidad con un sistema nuevo, hasta que el viejo queda sin uso y se apaga. Como una higuera estranguladora que cubre un árbol hasta reemplazarlo.

En la práctica:

• Identificas un módulo o capability del legacy (por ejemplo, "consulta de saldo").
• Construyes una versión nueva que cumple la misma función.
• Pones un router (API gateway, proxy) que decide a qué versión va cada request.
• Migras tráfico gradualmente, validando equivalencia.
• Cuando el viejo no recibe tráfico, lo apagas.

Anti-Corruption Layer (ACL)

Cuando construyes lo nuevo y necesitas hablar con el viejo, no dejes que la complejidad del viejo contamine al nuevo. Pon una capa intermedia (anti-corruption layer) que traduce los modelos del legacy a los del sistema moderno. Es código adicional, pero protege la limpieza del nuevo y permite cambios independientes.

Branch by Abstraction

Cuando necesitas cambiar algo crítico que está acoplado a muchos consumidores, en lugar de hacer un big-bang:

1. Introduces una abstracción (interfaz) que envuelve el comportamiento actual.
2. Migras a todos los consumidores a usar esa abstracción.
3. Detrás de la abstracción, sustituyes la implementación.
4. Limpieza final cuando todo funciona.

Aplica especialmente bien a reemplazo de bibliotecas internas, motores de cálculo, integraciones con bases de datos.

Stack moderno típico para reemplazar legacy

Sin volverse evangelista de tecnologías de moda, el stack que vemos consistentemente bien implementado en banca y retail mexicano en 2024:

• APIs REST o GraphQL sobre el core (la fachada moderna).
• Event-driven en los bordes: cuando una transacción ocurre en el core, publica un evento que otros sistemas consumen.
• Kafka, RabbitMQ o servicios manejados (Confluent Cloud, AWS MSK, Azure Event Hubs) para integraciones que antes vivían en SFTP.
• Event sourcing para casos donde necesitas auditoría completa (banca, audit trail regulatorio).
• Containers y orquestación (Kubernetes, ECS, Cloud Run) para los servicios nuevos.
• Observabilidad seria desde el día uno (OpenTelemetry, Datadog, Grafana, Honeycomb).
• CI/CD que permite desplegar varias veces al día, no una vez al mes.

No todo aplica a todos. Bancos con regulación CNBV típicamente combinan nube pública (servicios no críticos) con on-prem o nube privada (cores transaccionales). Retailers con muchos puntos de venta priorizan baja latencia y operación offline en ciertos componentes. La arquitectura específica se diseña, no se compra de catálogo.

Plan en 90 días para arrancar

Lo que recomendamos para empezar sin romper nada:

Semanas 1-3: Discovery

• Inventario de sistemas y datos. No la versión optimista; la real. Quién usa qué, qué integraciones existen, dónde viven los datos críticos.
• Mapa de capabilities del negocio (no de tecnologías). Qué cosas hace tu empresa: cobranza, cotización, alta de cliente, surtido, devolución, etc.
• Heatmap de qué capabilities están más bloqueadas por el legacy y cuáles bloquean más al negocio.

Semanas 4-6: MVP de migración

• Elige una capability de impacto medio y riesgo bajo para arrancar (la trampa es siempre arrancar con la más complicada).
• Diseña la versión nueva, el router, la estrategia de cutover.
• Identifica métricas de éxito (latencia, error rate, equivalencia funcional con el viejo, costo).

Semanas 7-12: Implementación y aprendizaje

• Construyes la nueva versión.
• Pones el router con feature flags: empiezas con 1% del tráfico, escalas si todo va bien.
• Comparas resultados (shadow mode antes de cutover).
• Publicas postmortem honesto: qué funcionó, qué no, qué repetir.

Ese primer ciclo te da plantilla para los siguientes. La regla de oro: nunca arranques migración mayor sin completar al menos un ciclo strangler completo en algo pequeño. Aprender el patrón en algo de bajo impacto evita aprenderlo en lo crítico.

Errores típicos que vemos

Tres patrones que aparecen una y otra vez:

Big bang. Decidir reemplazar el core en 18 meses con un equipo separado, sin tráfico real hasta el día del cutover. Si tu plan tiene una sola fecha grande de "go-live", revisa.

Construir el reemplazo sin entender el legacy. El sistema viejo casi siempre tiene reglas de negocio embebidas que nadie escribió. Si las descubres en producción, la migración te explota.

Subestimar las integraciones. El sistema central rara vez es el problema: lo difícil son los 40 sistemas que hablan con él vía SFTP, copybooks y stored procedures de los 90s.

Lecciones de proyectos mexicanos en 2024

Tres lecciones que aplican a la mayoría de los casos:

• El equipo que opera el legacy es el activo más valioso del proyecto. Inclúyelo desde el día uno. Sus 20 años de conocimiento valen más que cualquier consultor externo.
• Métricas de progreso por tráfico migrado, no por features entregados. Lo que cuenta es cuánta operación real corre en lo nuevo.
• Reservar 20-30% del esfuerzo a observabilidad y reversa de cutover. Son las dos formas más rápidas de cancelar un proyecto cuando faltan.

---

¿Quieres armar tu plan de modernización? Hagamos el assessment. En ALCA acompañamos discovery, diseño de patterns y entrega de migraciones legacy en banca y retail mexicano. Agenda una sesión con nuestro equipo.