Migrating banking applications to GeneXus 18 with Java and RPG: why compilation is not enough

A GeneXus migration in banking is not simply opening a Knowledge Base in a newer version and fixing errors until it compiles again.

When an application portfolio contains different GeneXus generations, Java and RPG components on IBM i, legacy integrations, and different build and deployment practices, the real challenge is broader: modernize without losing continuity while creating a more repeatable way to deliver the next change.

In one of our recent projects, we collaborated on a modernization program for a financial institution in Colombia. Two workstreams had to move together:

• progressive migration of legacy GeneXus applications to GeneXus 18;
• evolution of the delivery lifecycle toward DevOps practices with stronger traceability, version control, reusable automation, and controlled promotion between environments.

The important point was that these were not separate problems. Updating the technology without improving how software is built and delivered could leave the organization on a newer version while keeping the same operational risks.

The challenge was not one Knowledge Base

The portfolio contained applications with different technologies, generators, dependencies, and levels of standardization. Some were mainly Java. Others combined Java with RPG components running on IBM i.

That meant we could not treat migration as one mechanical procedure.

Before converting each KB, we needed to understand its real condition: dependencies, existing errors, legacy components, compilation requirements, integrations, environment differences, and the functional behavior that had to remain stable.

The first lesson was simple: if the source is unstable, migration amplifies the problem.

Stabilize first, convert second

The work progressed KB by KB.

We first established a stable enough source baseline. Then we moved into conversion to GeneXus 18 and the work that usually consumes most of the effort: specification, generation, compilation, incompatibility analysis, and correction without introducing unnecessary functional change.

Depending on the KB, the cycle included:

1. technical inventory and complexity analysis;
2. stabilization of the source state;
3. controlled conversion to GeneXus 18;
4. specification, generation, and compilation review;
5. resolution of legacy incompatibilities and dependencies;
6. platform-specific treatment for Java or RPG/IBM i;
7. execution of the migrated application;
8. smoke testing and functional validation;
9. documentation of findings and remaining work.

Migration became a verifiable process instead of a one-time event.

Preserve behavior before improving it

One of the most important decisions was to separate technical modernization from functional evolution.

During a critical-system migration, it is tempting to refactor, redesign screens, change rules, or introduce improvements at the same time. Every extra change, however, makes one question harder to answer:

Did the behavior change because GeneXus changed, or because we changed the application?

Our approach prioritized functional equivalence, stable compilation, and verifiable execution first. Improvements could follow later on a controlled baseline.

Java and RPG/IBM i require adaptation

Not every application shared the same architecture.

Some KBs were primarily Java. Others included RPG components on IBM i and required different treatment during conversion and validation.

The common method remained consistent — stabilize, convert, compile, validate, document — but implementation had to adapt to each platform.

That balance between a shared method and technical adaptation proved more useful than forcing one rigid recipe across the portfolio.

The second workstream changed how software was delivered

While migration progressed, we worked on another problem: making delivery more traceable and repeatable.

The goal was not to build a separate pipeline for every application. It was to create reusable foundations that could be adapted to KBs with different characteristics.

The DevOps work included capabilities to:

• keep source code and shared components in governed repositories;
• reuse common templates and delivery steps;
• produce traceable artifacts from build processes;
• promote changes between environments in a controlled way;
• add approvals and validation gates where needed;
• connect functional work, technical changes, and releases;
• document operational, recovery, and diagnostic procedures.

This matters in long modernization programs. If every migration depends on manual knowledge and different procedures, the organization pays the same learning cost repeatedly.

Migration started becoming a repeatable capability

As more KBs moved through the process, issues stopped being isolated discoveries and became reusable knowledge.

Each documented incompatibility, checklist, build procedure, and validation step reduced uncertainty for the next KB.

That may be one of the most valuable outcomes of this kind of program:

moving from "migrating applications" to building an organizational capability for modernization.

It does not mean every KB is the same. It means the team does not start from zero every time.

What the evidence supports

The historical records support specific stabilization, conversion and technical verification cycles for representative knowledge bases. A successful conversion, Rebuild All or build is not by itself evidence of end-to-end functional acceptance.

The team worked with Java scenarios and applications combining Java and RPG on IBM i, addressed technology-evolution incompatibilities, executed migrated applications, performed functional validations, and produced guides, logs, inventories, and technical documentation to preserve knowledge.

In parallel, a reusable automation architecture was designed and initial integration, deployment, and traceability components were implemented.

The program still has active work. It would be inaccurate to describe the entire portfolio as migrated or the complete DevOps model as deployed across every environment.

What we learned

1. Do not migrate an unstable KB

Existing problems become much harder to distinguish from issues introduced by the version change.

2. Keep the migration functionally conservative

Prove equivalence and stability first. Decide on functional modernization afterwards.

3. Turn recurring issues into procedures

If the same problem appears twice, it should not require a new investigation every time.

4. DevOps should not arrive at the end

Versioning, traceability, artifacts, and controlled promotion help during the migration itself.

5. One method does not mean identical implementation

Java and RPG/IBM i can share governance, evidence, and validation criteria while requiring different technical steps.

Modernizing the platform and modernizing delivery are one program

An organization can reach GeneXus 18 and still operate a fragile delivery process if deployments, repositories, evidence, and knowledge remain dependent on manual procedures.

Our main lesson from this project is that modernization should address two layers at the same time:

the platform that runs the software and the system the team uses to change that software.

When both evolve together, the next upgrade becomes less of an exceptional operation and more of a normal engineering capability.

Next step

If your organization is maintaining GeneXus applications on legacy versions and needs to move toward a current platform without putting operational continuity at risk, we can help assess the KBs, define a progressive migration strategy, and build a more traceable and repeatable delivery foundation.

Contact us or review GeneXus Modernization.