Hay un número que debería aterrorizar a cada CTO en banca y seguros: del 60 al 80 por ciento. Es la proporción de presupuestos de TI que la mayoría de las instituciones financieras gasta en mantener sistemas legacy — no en construir nuevas capacidades, no en innovar, no en responder a cambios del mercado. Solo en mantener las luces encendidas.
He pasado más de 12 años construyendo y modernizando software empresarial para organizaciones en finanzas, seguros, defensa y energía. He visto plataformas de core banking en COBOL escritas antes de que existiera internet. He visto sistemas de gestión de siniestros donde una sola solicitud de cambio tarda 6 meses y cuesta 200.000€. Y he visto qué pasa cuando las organizaciones finalmente deciden modernizar — tanto los éxitos como los fracasos espectaculares.
Este artículo es la guía que desearía haber tenido cuando empecé a trabajar en modernización legacy. Está escrito para el decisor — el CTO, CIO o VP de Ingeniería — que sabe que sus sistemas deben cambiar pero no está seguro de por dónde empezar.
El Verdadero Costo de Mantener Vivos los Sistemas Legacy
Seré directo: el mayor costo de los sistemas legacy no es el mantenimiento. Es el costo de oportunidad. Cada euro y cada hora-ingeniero gastada parcheando un sistema de 25 años es un euro y una hora que no se invierte en productos digitales que podrían abrir nuevas fuentes de ingresos.
Los Costos Visibles
- Contratos de mantenimiento: Los proveedores legacy cobran tarifas premium por soporte en sistemas fuera de vida. He visto contratos de soporte mainframe de 2-5M€/año.
- Talento especializado: Desarrolladores COBOL y especialistas mainframe se están jubilando más rápido de lo que pueden reemplazarse. Los disponibles cobran 150-250€/hora.
- Sobrecarga de integración: Cada nuevo producto digital necesita conectarse a sistemas legacy mediante integraciones frágiles que se rompen con cualquier cambio.
- Carga de cumplimiento: Cumplir nuevos requisitos regulatorios (DORA, PSD3, Open Banking) sobre arquitectura legacy requiere parches sobre parches.
Los Costos Ocultos
- Velocidad al mercado: Una funcionalidad que a una fintech le toma 2 semanas, a un banco atado a legacy le toma 6-12 meses.
- Atracción de talento: Los mejores ingenieros no quieren trabajar con COBOL. Compites por talento con un stack de 1985.
- Exposición a seguridad: Los sistemas legacy a menudo no soportan protocolos de seguridad modernos.
- Silos de datos: Los datos críticos de negocio están atrapados en sistemas que no se comunican entre sí.
La Opinión de Michele
Les digo a todos los ejecutivos lo mismo: la pregunta no es si pueden permitirse modernizar. La pregunta es si pueden permitirse no hacerlo. Cada mes que retrasan, fintechs e insurtechs están construyendo el futuro que sus clientes eventualmente exigirán.
Las 5 Estrategias de Modernización (Y Cuándo Usar Cada Una)
No existe una única forma correcta de modernizar. El enfoque adecuado depende de la criticidad del sistema, la calidad del código existente y cuánta disrupción pueden tolerar.
1. Encapsular (API Wrapper)
Qué es: Se mantiene el sistema legacy funcionando pero se envuelve con APIs modernas. Mejor para: Sistemas que funcionan correctamente pero son difíciles de integrar. Riesgo: Bajo.
2. Realojar (Lift and Shift a la Nube)
Qué es: Se mueve el sistema legacy de infraestructura on-premise a la nube sin cambiar el código. Riesgo: Bajo a medio.
3. Replataformar (Modernizar el Stack)
Qué es: Se migra la aplicación a una plataforma moderna — por ejemplo, de Oracle on-premise a PostgreSQL cloud-native. Riesgo: Medio.
4. Refactorizar (El Patrón Strangler Fig)
Qué es: Se reemplazan progresivamente partes del sistema legacy con nuevos servicios modernos. Los sistemas viejo y nuevo funcionan en paralelo. Es el enfoque que recomiendo para la mayoría de las plataformas bancarias y de seguros. Riesgo: Medio.
El Strangler Fig en la Práctica
He liderado proyectos donde extrajimos un microservicio a la vez de una plataforma aseguradora monolítica — empezando por el módulo menos crítico para probar el patrón, luego avanzando progresivamente. En 18 meses, el 60% del sistema corría sobre arquitectura moderna. Cero tiempo de inactividad. Cero pérdida de datos.
5. Reemplazar (Reescritura Completa)
Qué es: Se construye un sistema completamente nuevo desde cero. Riesgo: Alto.
Advertencia
La trampa de la reescritura completa: He visto más proyectos de modernización fallar por reescrituras big-bang que por cualquier otra causa. Mi regla: solo reescribe lo que puedas permitirte que falle durante 6 meses.
Framework de Decisión: ¿Qué Estrategia para Cada Sistema?
| Factor | Encapsular | Realojar | Replataformar | Refactorizar | Reemplazar |
|---|---|---|---|---|---|
| La lógica de negocio es sólida | ✓ | ✓ | ✓ | ✓ | — |
| El código es mantenible | ✓ | ✓ | Parcial | — | — |
| Se necesitan UX/APIs modernos | ✓ | — | — | ✓ | ✓ |
| Rango de presupuesto | 200K-500K€ | 100K-300K€ | 300K-800K€ | 500K-2M€ | 1M-5M+€ |
| Timeline | 2-4 meses | 1-3 meses | 3-6 meses | 6-18 meses | 12-36 meses |
Los 7 Errores que Matan los Proyectos de Modernización
- Empezar por el sistema más crítico. Tu ledger de core banking no es donde se aprende. Empieza por un sistema de menor riesgo.
- Subestimar la migración de datos. Típicamente representa el 40-60% del esfuerzo.
- Sin plan de rollback. Cada paso debe ser reversible.
- Ignorar a las personas. Presupuesta al menos 20% para gestión del cambio y formación.
- Elegir tecnología antes de entender el problema. "Nos movemos a microservicios" no es una estrategia.
- Sin entrega de valor incremental. Si no hay valor medible en 6 meses, perderás el patrocinio ejecutivo.
- Tratarlo como un proyecto de TI. Es una transformación de negocio.
Construir el Business Case: Cómo Obtener el Buy-In Ejecutivo
- Cuantifica el costo de no hacer nada: Calcula el costo anual total de mantenimiento. Siempre es 2-3x más de lo que aparece en el presupuesto "oficial".
- Modela el impacto en ingresos: Cada mes de retraso en un producto digital es ingreso perdido.
- Presenta una hoja de ruta por fases: Nunca presentes la modernización como un solo proyecto de 10M€.
La Opinión de Michele
El pitch de modernización más exitoso que he visto seguía esta estructura: "Gastamos 3.2M€/año manteniendo el Sistema X. Con 400K€ podemos modernizar el Módulo A en 4 meses, reduciendo costos de mantenimiento en 600K€/año."
El Rol de la IA en la Modernización Legacy
- Comprensión de código: Herramientas AI pueden leer y explicar código COBOL o RPG legacy.
- Generación automatizada de tests: La IA genera suites de test desde código legacy, creando una red de seguridad.
- Recuperación de documentación: La IA analiza código y esquemas de base de datos para reconstruir reglas de negocio.
- Asistencia a la migración: La IA traduce patrones de código de lenguajes legacy a equivalentes modernos, acelerando el proceso un 30-40%.
En Lasting Dynamics, hemos integrado la IA en nuestro flujo de modernización específicamente para la comprensión de código COBOL y la generación automatizada de tests.
Cómo Se Ve el Éxito: Una Timeline Realista
Así se ve un viaje de modernización bien ejecutado para una institución bancaria o aseguradora de tamaño medio.
| Fase | Duración | Entregable | Impacto de Negocio |
|---|---|---|---|
| Discovery y Assessment | 4-6 semanas | Inventario de sistemas, mapa de dependencias, assessment de riesgo | Imagen clara de lo que tienes y de lo que debe cambiar |
| Capa API (Encapsular) | 2-4 meses | APIs modernas sobre el core legacy | Nuevos productos digitales sin tocar código legacy |
| Migración del Primer Módulo | 3-6 meses | Un dominio de negocio en arquitectura moderna | Prueba de que la modernización funciona; el equipo gana confianza |
| Migración Progresiva | 12-24 meses | Sistemas core movidos incrementalmente | Costos de mantenimiento bajan 30-50%, speed-to-market mejora 3-5x |
| Decommission Legacy | 3-6 meses | Sistemas antiguos apagados | Ahorros completos realizados, stack moderno operativo |
Timeline total: 18 a 36 meses para una transformación completa. Pero el insight clave es que empiezas a entregar valor en el mes 3, no en el mes 36. Cada fase se paga sola.
La Conclusión
La modernización de sistemas legacy no es un proyecto tecnológico. Es una decisión estratégica sobre si tu organización competirá en la próxima década o se desangrará lentamente manteniendo sistemas construidos en la anterior.
La buena noticia: no necesitas hacerlo todo de una vez. Empieza con el assessment. Entiende qué tienes, cuánto te cuesta y qué está en juego. Luego elige la estrategia correcta para cada sistema y ejecuta en fases que entreguen valor medible cada trimestre.
“El mejor momento para empezar a modernizar fue hace cinco años. El segundo mejor es este trimestre.”
— Michele Cimmino