Entre
60% e 80% do orçamento de TI das grandes organizações é destinado a manter sistemas que já existem. Não a inovar. Não a crescer. A sustentar o que está.

Esses sistemas não são um problema. São décadas de lógica de negócio, regras implícitas, exceções aprendidas em produção e conhecimento institucional que não existe em nenhum outro lugar. São, no sentido mais literal, o ativo digital mais valioso da empresa.

O problema é que ninguém os entende completamente porque os desenvolvedores originais se aposentaram, e a documentação não existe ou está desatualizada.

Estudos da CAST Software mostram que até 70% do código legacy é “dark matter”: ninguém sabe exatamente o que faz nem por que está ali. A equipe tem medo de tocar em certas partes. E o custo de manter sem entender – a dívida de conhecimento – é a mais cara de todas as dívidas técnicas.

A pergunta que ninguém conseguiu responder bem até agora é: como se moderniza um sistema assim sem destruir o que ele contém?

Os dois enfoques que não resolvem o problema

O mercado oferece duas respostas. Nenhuma é suficiente.

A primeira é reescrever o sistema em uma linguagem moderna, assistida por ferramentas de IA. Este é o caminho mais adotado porque é visível e mensurável a curto prazo. O problema aqui é estrutural: migra-se a sintaxe, não a semântica. O novo sistema herda a lógica de negócio válida junto com as decisões de design obsoletas, os workarounds acumulados e a dívida conceitual do original. Em poucos anos, esse sistema “novo” será o próximo legacy. O ciclo se repete.

A segunda é começar do zero. A promessa é liberdade total de design. O custo real é a perda da identidade operacional construída durante anos: regras implícitas, exceções aprendidas em produção, comportamentos adaptados ao cliente real. Nada disso está documentado. Está no sistema. E quando o sistema novo entra em produção, esses casos reaparecem como bugs críticos que ninguém antecipou.

Embora ambos os enfoques sejam legítimos, têm um problema em comum, e é que nenhum resolve a pergunta central. Onde vive o conhecimento de negócio acumulado? Como ele é preservado enquanto o sistema muda?

O terceiro caminho: documentar, modelar, gerar

Existe uma abordagem diferente, adotada em muito poucos casos, mas com resultados qualitativamente distintos: documentar primeiro, transformar depois.

O processo tem quatro etapas:

1. Documentar o sistema atual com IA agêntica, extraindo o que o código faz e o conhecimento de negócio implícito que ele contém.
2. Trabalhar sobre os processos nessa documentação, não no código.
3. Ir construindo, com isso, o modelo conceitual da empresa: a empresa como código.
4. Gerar os novos sistemas a partir desse modelo, partindo do ativo digital e deixando para trás a dívida técnica.

Essa abordagem já existe e já tem resultados em produção. Uma empresa líder em gestão de investimentos do setor financeiro enfrentava exatamente esse desafio: 48 componentes de código legacy crítico, ~26.000 linhas de código, complexidade ciclomática de até 270 em seus programas mais críticos, e documentação preexistente: zero. O conhecimento vivia no código e na memória de dois especialistas.

Aplicando o GeneXus Legacy Modernization Framework (desenvolvido pela Globant: Glob.AI OS + GeneXus), os resultados foram mensuráveis: 48 programas documentados, com qualidade de documentação validada em 9/10 pelos próprios especialistas do cliente. A geração de documentação foi acelerada em 10x. E 100% dos casos de teste de regressão foram aprovados, incluindo precisão financeira ao decimal nos algoritmos de cálculo críticos.

O mais importante: o conhecimento que só existia no código e na memória de duas pessoas hoje é explícito, documentado, verificável e transferível.

Como funciona o framework

O GeneXus Legacy Modernization Framework opera com três pipelines paralelos e independentes a partir do código-fonte do Sistema Legacy:

Documentação: IA agêntica gera um resumo técnico estruturado que inclui pseudocódigo, regras de negócio, dependências e casos de borda, compreensível por humanos e por LLMs.

Site navegável: a documentação é publicada como portal HTML versionado, entregável ao cliente.

Código GeneXus: o Sistema Legacy é convertido em objetos em uma Knowledge Base GeneXus, a partir dos quais o código destino é gerado de forma determinística em qualquer linguagem (Java, .NET ou outras).

A chave está no processo de verificação: antes de gerar o código final, o framework verifica a paridade lógica entre o pseudocódigo da documentação e o objeto GeneXus criado, ambos gerados a partir da mesma fonte de verdade: o código legacy original. Se houver desvios, eles são corrigidos. Somente quando o modelo está aprovado, o GeneXus gera o código destino de forma determinística: para a mesma entrada, a mesma saída, sempre.

O GeneXus como camada intermediária desacopla duas decisões que não deveriam ser tomadas ao mesmo tempo: preservar a lógica de negócio e escolher o stack tecnológico destino. O mesmo modelo gera Java, .NET ou outros targets. A validação é realizada uma única vez. E o sistema migrado pode rodar em paralelo com o legacy durante a transição: migração incremental, sem big bang, com zero corte em produção.

GeneXus for Agents & o GeneXus Legacy Modernization Framework

O GeneXus Legacy Modernization Framework leva sistemas legados desenvolvidos em tecnologias não GeneXus para o GeneXus, utilizando o GeneXus for Agents. Assim, você obtém uma KB pronta para o GeneXus de hoje e de amanhã.

O framework resolve a modernização do legado sob um princípio simples: a conversa produz um modelo formal, e o código é uma de suas projeções. O usuário conversa com um agente em linguagem de negócio. Quando o modelo está completo e verificado, o código é gerado de forma determinística. Se o negócio muda, muda o modelo, e o sistema calcula quais partes regenerar. O código é consequência do modelo.

Essa é a ponte mais importante: o sistema modernizado fica habilitado para continuar evoluindo com o novo paradigma, incorporando novas funcionalidades sobre uma base sólida, verificável e auditável.

A pergunta que você não pode deixar sem resposta

No mundo de hoje, gerar código é fácil e barato. Isso faz com que o risco de acumular dívida técnica seja maior do que nunca, porque nunca foi tão fácil gerar código sem entendê-lo.

Para cada sistema que você tem hoje, vale a pena fazer três perguntas:

• Existe um modelo explícito de como ele deve operar?
• Esse modelo é compreensível por um humano e explicável por um LLM?
• O código é uma consequência automática desse modelo?

Se alguma resposta for não, esse sistema acumula dívida. Silenciosamente, todos os dias.

O caminho para revertê-lo começa escolhendo o módulo mais crítico, mais opaco ou mais caro de manter, e aplicando o framework. O modelo que você constrói hoje é a base do amanhã.

Para saber mais sobre o GeneXus, convidamos você a consultar a página GeneXus™ FAQs. Você também pode nos contatar por meio de nossos escritórios ou de nossa rede de distribuidores mundial.

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