Lo que nos llevamos de AISM 2026 en Múnich y por qué, cuando hablamos de modernización de software legacy, creemos que la conversación debe comenzar en los procesos de negocio y no en el código fuente.

Una aplicación lleva funcionando veinte años. Ha sobrevivido a varias generaciones de empleados, cambios de estrategia y cientos de excepciones añadidas con el tiempo. Hoy nadie la desarrollaría de la misma manera. Y, sin embargo, una parte importante del negocio sigue dependiendo de ella.

Entonces aparece una frase conocida: “Tenemos que modernizar esto.”

Pero ¿qué significa realmente modernizar? ¿Traducir el código a otro lenguaje? ¿Cambiar la interfaz? ¿Migrar la aplicación a la nube? ¿O aprovechar la oportunidad para analizar cómo debería trabajar la empresa en el futuro?

Para nosotros, ahí empieza la verdadera conversación. No con la elección de una tecnología, sino con una pregunta mucho más importante: ¿Qué necesita el negocio y qué papel debe desempeñar el software para conseguirlo?

Esta fue también la perspectiva que llevamos a AISM 2026 en Múnich, dentro de ASE, donde presentamos junto a Prof. Sandra Greiner nuestro paper “LLM-Based Legacy Application Re-engineering Platform: An Experience Report of Migrating a Web Application”.

La modernización legacy es mucho más que traducir código

En AISM pudimos conocer diferentes enfoques sobre modernización de software mediante inteligencia artificial: desde traducciones de COBOL a Java y migraciones de C a Rust basadas en agentes, hasta métodos para comprender aplicaciones existentes, reconstruir decisiones arquitectónicas o combinar IA con análisis tradicional de software.

La variedad de enfoques deja algo claro: modernizar una aplicación legacy no es una única tarea técnica.

Uno de los trabajos presentados lo resumía de forma especialmente interesante en su título: “Passing Parity Is Not Preserving Behaviour”. Es decir, superar determinadas pruebas de comparación no significa necesariamente que el nuevo sistema esté preservando correctamente el comportamiento del anterior.

Desde una perspectiva de negocio, nosotros añadiríamos una pregunta más: incluso si una nueva aplicación hace exactamente lo mismo que la antigua, ¿significa eso que sigue haciendo lo correcto para la empresa?

Esta pregunta está en el centro de nuestro enfoque con Legacy Revive.

El problema real no es el lenguaje de programación antiguo

Imaginemos un distribuidor técnico cuya aplicación principal gestiona ofertas, precios personalizados, aprobaciones y pedidos. Desde una perspectiva puramente técnica, el objetivo podría parecer sencillo:

La aplicación debe funcionar en una plataforma moderna.

Pero desde la perspectiva del negocio empiezan a aparecer preguntas diferentes: ¿Por qué algunas ofertas necesitan tres aprobaciones? ¿Qué reglas de precios siguen siendo relevantes? ¿En qué puntos deben los empleados introducir varias veces los mismos datos? ¿Qué excepciones representan realmente una ventaja competitiva? ¿Y cuáles existen únicamente porque el sistema antiguo no permitía hacerlo de otra forma?

El ejemplo es ficticio, pero muestra una diferencia fundamental: trasladar técnicamente un sistema existente no es lo mismo que mejorar el proceso de negocio que hay detrás.

Si confundimos ambos objetivos, podemos acabar con una aplicación completamente moderna que siga obligando a los usuarios a recorrer exactamente los mismos caminos innecesarios que antes. La tecnología cambia. El problema permanece.

Nuestro diferenciador: Business first, no Code first

Con Legacy Revive queremos empezar deliberadamente desde otro punto. La primera pregunta no es “¿Cómo traducimos este código?”, sino “¿Qué debería hacer esta aplicación por el negocio?”

Eso no significa que ignoremos el código existente. Al contrario. Una aplicación que lleva funcionando durante años puede contener una enorme cantidad de conocimiento: reglas de negocio, excepciones, dependencias y decisiones que quizá ya no estén documentadas en ningún otro lugar.

Pero el código es una fuente de información. No debería convertirse automáticamente en el plano de la aplicación futura. Porque una implementación existente nos cuenta principalmente cómo se resolvió algo. No necesariamente explica por qué se necesita, si todavía tiene sentido o si hoy existe una forma mejor de hacerlo.

Por eso, antes de decidir cómo modernizar técnicamente una aplicación, planteamos tres preguntas:

1. ¿Qué debe conservarse?

¿Qué reglas de negocio, capacidades, conocimientos y obligaciones siguen siendo esenciales?

2. ¿Qué debería cambiar?

¿Qué procesos podrían ser más sencillos, rápidos, transparentes o fáciles de mantener?

3. ¿Qué puede desaparecer?

¿Qué funcionalidades y excepciones han perdido el propósito para el que fueron creadas?

Para nosotros, estas preguntas no son un complemento de la modernización. Son las que marcan su dirección.

Conservar, mejorar o eliminar

Decir que “el nuevo sistema debe hacer todo lo que hacía el anterior” puede parecer la opción más segura. Pero también puede impedir tomar decisiones importantes.

Pensemos en una regla especial de descuento para determinados clientes. Puede representar una obligación contractual que sigue siendo relevante. En ese caso, debe preservarse.

Puede existir también una aprobación manual que se introdujo hace años porque entonces no había integración entre dos sistemas. En lugar de replicar exactamente ese paso, conviene entender qué necesidad de control existe detrás y decidir cómo resolverla ahora.

Y quizá haya un informe que nadie utiliza desde hace años. En ese caso, la pregunta correcta no es cómo reconstruirlo. La pregunta es si todavía debería existir.

La modernización Business first diferencia entre necesidad empresarial y hábito histórico.

Y para hacerlo correctamente necesitamos algo que ninguna transformación automática del código puede sustituir: conversar con las personas que conocen y utilizan los procesos. Porque no todas las funcionalidades actuales aportan valor, pero tampoco todas las excepciones aparentemente extrañas son innecesarias. El reto está en entender la diferencia.

¿Qué papel debe jugar la IA?

La capacidad de la inteligencia artificial para analizar, generar y transformar código abre enormes oportunidades para modernizar software. Pero también existe una tentación: considerar que el objetivo es automatizar la mayor cantidad posible de trabajo técnico.

Nuestra perspectiva es diferente: la velocidad aporta valor cuando la dirección es la correcta.

Crear rápidamente una nueva aplicación sirve de poco si parte de requisitos que nadie ha validado. De la misma manera, generar automáticamente una descripción convincente de un proceso no es suficiente si nadie confirma que refleja cómo funciona realmente el negocio.

Para nosotros, la IA debe formar parte de un proceso de modernización controlado, trazable y comprensible. La cuestión no es únicamente cuánto puede producir. La cuestión es si ayuda a descubrir conocimiento, entender dependencias, responder las preguntas adecuadas y tomar mejores decisiones.

Las decisiones de negocio siguen siendo decisiones de negocio: ¿Qué riesgos son aceptables? ¿Qué excepciones son críticas? ¿Qué procesos deberían cambiar? ¿Qué necesita realmente el cliente o el empleado? Las respuestas no pueden obtenerse únicamente leyendo un lenguaje de programación.

Un objetivo común para negocio e IT

El enfoque Business first no significa enfrentar negocio e IT. Todo lo contrario. El objetivo es que ambos trabajen sobre una misma visión de lo que se quiere conseguir.

Decir simplemente “necesitamos modernizar el sistema” es demasiado ambiguo. Incluso “necesitamos una nueva arquitectura” describe una intención técnica, no un resultado empresarial.

Es mucho más útil definir objetivos como:

• Crear una oferta sin introducir los mismos datos varias veces.
• Poder modificar una regla de negocio sin reconstruir todo el proceso.
• Hacer que una aprobación sea comprensible y trazable para todas las partes.
• Permitir que un nuevo empleado gestione un caso estándar sin depender del conocimiento informal de una única persona.

Este tipo de objetivos no elimina las decisiones técnicas. Les proporciona un criterio con el que evaluarlas.

El éxito no termina con el go-live

Si comenzamos una modernización partiendo de objetivos de negocio, también deberíamos medir su éxito de esa manera.

En nuestro ejemplo del distribuidor técnico podríamos observar indicadores como el tiempo necesario para procesar una oferta, el número de entradas manuales de datos, cuánto se tarda en implementar una nueva regla o hasta qué punto las decisiones quedan documentadas y son comprensibles.

No son resultados prometidos por Legacy Revive. Son ejemplos de cómo un proyecto Business first puede definir lo que significa realmente tener éxito.

Porque poner el nuevo sistema en producción es un hito importante. El objetivo final es el impacto que genera en el negocio.

Legacy Revive: del negocio al sistema

En insinno no planteamos Legacy Revive como una renovación tecnológica por el simple hecho de utilizar tecnología más moderna. Nuestro objetivo es ayudar a las empresas a modernizar aplicaciones existentes a partir de una razón de negocio clara.

Nuestro diferenciador puede resumirse de forma sencilla: vamos del negocio al sistema, no del código a una nueva versión del mismo sistema.

Queremos entender qué hace valiosa a una aplicación. Qué conocimiento debe conservarse. Qué debería mejorar. Qué puede dejar de existir. Y cómo convertir esas decisiones en una base sólida para la implementación técnica.

La pregunta más importante llega antes de escribir la primera línea de código

AISM 2026 mostró hasta qué punto están avanzando las posibilidades técnicas para analizar, comprender, validar y transformar sistemas legacy.

Nuestra conclusión es que esas posibilidades deben combinarse con algo igual de importante: claridad sobre el negocio.

Por eso, la pregunta no debería ser únicamente “¿Podemos reconstruir esta aplicación?”. La pregunta debería ser: “¿Qué aplicación necesitará nuestra empresa en el futuro y qué debemos conservar realmente de la solución que tenemos hoy?”

Ahí es donde comienza Legacy Revive.

¿Estás pensando en modernizar una aplicación crítica para tu negocio? Hablemos primero de cómo funciona tu negocio. Del código podemos hablar después.

Más información sobre Legacy Revive:
legacy-revive.insinno.eu