TL;DR: migrate a GeneXus application in 4 ideas
- To migrate a GeneXus application, the work starts before the project: from the knowledge base, in any version, agents analyze the system and deliver an estimate, a delivery plan, a prototype and documentation.
- There are three target paths: full GeneXus (GeneXus 18), hybrid (a native front end with the logic in GeneXus) or full native (the KB as a knowledge source for a new stack).
- The estimate is deterministic: it classifies transactions, screens and procedures by complexity, and the same KB always produces the same result.
- Specialized agents cover strategy, specification and construction in deliveries, with human validation at every decision point.
GeneXus applications are part of business-critical systems for many organizations, and they hold years of evolution and business knowledge. That’s why, when you need to migrate a GeneXus application, the first challenge isn’t technological: it’s understanding what the system does today and how to transform it without losing that knowledge.
This webinar (in Spanish) is the second part of How to modernize legacy systems with AI, where Diego de Fuentes, CTO of GeneXus Consulting, presented the what and the why. Now Gastón González, Project Manager at GeneXus Consulting, focuses on the how: he walks through each stage of a migration, shows what each agent produces and presents real examples of migrated applications.
Before you migrate a GeneXus application: the pre-project stage
The four stages of the process (strategy, specification, implementation and validation) are preceded by an initial stage: the pre-project. It covers everything that happens before the formal kickoff, while the system is being understood and the path is agreed with the client.
The starting point is the knowledge base (KB), in any GeneXus version. The client can provide a full backup, an XPZ or access to an environment where the KB lives. This is complemented by interviews, GeneXus Consulting’s own forms and data from users. With all that information, agents analyze the system, convert the KB to the latest GeneXus version and fix any model issues that would block progress.
The pre-project ends with a plan agreed with the client. From then on, the migration always moves forward in cumulative deliveries defined from the start, with checkpoints and human decisions at every stage.
Three paths to migrate a GeneXus application
The pre-project also defines the target of the technology upgrade. There are three possible paths:
Path 1
Full GeneXus
The KB is moved to the latest upgrade of GeneXus 18 and the front end is rebuilt, for example when moving from Win to Web. The first milestone is having the model compiling and generating the tables correctly.
Path 2
Hybrid
The front end is rebuilt in native technology, such as React, while the KB keeps handling the model and the logic, exposed through APIs. The first milestone is the generated database and the available APIs.
Path 3
Full native
The KB is used as a knowledge source: the logic and screen information are extracted from it, and the application is fully rebuilt on a new stack, such as React or Next.js, with a custom software development approach.
In all three cases, the KB is moved to GeneXus 18 so the agents always work on the latest version.
The initial kit: estimate, plan and prototype
The outcome of the pre-project is a kit in a standardized format, delivered to the client so they can make a decision:
Proposal. It presents the three paths, the work process, the size of the system and the estimated timeline in months for each option.
Detailed plan. It describes the stages, the advantages of each path, the system inventory and how each timeline was calculated.
Working prototype. It shows what the migrated application could look like, with screens users can already interact with.
Wiki-style documentation. It explains key features of the system: their business rules and how each calculation is performed.
How long it takes to migrate a GeneXus application: how it’s estimated
The KB isn’t just code: it’s a model that holds all the information about the system. It shows which objects call which others, what data each screen uses, which parts never run (dead code) and what is duplicated. That information is used for the estimate and also to improve the system during the conversion, instead of copying it as is.
To estimate, each object is classified as low, medium or high complexity, using proprietary metrics based on GeneXus Consulting’s experience:
- Transactions: number of rules and levels.
- Screens: lines of code, events and rules.
- Procedures: lines of code, logic and number of objects they call.
The estimate is run on the KB in its source version and on the version converted to GeneXus 18, and both are checked to make sure they match.
The estimate is deterministic: if the same KB is estimated several times, the result is always the same, and it serves as the single basis for comparing the three paths.
For the estimate to be reliable, the information has to be properly prepared:
- A correct initial snapshot: the KB must be the one in production, and it’s best to back it up untouched before starting.
- Clarity about quality: knowing what is used and what isn’t, so errors aren’t repeated during the process.
- The full environment: devices such as printers, workstations, design, integrations with other systems and security.
The agents involved when you migrate a GeneXus application
Each stage of the project relies on a set of artificial intelligence agents with a specific role. In every stage, an independent reviewer agent checks that nothing is missing, and the decision to move forward is always made by a person.
Once at the start
Strategy
The source agent documents what exists today. A transition agent defines how each screen moves over: as is, as a “work with” pattern or as a wizard. An auditor looks for risks and hidden elements.
For each delivery
Specification
A reverse spec agent documents what each feature does, based on the KB. A comparison agent defines what changes in the new version, and a reviewer checks that nothing is missing.
In cycles
Construction
The planner defines the units of work, the builder implements them in smaller parts and the testers test them, backed by our Testing & QA team. Evaluations measure how the process is performing so it can be improved.
In addition, a converter agent moves the KB from versions such as 7.5, 8 or 9 up to GeneXus 18 and prepares the estimate for the initial kit, while other agents handle the UI conversion and the releases between environments. The work follows four rules:
- Iteration limits: if there are no changes after a certain number of loops, the process stops so a person can review it.
- Minimum permissions: each agent only has the tools it needs for its task.
- A build that always works: every iteration has to keep the KB compiling, without breaking what has already been tested.
- Improve the tool, not the case: if an error keeps repeating, the agent’s tool is improved instead of fixing objects one by one.
The development cycle in action
In the webinar, Gastón shows a real run on a demo ERP. First, the main agent reads the project status…. The main agent reads the project status, shows which stage it’s in and proposes the next step: migrating two work order screens to the web. Once approved, it delegates the task to the agent that converts the interface, and then an independent tester reviews the result. If it finds something, the cycle repeats until it’s ready.
The whole process can be followed step by step in monitoring tools, and it doesn’t depend on a single AI tool: the same development cycle works with Claude Code, Kiro or Codex, among others.
What kind of applications you can get
Starting from the same source Win application, the webinar shows different results:
- Web in GeneXus 18 without patterns: first with the default style and then with the client’s design system, in grid, card or compact view. It can coexist with the Win application on the same database.
- Web in GeneXus 18 with K2B Tools: column filters, card views, pivot tables and kanban boards with drag and drop, plus data export.
- React front end: a web application outside GeneXus, with filters, column selection and export to CSV or PDF.
- Desktop with Electron: an application with a local database that works offline and syncs the information when it connects to the central system.
- Mobile with React Native: a digital wallet application with fast navigation and effects specific to that technology.
The three paths cover a wide range of solutions, and they can be combined depending on what each organization needs.
FAQ: how to migrate a GeneXus application
What does the organization need to provide to get started?
The knowledge base, in any GeneXus version: a full backup, an XPZ or access to an environment where the KB lives. This is complemented by interviews and forms.
Which GeneXus versions can be migrated?
Legacy versions such as GeneXus 7.5, 8 or 9, as well as Evolution versions. In every case, the KB is moved to GeneXus 18.
My application is already on GeneXus 18, but its design is very basic. Can only the visual side be modernized?
Yes. The work can focus only on the visual experience, keeping the back end in GeneXus and adding a modern presentation layer, for example in React.
Are the agents subagents or skills?
They are subagents. A main agent communicates with the user and delegates each task to subagents organized in graphs, which make their own decisions. Each agent has its own skill, which gives it the context and guidance on how to work, and which is improved as the process is fine-tuned.
Does the whole system have to be migrated at once?
No. The migration is organized in deliveries, and you can start with a pilot to assess the results before expanding the scope.
Conclusion
To migrate a GeneXus application with AI is not to convert objects automatically. It’s an orderly process that starts by understanding the system, relies on a deterministic estimate and moves forward in deliveries with specialized agents and human decisions. It also leaves the system’s knowledge documented: its features, its rules and its migration strategy.
To learn more about how we approach technology upgrades, explore our Technological Evolution services.
Next step
Do you have a GeneXus application to migrate? Let’s start with a pilot and measure the results together.
-
Next
Webinar: How to mo...
