Migrar aplicaciones bancarias a GeneXus 18 con Java y RPG: por qué compilar no basta

Una migración de GeneXus en banca no consiste simplemente en abrir una Knowledge Base en una versión nueva y corregir errores hasta que vuelva a compilar.

Cuando existen aplicaciones construidas sobre distintas generaciones de GeneXus, combinaciones de Java y RPG sobre IBM i, integraciones heredadas y prácticas de despliegue que han evolucionado de forma diferente con los años, el verdadero reto es otro: modernizar sin perder continuidad y, al mismo tiempo, dejar una forma de trabajo más repetible para el siguiente cambio.

En uno de nuestros proyectos recientes colaboramos en un programa de modernización para una entidad financiera de Colombia con dos frentes que debían avanzar de forma coordinada:

• migración progresiva de aplicaciones GeneXus legadas hacia GeneXus 18;
• evolución del ciclo de entrega hacia prácticas DevOps, con mayor trazabilidad, control de versiones, automatización y promociones controladas entre ambientes.

El punto importante es que ambos problemas estaban conectados. Migrar la tecnología sin mejorar la forma de construir y desplegar podía dejar al equipo con una versión más reciente, pero con los mismos riesgos operativos.

El problema no era una sola KB

El portafolio incluía aplicaciones con tecnologías, generadores y niveles de estandarización diferentes. Algunas trabajaban principalmente con Java; otras combinaban Java con componentes RPG sobre IBM i.

Eso impedía tratar la migración como un procedimiento único aplicado mecánicamente.

Antes de convertir cada KB había que entender su estado real:

• dependencias;
• errores existentes;
• componentes heredados;
• condiciones de compilación;
• integraciones;
• diferencias entre ambientes;
• y comportamiento funcional que debía preservarse.

La primera lección fue simple: si el origen no está estable, la migración amplifica el problema.

Primero estabilizar, después convertir

El trabajo se organizó de forma progresiva por KB.

Antes de migrar, revisábamos el estado de origen y buscábamos dejar una línea base suficientemente estable. Después iniciábamos la conversión a GeneXus 18 y comenzaba el trabajo que realmente consume esfuerzo en una modernización: especificar, generar, compilar, identificar incompatibilidades y resolverlas sin introducir cambios funcionales innecesarios.

Dependiendo de la KB, el ciclo podía incluir:

1. inventario y análisis técnico;
2. estabilización del estado de origen;
3. conversión controlada a GeneXus 18;
4. revisión de especificación, generación y compilación;
5. corrección de incompatibilidades y dependencias heredadas;
6. tratamiento específico para Java o RPG/IBM i;
7. ejecución de la aplicación migrada;
8. pruebas smoke y validaciones funcionales;
9. documentación de hallazgos y pendientes.

La migración dejaba de ser un evento y se convertía en un proceso verificable.

Preservar comportamiento era más importante que "mejorar" durante la migración

Uno de los criterios más importantes fue separar modernización técnica de evolución funcional.

Cuando se migra una aplicación crítica, es muy tentador aprovechar para refactorizar, cambiar pantallas, corregir reglas o introducir mejoras al mismo tiempo. Pero cada cambio adicional hace más difícil responder una pregunta fundamental:

¿El comportamiento cambió porque GeneXus cambió o porque nosotros cambiamos la aplicación?

Por eso el enfoque priorizó primero equivalencia funcional, compilación estable y ejecución verificable. Las mejoras podían venir después, sobre una base más controlada.

Java y RPG/IBM i obligan a adaptar el método

No todas las aplicaciones tenían la misma arquitectura.

En algunos casos el trabajo era principalmente Java. En otros existían componentes RPG sobre IBM i que requerían un tratamiento diferente durante la conversión y validación.

La metodología común seguía siendo la misma —estabilizar, convertir, compilar, validar y documentar—, pero la ejecución debía adaptarse a cada plataforma.

Ese equilibrio entre proceso común y adaptación técnica resultó más útil que intentar construir una receta rígida para todo el portafolio.

El segundo frente era cambiar cómo se entregaba software

Mientras avanzaban las migraciones, trabajábamos en otro problema: hacer más trazable y repetible el ciclo de entrega.

El objetivo no era crear un pipeline distinto y aislado para cada aplicación. La intención era construir una base reutilizable que pudiera adaptarse a KBs con características diferentes.

El frente DevOps incluyó capacidades para:

• custodiar fuentes y componentes compartidos en repositorios gobernados;
• reutilizar plantillas y pasos comunes;
• generar artefactos trazables desde compilaciones;
• controlar promociones entre ambientes;
• incorporar aprobaciones y validaciones en puntos relevantes;
• relacionar requerimientos, cambios técnicos y entregas;
• documentar procedimientos de operación, recuperación y diagnóstico.

Esto importa especialmente en modernizaciones largas. Si cada migración depende de conocimiento manual y procedimientos distintos, la organización termina pagando el mismo costo de aprendizaje una y otra vez.

La migración empezó a convertirse en una fábrica repetible

A medida que avanzaban las KB, los problemas encontrados dejaban de ser incidentes aislados y empezaban a convertirse en conocimiento reutilizable.

Cada incompatibilidad documentada, cada checklist, cada procedimiento de compilación y cada validación servía para reducir incertidumbre en la siguiente KB.

Ese cambio es probablemente uno de los resultados más útiles de este tipo de programa:

pasar de "migrar aplicaciones" a construir una capacidad organizacional para modernizarlas.

No significa que todas las KB sean iguales. Significa que el equipo ya no empieza desde cero cada vez.

Qué resultados podemos afirmar

La documentación histórica acredita ciclos concretos de estabilización, conversión y comprobación técnica sobre KB representativas. Una conversión abierta en GeneXus 18, un Rebuild All correcto o una compilación estable no prueban por sí solos ejecución equivalente de todos los generadores ni aceptación funcional del cliente.

También se trabajó con escenarios Java y con aplicaciones que combinaban Java y RPG sobre IBM i; se resolvieron incompatibilidades propias de la evolución tecnológica; se validó la ejecución de aplicaciones migradas; y se generaron guías, bitácoras, inventarios y documentación técnica para conservar el conocimiento.

En paralelo, se diseñó una arquitectura de automatización reutilizable y se implementaron componentes iniciales para integración, despliegue y trazabilidad.

El programa, sin embargo, mantiene actividades abiertas. No sería correcto presentar todo el portafolio como migrado ni todo el modelo DevOps como desplegado en todos los ambientes.

Lo que aprendimos

1. No migres una KB inestable

Los problemas preexistentes se vuelven mucho más difíciles de separar de los problemas introducidos por el cambio de versión.

2. Mantén la migración funcionalmente conservadora

Primero demuestra equivalencia y estabilidad. Después decide qué modernizar funcionalmente.

3. Convierte los problemas en procedimientos

Si el mismo error aparece dos veces, ya no debería resolverse como una investigación nueva.

4. DevOps no debe llegar al final

Versionado, trazabilidad, artefactos y controles de promoción ayudan durante la migración, no solo después.

5. Una metodología común no significa una implementación idéntica

Java y RPG/IBM i pueden compartir gobierno, evidencias y criterios de validación aunque necesiten pasos técnicos diferentes.

Modernizar tecnología y modernizar la entrega son el mismo programa

Una organización puede terminar con GeneXus 18 y seguir teniendo un proceso frágil si despliegues, repositorios, evidencias y conocimiento continúan dependiendo de procedimientos manuales.

Por eso nuestra lectura de este proyecto es que una modernización efectiva debe trabajar sobre dos capas al mismo tiempo:

la plataforma que ejecuta el software y el sistema con el que el equipo cambia ese software.

Cuando ambas evolucionan juntas, la siguiente actualización deja de sentirse como una operación extraordinaria y empieza a parecerse a una capacidad normal de ingeniería.

Próximo paso

Si tu organización mantiene aplicaciones GeneXus en versiones heredadas y necesita llevarlas a una plataforma vigente sin poner en riesgo la continuidad operativa, podemos ayudarte a evaluar las KB, definir una estrategia progresiva de migración y construir una base de entrega más trazable y repetible.

Contáctanos o revisa GeneXus Modernization.