Between
60% and 80% of IT budgets at large organizations go toward maintaining systems that already exist. Not to innovate. Not to grow. To keep what’s there running.
Those systems are not a problem. They are decades of business logic, implicit rules, exceptions learned in production, and institutional knowledge that exists nowhere else. They are, in the most literal sense, a company’s most valuable digital asset.
The problem is that no one fully understands them – because the original developers have retired, and the documentation either doesn’t exist or is out of date.
Studies by CAST Software show that up to 70% of legacy code is “dark matter”: no one knows exactly what it does or why it’s there. The team is afraid to touch certain parts. And the cost of maintaining without understanding – the knowledge debt – is the most expensive of all technical debts.
The question no one has been able to answer well until now is: how do you modernize a system like that without destroying what it contains?
The two approaches that Don’t solve the problem
The market offers two answers. Neither is enough.
The first is to rewrite the system in a modern language, assisted by AI tools. This is the most widely adopted path because it is visible and measurable in the short term. The problem here is structural: syntax is migrated, not semantics. The new system inherits the valid business logic along with the obsolete design decisions, accumulated workarounds, and conceptual debt from the original. Within a few years, that “new” system becomes the next legacy. The cycle repeats.
The second is to start from scratch. The promise is total design freedom. The real cost is the loss of the operational identity built over years: implicit rules, exceptions learned in production, behaviors adapted to the real customer. None of that is documented. It lives in the system. And when the new system goes to production, those cases resurface as critical bugs no one anticipated.
Although both approaches are legitimate, they share a common problem – neither resolves the central question. Where does the accumulated business knowledge live? How is it preserved while the system changes?
The Third Path: Document, Model, Generate
A different approach exists – adopted in very few cases but with qualitatively different results: document first, transform later.
The process has four steps:
- Document the current system with agentic AI, extracting what the code does and the implicit business knowledge it contains.
- Work on the processes within that documentation, not in the code.
- Use that to progressively build the company’s conceptual model: the company as code.
- Generate the new systems from that model, starting from the digital asset and leaving the technical debt behind.
This approach already exists and already has results in production. A leading investment management company in the financial sector faced exactly this challenge: 48 critical legacy code components, approximately 26,000 lines of code, cyclomatic complexity of up to 270 in its most critical programs, and pre-existing documentation: zero. The knowledge lived in the code and in the memory of two specialists.
By applying the GeneXus Legacy Modernization Framework (developed by Globant: Glob.AI OS + GeneXus), the results were measurable: 48 programs documented, with documentation quality validated at 9/10 by the client’s own experts. Documentation generation was accelerated 10x. And 100% of regression test cases passed, including financial precision to the decimal in the critical calculation algorithms.
Most importantly: the knowledge that existed only in the code and in the memory of two people is now explicit, documented, verifiable, and transferable.
How the Framework Works
The GeneXus Legacy Modernization Framework operates with three parallel and independent pipelines from the legacy system’s source code:
Documentation: agentic AI generates a structured technical summary that includes pseudocode, business rules, dependencies, and edge cases – understandable by both humans and LLMs.
Navigable site: the documentation is published as a versioned HTML portal, deliverable to the client.
GeneXus code: the legacy system is converted into objects in a GeneXus Knowledge Base, from which the target code is generated deterministically in any language (Java, .NET, or others).
The key lies in the verification process: before generating the final code, the framework verifies the logical parity between the pseudocode in the documentation and the GeneXus object created – both generated from the same source of truth: the original legacy code. If there are deviations, they are corrected. Only when the model is approved does GeneXus generate the target code deterministically: same input, same output, always.
GeneXus as an intermediate layer decouples two decisions that should not be made at the same time: preserving the business logic and choosing the target technology stack. The same model generates Java, .NET, or other targets. Validation is performed only once. And the migrated system can run in parallel with the legacy during the transition: incremental migration, no big bang, with zero production downtime.
GeneXus for Agents & the GeneXus Legacy Modernization Framework
The GeneXus Legacy Modernization Framework takes legacy systems developed in non-GeneXus technologies toward GeneXus, using GeneXus for Agents. This way, you get a KB ready for the GeneXus of today and tomorrow.
The framework solves legacy modernization under a simple principle: the conversation produces a formal model, and the code is one of its projections. The user converses with an agent in business language. When the model is complete and verified, the code is generated deterministically. If the business changes, the model changes, and the system calculates which parts to regenerate. The code is a consequence of the model.
That is the most important bridge: the modernized system is enabled to continue evolving with the new paradigm, incorporating new functionalities on a solid, verifiable, and auditable foundation.
The question You cannot leave unanswered
In today’s world, generating code is easy and cheap. That makes the risk of accumulating technical debt higher than ever – because it has never been easier to generate code without understanding it.
For every system you have today, it is worth asking three questions:
- Does an explicit model exist for how it should operate?
- Is that model understandable by a human and explainable by an LLM?
- Is the code an automatic consequence of that model?
If any answer is no, that system is accumulating debt. Silently, every day.
The path to reversing it begins by choosing the most critical, most opaque, or most costly-to-maintain module and applying the framework. The model you build today is the foundation for tomorrow.
To learn more about GeneXus, we invite you to visit the GeneXus™ FAQs page. You can also contact us through our offices or our worldwide distributor network.
You may also be interested in reading:
GeneXus and the Power of Knowledge
Does GeneXus for Agents Work? Here’s What Its Users Think
GeneXus for Agents: what it is, how it works, and how to get started