Entre el 60% y el 80% del presupuesto de IT de las grandes organizaciones se destina a mantener sistemas que ya existen. No a innovar. No a crecer. A sostener lo que está.
Esos sistemas no son un problema. Son décadas de lógica de negocio, reglas implícitas, excepciones aprendidas en producción y conocimiento institucional que no existe en ningún otro lugar. Son, en el sentido más literal, el activo digital más valioso de la empresa.
El problema es que nadie los entiende completamente porque los desarrolladores originales se jubilaron, y la documentación no existe o está desactualizada.
Estudios de CAST Software muestran que hasta el 70% del código legacy es «dark matter»: nadie sabe exactamente qué hace ni por qué está ahí. El equipo tiene miedo de tocar ciertas partes. Y el costo de mantener sin entender, la deuda de conocimiento, es la más cara de todas las deudas técnicas.
La pregunta que nadie ha podido responder bien hasta ahora es: ¿cómo se moderniza un sistema así sin destruir lo que contiene?
Los dos enfoques que no resuelven el problema
El mercado ofrece dos respuestas. Ninguna es suficiente.
La primera
es reescribir el sistema en un lenguaje moderno, asistido por herramientas de IA. Este es el camino más adoptado porque es visible y medible a corto plazo. El problema acá es estructural: se migra la sintaxis, no la semántica. El nuevo sistema hereda la lógica de negocio válida junto con las decisiones de diseño obsoletas, los workarounds acumulados y la deuda conceptual del original. En pocos años, ese sistema «nuevo» será el próximo legacy. El ciclo se repite.
La segunda
es empezar de cero. La promesa es libertad total de diseño. El costo real es la pérdida de la identidad operativa construida durante años: reglas implícitas, excepciones aprendidas en producción, comportamientos adaptados al cliente real. Nada de eso está documentado. Está en el sistema. Y cuando el sistema nuevo sale a producción, esos casos reaparecen como bugs críticos que nadie anticipó.
Aunque ambos enfoques son legítimos, tienen un problema en común, y es que ninguno resuelve la pregunta central. ¿Dónde vive el conocimiento de negocio acumulado?, ¿Cómo se preserva mientras el sistema cambia?
El tercer camino: documentar, modelar, generar
Existe un enfoque diferente, adoptado en muy pocos casos pero con resultados cualitativamente distintos: documentar primero, transformar después.
El proceso tiene cuatro pasos:
- Documentar el sistema actual con IA agéntica, extrayendo qué hace el código y el conocimiento de negocio implícito que contiene.
- Trabajar sobre los procesos en esa documentación, no en el código.
- Ir construyendo, con eso, el modelo conceptual de la empresa: la empresa como código.
- Generar los nuevos sistemas desde ese modelo, partiendo del activo digital y dejando atrás la deuda técnica.
Este enfoque ya existe y ya tiene resultados en producción. Una compañía líder en gestión de inversiones del sector financiero enfrentaba exactamente este desafío: 48 componentes de código legacy crítico, ~26.000 líneas de código, complejidad ciclomática de hasta 270 en sus programas más críticos, y documentación preexistente: cero. El conocimiento vivía en el código y en la memoria de dos especialistas.
Aplicando el GeneXus Legacy Modernization Framework (desarrollado por Globant: Glob.AI OS + GeneXus), los resultados fueron medibles: 48 programas documentados, con calidad de documentación validada 9/10 por los propios expertos del cliente. La generación de documentación se aceleró 10x. Y el 100% de los casos de prueba de regresión aprobó, incluyendo precisión financiera al decimal en los algoritmos de cálculo críticos.
Lo más importante: el conocimiento que solo existía en el código y en la memoria de dos personas hoy es explícito, documentado, verificable y transferible.
Cómo funciona el framework
El GeneXus Legacy Modernization Framework opera con tres pipelines paralelos e independientes a partir del código fuente del Sistema Legacy:
Documentación:
IA agéntica genera un resumen técnico estructurado que incluye pseudocódigo, reglas de negocio, dependencias y casos borde, comprensible por humanos y por LLMs.
Site navegable:
la documentación se publica como portal HTML versionado, entregable al cliente.
Código GeneXus:
el Sistema Legacy se convierte en objetos en una Knowledge Base GeneXus, desde los cuales se genera el código destino de forma determinística en cualquier lenguaje (Java, .NET u otros).
La clave está en el proceso de verificación: antes de generar el código final, el framework verifica la paridad lógica entre el pseudocódigo de la documentación y el objeto GeneXus creado, ambos generados desde la misma fuente de verdad: el código legacy original. Si hay desviaciones, se corrigen. Solo cuando el modelo está aprobado, GeneXus genera el código destino de forma determinística: a igual entrada, igual salida, siempre.
GeneXus como capa intermedia desacopla dos decisiones que no deberían tomarse al mismo tiempo: preservar la lógica de negocio y elegir el stack tecnológico destino. El mismo modelo genera Java, .NET u otros targets. La validación se realiza una sola vez. Y el sistema migrado puede correr en paralelo con el legacy durante la transición: migración incremental, sin big bang, con cero corte en producción.
GeneXus for Agents & el GeneXus Legacy Modernization Framework
El GeneXus Legacy Modernization Framework
lleva sistemas legacy desarrollados en tecnologías no GeneXus hacia GeneXus, utilizando GeneXus for Agents. Así, obtienes una KB lista para el GeneXus de hoy y del mañana.
El framework resuelve la modernización del legacy bajo un principio simple: la conversación produce un modelo formal, y el código es una de sus proyecciones. El usuario conversa con un agente en lenguaje de negocio. Cuando el modelo está completo y verificado, el código se genera de forma determinística. Si el negocio cambia, cambia el modelo, y el sistema calcula qué partes regenerar. El código es consecuencia del modelo.
Ese es el puente más importante: el sistema modernizado queda habilitado para seguir evolucionando con el nuevo paradigma, incorporando nuevas funcionalidades sobre una base sólida, verificable y auditable.
La pregunta que no puedes dejar sin responder
En el mundo de hoy, generar código es fácil y barato. Eso hace que el riesgo de acumular deuda técnica sea más alto que nunca, porque nunca fue tan fácil generar código sin entenderlo.
Para cada sistema que tienes hoy, vale la pena hacerse tres preguntas:
- ¿Existe un modelo explícito de cómo debe operar?
- ¿Ese modelo es comprensible por un humano y explicable por un LLM?
- ¿El código es una consecuencia automática de ese modelo?
Si alguna respuesta es no, ese sistema acumula deuda. Silenciosamente, todos los días.
El camino para revertirlo comienza eligiendo el módulo más crítico, más opaco o más costoso de mantener, y aplicar el framework. El modelo que construyes hoy es la base del mañana.
Para saber más sobre GeneXus, te invitamos a consultar la página
GeneXus™ FAQs
. También puedes contactarnos a través de
nuestras oficinas
o de nuestra
red de distribuidores mundial
.
También te puede interesar leer:
GeneXus y el poder del conocimiento
¿Funciona GeneXus for Agents? Esto opinan sus usuarios
GeneXus for Agents: qué es, cómo funciona y cómo empezar