TL;DR: migrar una aplicación GeneXus en 4 ideas
- Migrar una aplicación GeneXus empieza antes del proyecto: a partir de la base de conocimiento, en cualquier versión, los agentes analizan el sistema y entregan una estimación, un plan de entregas, un prototipo y documentación.
- Hay tres caminos de destino: full GeneXus (GeneXus 18), híbrido (front-end nativo con la lógica en GeneXus) o full nativo (la KB como fuente de conocimiento para un nuevo stack).
- La estimación es determinista: clasifica transacciones, pantallas y procedimientos por complejidad, y la misma KB siempre da el mismo resultado.
- Agentes especializados cubren la estrategia, la especificación y la construcción por entregas, con validación humana en cada decisión.
Las aplicaciones GeneXus forman parte de sistemas críticos para muchas organizaciones y concentran años de evolución y de conocimiento del negocio. Por eso, cuando hay que migrar una aplicación GeneXus, el primer desafío no es tecnológico: es entender qué hace hoy el sistema y cómo transformarlo sin perder ese conocimiento.
Este webinar es la segunda parte de Modernizar sistemas legacy con IA, donde Diego de Fuentes, CTO de GeneXus Consulting, presentó el qué y el porqué. Ahora Gastón González, Project Manager de GeneXus Consulting, se centra en el cómo: recorre cada etapa de una migración, muestra lo que produce cada agente y presenta ejemplos reales de aplicaciones migradas.
Antes de migrar una aplicación GeneXus: el preproyecto
A las cuatro etapas del proceso (estrategia, especificación, implementación y validación) se suma una etapa inicial: el preproyecto. Es todo lo que ocurre antes del inicio formal, mientras se entiende el sistema y se acuerda el camino con el cliente.
El punto de partida es la base de conocimiento (KB), en cualquier versión de GeneXus. El cliente puede entregar un respaldo completo, un XPZ o dar acceso a un ambiente donde esté la KB. A eso se suman entrevistas, formularios propios de GeneXus Consulting y datos de los usuarios. Con toda esa información, los agentes analizan el sistema, convierten la KB a la última versión de GeneXus y corrigen los problemas del modelo que impidan avanzar.
El preproyecto termina con un plan acordado con el cliente. A partir de ahí, la migración se hace siempre por entregas acumulativas, definidas desde el inicio, con puntos de control y decisiones humanas en cada etapa.
Tres caminos para migrar una aplicación GeneXus
En el preproyecto también se define el destino de la actualización tecnológica. Hay tres caminos posibles:
Camino 1
Full GeneXus
La KB se lleva a GeneXus 18 en su último upgrade y se rehace el front-end, por ejemplo al pasar de Win a Web. El primer hito es tener el modelo compilando y generando bien las tablas.
Camino 2
Híbrido
El front-end se rehace en tecnología nativa, como React, y la KB sigue manejando el modelo y la lógica, expuestos mediante APIs. El hito inicial es la base de datos generada y las APIs disponibles.
Camino 3
Full nativo
La KB se usa como fuente de conocimiento: de ella se extraen la lógica y la información de las pantallas, y la aplicación se rehace por completo en un nuevo stack, como React o Next.js, con un enfoque de desarrollo de software a medida.
En los tres casos, la KB se lleva a GeneXus 18 para que los agentes trabajen siempre sobre la última versión.
El kit inicial: estimación, plan y prototipo
El resultado del preproyecto es un kit con un formato estandarizado, que se entrega al cliente para que tome la decisión:
Propuesta. Presenta los tres caminos, el proceso de trabajo, el tamaño del sistema y el plazo estimado en meses para cada opción.
Plan detallado. Describe las etapas, las ventajas de cada camino, el inventario del sistema y cómo se llegó a cada plazo.
Prototipo funcional. Muestra cómo podría lucir la aplicación migrada, con pantallas con las que ya se puede interactuar.
Documentación tipo wiki. Explica funcionalidades clave del sistema: sus reglas de negocio y cómo se realiza cada cálculo.
Cuánto lleva migrar una aplicación GeneXus: cómo se estima
La KB no es solo código: es un modelo con toda la información del sistema. Indica qué objetos llaman a cuáles, qué datos usa cada pantalla, qué partes nunca se ejecutan (código muerto) y qué está duplicado. Esa información sirve para estimar y también para mejorar el sistema durante la conversión, en lugar de copiarlo tal como está.
Para estimar, se clasifica cada objeto como de complejidad baja, media o alta, con métricas propias basadas en la experiencia de GeneXus Consulting:
- Transacciones: cantidad de reglas y de niveles.
- Pantallas: líneas de código, eventos y reglas.
- Procedimientos: líneas de código, lógica y cantidad de objetos a los que llaman.
La estimación se hace sobre la KB en su versión de origen y sobre la versión convertida a GeneXus 18, y se verifica que ambas coincidan.
La estimación es determinista: si se estima varias veces la misma KB, el resultado es siempre el mismo, y sirve como única base para comparar los tres caminos.
Para que la estimación sea confiable, hay que preparar bien la información:
- Una foto inicial correcta: la KB debe ser la que está en producción, y conviene respaldarla intacta antes de empezar.
- Claridad sobre la calidad: saber qué se usa y qué no, para no repetir errores durante el proceso.
- El entorno completo: dispositivos como impresoras, puestos de trabajo, diseño, integraciones con otros sistemas y seguridad.
Los agentes que intervienen al migrar una aplicación GeneXus
Cada etapa del proyecto se apoya en un conjunto de agentes de inteligencia artificial con un rol específico. En todas, un agente revisor independiente controla que no falte nada, y la decisión de avanzar es siempre humana.
Una vez al inicio
Estrategia
El agente source documenta lo que hay hoy. Un agente de transición define cómo pasa cada pantalla: tal cual, como un «trabajar con» o como un wizard. Un auditor busca riesgos y elementos ocultos.
Por cada entrega
Especificación
Un agente de reverse spec documenta qué hace cada funcionalidad a partir de la KB. Un agente de comparación define qué cambia en la nueva versión, y un revisor controla que no falte nada.
En ciclos
Construcción
El planner define las unidades de trabajo, el builder las implementa en partes más chicas y los testers las prueban, con el apoyo de nuestro equipo de Testing y QA. Las evaluaciones miden cómo funciona el proceso para mejorarlo.
Además, un agente conversor lleva la KB desde versiones como la 7.5, 8 o 9 hasta GeneXus 18 y prepara la estimación del kit inicial, y otros agentes se encargan de convertir la interfaz y de las liberaciones entre ambientes. El trabajo se ordena con cuatro reglas:
- Límites de iteraciones: si después de cierta cantidad de vueltas no hay cambios, el proceso se detiene para que lo revise una persona.
- Permisos mínimos: cada agente tiene solo las herramientas que necesita para su tarea.
- Un build siempre funcionando: cada iteración tiene que mantener la KB compilando, sin romper lo que ya está probado.
- Mejorar la herramienta, no el caso: si un error se repite, se mejora la herramienta del agente en lugar de corregir objeto por objeto.
El ciclo de desarrollo en acción
En el webinar se ve una ejecución real sobre un ERP de demostración. El agente principal lee el estado del proyecto, muestra en qué etapa está y propone el siguiente paso: migrar a web dos pantallas de órdenes de trabajo. Al aprobarlo, delega la tarea en el agente que convierte la interfaz, y después un tester independiente revisa el resultado. Si encuentra algo, el ciclo se repite hasta que esté listo.
Todo el proceso se puede seguir paso a paso en herramientas de monitoreo, y no depende de una única herramienta de IA: el mismo ciclo de desarrollo funciona con Claude Code, Kiro o Codex, entre otras.
Qué tipo de aplicaciones se pueden obtener
A partir de la misma aplicación Win de origen, el webinar muestra distintos resultados:
- Web en GeneXus 18 sin patterns: primero con el estilo por defecto y después con el sistema de diseño del cliente, en vista de grilla, de tarjetas o compacta. Puede convivir con la aplicación Win sobre la misma base de datos.
- Web en GeneXus 18 con K2B Tools: filtros por columna, vistas de tarjetas, pivot y kanban con arrastrar y soltar, y exportación de datos.
- Front-end en React: una aplicación web fuera de GeneXus, con filtros, selección de columnas y exportación a CSV o PDF.
- Escritorio con Electron: una aplicación con base de datos local que funciona sin conexión y sincroniza la información cuando se conecta al sistema central.
- Móvil con React Native: una aplicación de billetera electrónica con navegación ágil y efectos propios de esa tecnología.
Los tres caminos cubren un abanico amplio de soluciones, y se pueden combinar según lo que necesite cada organización.
Preguntas frecuentes sobre cómo migrar una aplicación GeneXus
¿Qué tiene que entregar la organización para empezar?
La base de conocimiento, en cualquier versión de GeneXus: un respaldo completo, un XPZ o acceso a un ambiente donde esté la KB. Se complementa con entrevistas y formularios.
¿Desde qué versiones de GeneXus se puede migrar?
Desde versiones legadas como GeneXus 7.5, 8 o 9, y también desde versiones Evolution. En todos los casos, la KB se lleva a GeneXus 18.
Mi aplicación ya está en GeneXus 18, pero su diseño es muy básico. ¿Se puede modernizar solo la parte visual?
Sí. Se puede trabajar solo sobre la experiencia visual, manteniendo el back-end en GeneXus y sumando una capa de presentación moderna, por ejemplo en React.
¿Los agentes son subagentes o skills?
Son subagentes. Un agente principal se comunica con el usuario y delega cada tarea en subagentes organizados en grafos, que toman sus propias decisiones. Cada agente tiene su propia skill, que le da el contexto y la guía de cómo trabajar, y que se mejora a medida que se ajusta el proceso.
¿Hay que migrar todo el sistema de una vez?
No. La migración se organiza por entregas, y se puede empezar con un piloto para evaluar los resultados antes de ampliar el alcance.
Conclusión
Migrar una aplicación GeneXus con IA no consiste en convertir objetos de forma automática. Es un proceso ordenado que empieza por entender el sistema, se apoya en una estimación determinista y avanza por entregas con agentes especializados y decisiones humanas. Además, deja documentado el conocimiento del sistema: sus funcionalidades, sus reglas y su estrategia de migración.
Si quieres conocer más sobre este enfoque, puedes leer también Migraciones GeneXus con IA: menos riesgo, resultados predecibles y conocer nuestro servicio de Evolución Tecnológica.
Próximo paso
¿Tienes una aplicación GeneXus para migrar? Empecemos con un piloto y midamos los resultados juntos.
-
Siguiente
Modernizar sistema...
