Recibí la llamada a las 9 de la mañana. El director de operaciones quería «modernizar el código». Llevaban quince años con un sistema en COBOL que procesaba transacciones sin un solo fallo en producción. Mi respuesta fue incómoda: «¿Por qué?» Nadie tenía una respuesta clara. Solo sabían que COBOL sonaba viejo, y viejo significa inseguro en la mentalidad corporativa actual. Pasé los siguientes dieciocho meses ayudándoles a descubrir por qué esa suposición era peligrosamente incorrecta.
El costo oculto de la modernización
Las migraciones de sistemas heredados son máquinas de generar deuda técnica, no de reducirla. Durante el proyecto que mencioné, nos encontramos con algo inesperado: el equipo que mantenía el COBOL conocía cada rincón del negocio. Documentación formal: ninguna. Pero en sus cabezas vivía la lógica de veinte años de evolución empresarial. La decisión de cambiar de plataforma no era técnica. Era política.
El 67% de las migraciones de sistemas críticos sufren retrasos mayores al 40% de lo planificado. La razón rara vez es la tecnología destino. Es la brecha entre lo que el nuevo equipo entiende del dominio del negocio y lo que el antiguo equipo sabe por intuición después de décadas.
Lo que descubrimos cuando empezó a fallar
Tres meses dentro de la migración, el nuevo sistema en Java empezó a procesar órdenes de forma distinta. No había errores de compilación. El código pasaba todos los tests unitarios. Pero la lógica de redondeo de precios no se comportaba igual en casos extremos que ocurrían una vez cada mil transacciones. El sistema legacy lo manejaba porque alguien, hace doce años, había ajustado una regla específica para un cliente importante. Esa regla nunca llegó a la especificación técnica. Existía solo en una nota manuscrita archivada en un cajón.
Encontramos quince casos así durante la implementación. Quince micro-reglas de negocio que vivían invisibles dentro del código original. El nuevo equipo no podía replicarlas sin entender la historia detrás de cada una.
La alternativa que casi nadie considera
La industria nos vende que la solución es reescribir. Burn it down. Start fresh. Es el discurso de las empresas de consultoría porque les permite facturar durante años. Pero existe una tercera vía que es más lenta, menos glamorosa, y funciona mejor: la modernización por capas.
En lugar de reemplazar todo, extrajimos servicios específicos del COBOL dentro de APIs REST. Migramos una transacción a la vez, validando en paralelo contra el sistema antiguo. El proceso tardó más. Fue aburrido. Nadie en una conferencia de tecnología se habría emocionado escuchando sobre ello. Pero después de tres años, el sistema legacy estaba completamente desmantelado, sin un solo incidente en producción.
El equipo nuevo aprendió la lógica de negocio mientras integraba pieza a pieza. El equipo antiguo documentó cada regla que descubrían mientras migraban. El resultado no fue un nuevo sistema perfecto. Fue uno que funcionaba porque entendía la realidad del negocio, no solo los requisitos teóricos.
Por qué la edad del código no es el problema
COBOL seguirá funcionando dentro de veinte años. Java puede desaparecer en media década si el mercado decide que algo más eficiente lo reemplaza. La fragilidad no está en el lenguaje. Está en el conocimiento que vive solo en las cabezas de las personas. Un sistema de cinco años sin documentación es tan riesgoso como uno de treinta.
La verdadera pregunta antes de cualquier migración no debería ser: «¿Es moderno?» Debería ser: «¿Qué entendemos del negocio que soporta?» Si la respuesta es «poco», migrar lo va a hacer más visible, más costoso, y probablemente lo arruinará.
Preguntas frecuentes
¿Cuándo es realmente necesario migrar un sistema legacy?
Cuando el costo de mantenerlo supera significativamente el costo de migrar, y cuando los expertos que lo entienden se van a jubilar sin haber transferido su conocimiento. No es una decisión técnica. Es una decisión de riesgo operativo.
¿Pueden los sistemas antiguos ser tan seguros como los nuevos?
Sí, si están correctamente mantenidos y documentados. La seguridad no viene del año de lanzamiento del lenguaje. Viene de buenas prácticas, auditorías regulares y equipos competentes que entienden lo que protegen.
¿Qué alternativa hay a la reescritura completa?
La modernización incremental por servicios es viable para la mayoría de sistemas críticos. Requiere más disciplina y paciencia que una reescritura, pero reduce drásticamente el riesgo de perder funcionalidad invisible.
Antes de llamar a una empresa de consultoría con propuestas de transformación digital, considera si el problema real es el código o el conocimiento que falta documentar.
