Cuando se habla de IA y sistemas legacy, el debate suele plantearse como una carrera: qué modelo reescribe más código y más rápido. Creo que la pregunta está mal enfocada. En una migración, lo difícil casi nunca es escribir el código nuevo, sino entender el viejo.
Un sistema con décadas de evolución acumula reglas de negocio que solo existen en el código, integraciones que nadie documentó y dependencias ocultas que aparecen cuando el proyecto ya va muy avanzado. Y no basta con mantener la funcionalidad: hay que preservar los contratos reales, como formatos, semántica de los datos o efectos colaterales. Ahí es donde las arquitecturas agénticas están cambiando de verdad las cosas.
Índice de temas
Los agentes leen el código que nadie tiene tiempo de leer
Un agente puede recorrer todo el código fuente, identificar patrones y encontrar dependencias que a un equipo le costaría muchísimo mapear a mano. Lo que estamos viendo en el sector es que el mayor ahorro no está en el trabajo repetitivo, sino en este discovery. En nuestros proyectos, alrededor del 80% de las dudas que surgían en esa fase las resolvieron los agentes.
Pero el discovery humano sigue siendo imprescindible: alguien tiene que validar qué significa cada regla para el negocio. Y una vez entendido el sistema, los agentes generan la documentación, con los pasos a seguir, y los tests que orientan toda la migración.
Sin tests no hay migración
Lo que funciona es invertir primero en una batería de tests que permita comprobar que el sistema nuevo se comporta igual que el antiguo, y en pequeños refactors del código legacy. Después, el trabajo se reparte entre agentes especializados: uno analiza, otro migra, otro revisa contra el original. Cada uno trabaja en su propio contexto y comparte sus hallazgos por escrito, guiado por instrucciones detalladas para cada tarea (lo que en la jerga se llaman skills).
Un ejemplo, en el CMS de un cliente del sector turístico y hotelero, la base de datos completa se trasladó al nuevo framework con una sola intervención humana. Y las vistas de eventos, revisadas por agentes que abren la versión antigua en el navegador y la comparan con la nueva, se migraron en 8 horas frente a las 40-48 que habría costado hacerlo a mano.
La IA se equivoca: por eso el humano no es opcional
La objeción más razonable es que la IA no es determinista. Es cierto, y por eso no conviene pedirle lo que no sabe hacer. En un sistema financiero, una regla de redondeo mal interpretada puede compilar sin errores y dar resultados distintos. Lo que funciona es combinar arquitecturas agénticas, sobre todo para el discovery, con transpiladores deterministas construidos a medida para la conversión del código: el agente entiende y el transpilador garantiza un resultado reproducible.
Los propios fabricantes de modelos lo asumen. OpenAI publicó el 19 de octubre de 2026 una evaluación de migración de COBOL en la que su último modelo alcanza un 97,9% de acierto en pruebas que exigen paridad exacta con las salidas del programa original, y aun así advierte de que llevarlo a producción exige revisión experta y pruebas contra las reglas de negocio. El humano en el bucle no es un freno: cubre lo que a la IA le falta. Por eso, cuanto más contexto, mejor.
Migrar tal cual y evolucionar después
Tampoco la tecnología de destino es una limitación: el enfoque sirve para cualquier stack. Y el tiempo liberado tiene un efecto menos evidente: permite abordar lo que antes se descartaba, como rediseñar la estructura de la base de datos aprovechando la migración. El entregable resultante es mejor y más completo. Además, desplegar por módulos permite que el sistema antiguo y el nuevo convivan mientras dura la transición.
Mi recomendación es migrar primero tal cual y evolucionar después, empezando por un módulo acotado, midiendo y escalando a partir de ahí. La ventaja no será de quien migre con más IA, sino de quien sepa migrar con IA sin perder el control de lo que migra.
