Reescribir un sistema legacy sale caro. Entenderlo sale mucho, mucho más caro.

Cualquiera que haya heredado un ERP de quince años lo sabe. La persona que escribió el cálculo de comisiones ya no está, la documentación dice una cosa y el código hace otra, y nadie se atreve a tocar el módulo de facturación porque la última vez que alguien lo hizo se cayó el cierre de mes. El sistema funciona. Nadie sabe bien por qué.

Eso es lo que cambió con la IA. No escribe el sistema nuevo por ti, pero hace en semanas la parte que antes se comía la mitad del presupuesto: leer el código viejo y explicar qué hace.

Dónde entra la IA en una modernización legacy

Hay tres trabajos donde la diferencia ya es medible.

Leer y documentar. Morgan Stanley construyó una herramienta interna, DevGen.AI, que desde enero de 2025 revisó 9 millones de líneas de COBOL y Perl y las convirtió en especificaciones en inglés llano. Según contó Mike Pizzi, su jefe global de tecnología, al Wall Street Journal, eso les ahorró unas 280.000 horas de desarrolladores. Fíjate en lo que no hace la herramienta. No reescribe nada. Extrae la lógica de negocio y deja que un equipo la reconstruya con herramientas modernas.

Actualizar y traducir. Amazon usó su asistente Q para pasar aplicaciones a Java 17. Andy Jassy escribió que el tiempo promedio por aplicación bajó de unos 50 días de desarrollador a unas pocas horas, que en menos de seis meses actualizaron más de la mitad de sus sistemas Java en producción y que el ahorro equivale a 4.500 años de trabajo. Ojo, eso es Java a Java. Traducir de verdad (COBOL a Java, Visual FoxPro a Python) es más difícil y pide más revisión humana.

Fijar el comportamiento antes de moverlo. Esta es la que más me importa. Antes de cambiar un módulo necesitas pruebas que digan “esto es lo que hace hoy”, con sus errores incluidos. Se llaman pruebas de caracterización y escribirlas a mano en un sistema sin documentación era un trabajo eterno. Hoy la IA las genera leyendo el código, y tu equipo las revisa.

Anthropic describió este mismo flujo para COBOL en febrero de este año: mapear dependencias, documentar, medir riesgo por componente y recién entonces traducir. Lo analizamos cuando IBM perdió 31 mil millones en bolsa el día del anuncio.

Las cinco estrategias, con y sin IA

Las opciones de siempre siguen siendo las mismas. Lo que cambia es cuánto cuesta cada una.

Estrategia	Qué haces	Qué cambia con IA
Encapsulamiento (API wrapping)	Pones una capa de APIs encima del sistema viejo	Poco. Ya era la opción barata
Re-plataforma (lift and shift)	Mueves el sistema a la nube sin tocar la lógica	Las actualizaciones de versión se vuelven rutinarias
Refactorización	Ordenas el código sin cambiar lo que hace	Las pruebas de caracterización la hacen segura
Re-arquitectura	Partes el monolito en piezas	El mapa de dependencias deja de ser una adivinanza
Reconstrucción	Escribes un sistema nuevo desde cero	Arrancas con especificaciones extraídas del código, no de la memoria de alguien

Mi opinión es que la reconstrucción completa sigue siendo la peor apuesta en casi cualquier empresa mediana, con o sin IA. Concentra todo el riesgo en un solo día de salida.

Cómo se ejecuta mes a mes

Así es como planteamos un proyecto en IQ Source, con el patrón Strangler Fig: el sistema nuevo crece alrededor del viejo y lo va reemplazando por partes, sin un día de corte.

Mes 1. Entender. Inventario de módulos, mapa de dependencias y documentación generada con IA, revisada con la gente que usa el sistema todos los días. Al final del mes hay una lista de módulos ordenada por dos cosas: cuánto duele y qué tan aislado está.

Mes 2. Fijar. Pruebas de caracterización sobre el primer módulo elegido y una capa de API delante de él. Todavía no se apaga nada.

Meses 3 y 4. Primer módulo en producción. La versión nueva corre en paralelo, se compara contra la vieja con las mismas pruebas y el tráfico se redirige cuando los resultados coinciden.

Mes 5 en adelante. El siguiente módulo va más rápido porque el mapa, las pruebas y la capa de API ya existen. El sistema viejo se apaga por partes.

¿Cuál módulo va primero? ¿El que más falla o el que menos depende de los demás? ¿Quién confirma que una regla rara es un error y no una política que alguien pidió en 2014? Esas preguntas se contestan en el primer mes, y ninguna la contesta un modelo.

Lo que la IA no resuelve

La IA te dice qué hace el código. No te dice si debería hacerlo.

Un sistema de quince años tiene reglas que fueron decisiones de negocio y reglas que fueron errores que todos aprendieron a rodear. Distinguirlas pide a alguien de operaciones sentado al lado del equipo técnico, y eso no se acelera. Tampoco la migración de datos, que es donde yo esperaría que se rompa el cronograma, porque los datos viejos tienen veinte años de excepciones guardadas en campos de texto.

Y la gente. Un equipo que lleva una década manteniendo el sistema viejo es el que mejor sabe dónde están las trampas. Si lo dejas fuera del proyecto, la IA te va a documentar el código y vas a perder el contexto.

Si tienes un sistema que nadie quiere tocar, el primer paso es medir cuánto te está costando mantenerlo. La calculadora de deuda técnica te da un número para empezar, y si quieres ver cómo armamos el plan completo, está en nuestro servicio de modernización legacy.