A IA consegue migrar código. Quem valida que o negócio continua funcionando?

A modernização de sistemas legados voltou ao centro da conversa sobre tecnologia.

Durante anos, muitas organizações sabiam que precisavam modernizar seus sistemas centrais. Também sabiam que esses projetos podiam levar tempo demais, exigir investimentos enormes e expor o negócio a um nível de risco difícil de aceitar.

A IA muda parte dessa equação.

Hoje, as equipes podem usar agentes para ler grandes bases de código, reconstruir a lógica de negócio durante a migração para uma nova stack tecnológica, gerar documentação, propor cenários de teste, identificar dependências e dar mais contexto a quem toma as decisões.

A reação do mercado colocou o tema em evidência. Em fevereiro de 2026, a Anthropic publicou dois conteúdos sobre a modernização de sistemas legados com IA:

• The Code Modernization Playbook, em que defende que agentes de IA especializados em tarefas de desenvolvimento de software podem ajudar a modernizar sistemas legados que antes pareciam complexos, arriscados ou caros demais.
• Um artigo sobre a modernização de COBOL com o Claude Code, em que afirma que ferramentas como o Claude Code podem automatizar fases de exploração e análise, mapear dependências, documentar fluxos, identificar riscos e apoiar o planejamento da migração de sistemas COBOL.

No mesmo mês, após o artigo sobre COBOL, a Reuters informou que a IBM sofreu sua maior queda em um único dia na bolsa desde 2000, com as ações recuando 13,2% em um só dia.

Para quem trabalha com qualidade de software, essa reação do mercado reforça algo que vemos em projetos reais: a IA pode acelerar o entendimento e a transformação do código, mas a capacidade de validar o comportamento continua definindo o risco real de uma migração.

Em sistemas críticos, migrar mais rápido gera valor quando as equipes também conseguem provar que o negócio continua funcionando como esperado.

Por que migrar sistemas legados¶

Uma migração pode responder a diferentes motivos técnicos, operacionais, econômicos e estratégicos. Às vezes, o gatilho é uma plataforma que está chegando ao fim do suporte. Em outros casos, o custo de manter uma infraestrutura antiga, licenças caras ou um conhecimento técnico muito específico começa a pesar demais.

Também pode haver motivos relacionados a escala, desempenho, segurança, compliance, integração com novos sistemas, troca de fornecedores, melhoria da experiência do usuário, disponibilidade, resiliência ou transformação digital.

“A migração busca preservar o valor funcional de um sistema importante para a organização enquanto atualiza sua base tecnológica”, explicou Guillermo Amorin, AI & Development Manager da Abstracta.

Guillermo explicou que esse processo pode afetar a arquitetura, os dados, os programas, as interfaces, a infraestrutura e as operações. Por isso, cada decisão técnica deve vir acompanhada de uma pergunta de qualidade:

Como vamos provar que o comportamento do qual o negócio depende continua funcionando?

O ponto-chave antes de migrar¶

A resposta a essa pergunta começa antes de transformar o código. “Em um sistema crítico, a organização precisa saber qual comportamento deve ser preservado, onde esse comportamento se expressa hoje e que evidências podem ser usadas para compará-lo com a nova versão”, destacou Guillermo.

Isso significa identificar regras de negócio, fluxos, dados, integrações, exceções, processos batch, permissões, relatórios e pontos de controle. Também significa definir testes, traces, métricas e critérios de aceitação para decidir se o sistema modernizado consegue sustentar a operação.

Em resumo, antes de migrar, a organização precisa entender se consegue observar, comparar e verificar que o negócio continua funcionando como esperado. Essa capacidade de verificação vai definir quão governável será a migração e que nível de risco a equipe pode assumir em cada etapa.

O código legado continua sustentando negócios reais¶

Quando falamos de sistemas legados, a imagem que costuma vir à mente é a de um software antigo que ninguém quer tocar. Mas a realidade costuma ser mais interessante: muitos sistemas legados funcionam todos os dias. Eles processam transações, calculam juros, movimentam dinheiro, gerenciam contas, controlam estoques, conectam equipes e sustentam operações que não podem parar.

Em bancos, seguros, varejo, governo, saúde e telecomunicações, muito valor ainda roda sobre tecnologias legadas: sistemas escritos em COBOL ou RPG, plataformas mainframe, bancos de dados antigos, processos batch de fechamento ou de cálculos em grande escala e arquiteturas monolíticas.

Muitos sistemas legados têm pontos fortes importantes na operação atual:

• São estáveis e sustentam processos críticos todos os dias.
• Processam grandes volumes de transações.
• Estão profundamente integrados ao negócio.
• Respondem a regras especiais, exceções e situações reais acumuladas ao longo de anos.
• Preservam um conhecimento operacional que muitas vezes não está totalmente documentado.

O desafio costuma aparecer quando a organização precisa mudar algo:

• Migrar para a nuvem ou para uma nova infraestrutura.
• Substituir uma plataforma que está chegando ao fim do suporte.
• Trocar de fornecedor ou reduzir a dependência tecnológica.
• Modernizar a arquitetura para que o sistema seja mais fácil de manter.
• Integrar o sistema a novos canais digitais, APIs ou plataformas.
• Reduzir custos de operação, licenciamento ou infraestrutura.
• Atender a uma necessidade de escala, disponibilidade ou resiliência.

É aí que surgem as perguntas difíceis.

Onde vive a lógica de negócio? Quais fluxos são realmente críticos? Quais regras históricas precisam ser preservadas? Como detectar uma diferença entre o sistema atual e o novo? Quem pode validar se um resultado é aceitável para o negócio?

As respostas costumam estar distribuídas. Parte delas vive no código. Outra parte está com as pessoas que conhecem o negócio. Também há sinais em logs, bancos de dados, incidentes históricos, processos batch, integrações e comportamentos que o sistema acumulou ao longo dos anos.

Em uma migração, essa dispersão do conhecimento é parte central do risco. Quanto mais difícil for entender e observar o comportamento atual, mais importante se torna construir evidências antes de fazer mudanças.

O difícil é saber o que mudou¶

Neste ponto, vale lembrar a definição de Michael Feathers em Working Effectively with Legacy Code: código legado é código sem testes.

Em uma migração, essa ideia é muito concreta. Se não temos testes, observabilidade ou uma forma clara de comparar comportamentos, dependemos demais da intuição, da memória e de validações parciais.

O sistema atual pode ter dívida técnica, regras históricas e exceções difíceis de explicar. Mas também é o sistema que sustenta a operação real hoje.

Por isso, cada diferença entre o sistema atual e o novo precisa de análise: pode ser um novo defeito, uma correção intencional, um bug histórico que veio à tona ou uma regra que o negócio precisa preservar.

Há alguns anos, vivemos isso de perto em um projeto que ainda nos ajuda a explicar o problema.

Uma história que ainda explica o problema¶

Há alguns anos, trabalhamos no core em RPG de uma rede de supermercados na América Latina.

A empresa tinha começado como uma pequena loja. Com o tempo, cresceu até 10 unidades. Depois, decidiu se expandir para uma nova região geográfica.

O problema era uma restrição histórica: o identificador de loja no sistema central só conseguia gerenciar até 10 unidades.

À primeira vista, parecia uma mudança limitada: permitir que o sistema gerenciasse mais uma loja. Na prática, porém, esse dado aparecia em fluxos centrais do negócio: contas, saldos, movimentações de dinheiro, operações internas, transações e processos diários.

Reunir o conhecimento não foi fácil: a documentação estava desatualizada ou simplesmente não existia, e havia partes do sistema que ninguém sabia explicar. Alguns módulos não eram tocados havia anos, algumas áreas do código deixavam a equipe cautelosa e o comportamento de certas funcionalidades não era totalmente claro.

Passamos um ano e meio entrevistando pessoas-chave, reconstruindo a lógica do sistema e escrevendo testes. Depois veio a mudança no código, que levou cerca de um mês e meio.

Mais de 90% do projeto foram testes.

O projeto deu certo, e essa experiência nos deixou uma ideia muito relevante: muitas migrações são adiadas ou ficam muito caras porque validar a mudança pode ser mais complexo do que escrevê-la.

A IA está começando a mudar essa conta. Ela nos dá novas capacidades para entender, explorar e verificar sistemas que antes exigiam muito trabalho manual.

O que muda com a IA: mais capacidade para entender e verificar¶

Com a IA, ganhamos mais alcance para estudar os sistemas legados antes de modificá-los.

Nesses sistemas, a lógica de negócio costuma estar distribuída em arquivos antigos, scripts, processos batch, integrações, comentários incompletos e decisões acumuladas ao longo de anos. Em muitos casos, o código é a fonte mais confiável para reconstruir como o sistema funciona.

Um agente pode ajudar a navegar por esse volume de informações, identificar dependências, detectar regras de negócio e transformar o conhecimento disperso em insumos que a equipe pode revisar. Essa capacidade muda o ponto de partida.

Tero: agentes para conversar com o código¶

Com o Tero, nosso framework open source para criar agentes de IA que trabalham com contexto, desenvolvemos capacidades para explorar grandes sistemas por meio de perguntas em linguagem natural.

A ideia é ampliar o alcance da equipe. Um agente pode ajudar a entender fluxos, dependências, regras de negócio, caminhos críticos e possíveis cenários com base em evidências do próprio sistema.

Podemos fazer perguntas concretas:

• O que acontece quando são calculados juros sobre uma dívida em atraso?
• Quais tabelas são atualizadas quando esta operação é confirmada?
• Quais partes do código participam deste fluxo?
• Quais APIs estão envolvidas nesta operação?
• Onde este dado é validado?
• Quais regras afetam este saldo?
• Quais processos rodam antes que este arquivo seja gerado?

As respostas funcionam como hipóteses de trabalho. Elas ajudam a equipe a investigar melhor, priorizar fluxos críticos, desenhar cenários e decidir qual comportamento precisa de validação.

Para a engenharia de qualidade, esse é o ponto central: entender melhor o sistema para priorizar fluxos críticos, desenhar cenários melhores e decidir qual comportamento precisa de validação.

A análise humana continua no centro, enquanto a IA ajuda a encontrar sinais, organizar informações e transformar o conhecimento oculto em insumos concretos para validar o comportamento.

Antes de comparar o sistema atual com o migrado, precisamos entender qual comportamento importa, onde vive a lógica e quais caminhos merecem prioridade. Conversar com o código ajuda a construir esse mapa.

O que exatamente significa testar em uma migração de sistemas legados?¶

Em uma migração de sistemas legados, a validação se concentra em provar a equivalência: a nova versão deve preservar o comportamento crítico do sistema atual.

Esse sistema atual já está em produção. Ele processa operações reais, sustenta processos de negócio e reflete regras acumuladas ao longo de anos. Também pode ter dívida técnica, exceções difíceis de explicar e bugs históricos com os quais o negócio já aprendeu a lidar.

Por isso, a migração combina risco, complexidade e incerteza. A equipe precisa identificar qual comportamento preservar, quais diferenças aceitar e quais sinais revisar antes de avançar.

Os testes de caracterização oferecem uma forma prática de abordar esse problema: capturamos como o sistema atual se comporta, executamos os mesmos cenários na versão migrada e comparamos os resultados.

O ponto crítico aparece quando comparamos as saídas. Cada diferença entre o sistema atual e a nova versão precisa ser classificada: pode ser um defeito introduzido pela migração, uma correção esperada, um bug histórico que veio à tona ou uma regra de negócio que a organização precisa preservar.

A validação acontece em dois níveis¶

1. Nível funcional: o comportamento do negócio¶

A equipe precisa entender como o sistema atual se comporta em fluxos reais. Isso inclui documentar processos, entrevistar usuários ou stakeholders do negócio, validar a documentação existente e desenhar casos de teste baseados em risco.

Neste ponto, o foco não está apenas em demonstrar a equivalência, mas também em entender o negócio e o sistema para desenhar testes capazes de verificar a correção. É também aqui que as equipes podem encontrar bugs existentes ou partes do sistema que já não são usadas.

2. Nível técnico: automação e evidências¶

A equipe precisa analisar código, logs, dependências, dados, restrições de ambiente, integrações e as possibilidades reais de automação. Esse nível permite gerar testes, revisar a cobertura, definir traces e detectar limites técnicos antes de comparar o sistema atual com a nova versão.

É uma abordagem complementar, com foco nos testes de caracterização: cobrir o sistema legado, salvar os estados inicial e final com todas as saídas e depois compará-los com a execução no sistema migrado.

A IA ajuda, mas não substitui o julgamento¶

Gerar testes a partir do código pode fornecer evidências, mas esses testes precisam de revisão. Um modelo pode criar asserções fracas, inventar mocks, fixar dados no código ou cobrir caminhos que não representam o uso real do sistema.

Além disso, o maior bloqueio muitas vezes não está no código, mas no acesso a ambientes, repositórios, licenças, dados de teste reais ou pessoas que conhecem o sistema e também sustentam a operação diária.

Por isso, a IA agrega valor quando ajuda as equipes a entender, priorizar e gerar evidências. Em uma migração crítica, essas evidências precisam de metodologia, experiência humana e critérios claros para decidir qual comportamento preservar, quais diferenças aceitar e quais sinais revisar antes de avançar.

Antes de migrar, medimos a capacidade de verificação¶

Os testes de caracterização ajudam a capturar e comparar comportamentos. No entanto, como mencionamos, antes de executar uma migração precisamos saber se a organização tem as condições reais para fazê-la com evidências.

Para responder a isso, olhamos o sistema a partir de várias dimensões:

Nem todas as dimensões têm o mesmo peso. Os testes nos fluxos críticos, a regressão contínua e a reversibilidade costumam definir o teto de risco: se não há uma rede mínima de segurança de testes, se não conseguimos executar controles de forma repetível ou se não existe uma forma realista de fazer rollback, a migração precisa de preparação antes de avançar.

Esse diagnóstico permite classificar o risco de cada parte do sistema. Quando a capacidade de verificação é baixa, o primeiro passo é construir uma rede mínima de evidências: testes de aprovação nos fluxos críticos, uma linha de base de comportamento, execução repetível, observabilidade básica e um plano de rollback.

Quando a capacidade de verificação é mais madura, a equipe pode avançar com fatias incrementais, quality gates e comparações mais automatizadas entre o sistema atual e o novo.

A conversa com o negócio também muda. A equipe pode discutir evidências: qual comportamento está coberto, quais diferenças apareceram, quem pode validá-las e que nível de risco a organização aceita antes de avançar.

Uma metodologia baseada em fatias¶

Uma migração completa precisa de uma forma de governar o risco com evidências. Na Abstracta, temos formalizado essa abordagem como uma metodologia baseada em fases e fatias.

Uma fatia pode ser uma unidade vertical de valor de negócio, uma camada técnica, um fluxo crítico ou uma parte do sistema com limites claros. Cada fatia tem seu próprio diagnóstico, perfil de risco e estratégia.

A metodologia se organiza em 6 fases:

• Descoberta e linha de base. Construímos um retrato verificável do sistema atual.
• Estratégia de migração. Definimos o que muda, em que ordem e com qual abordagem.
• Validação do comportamento. Criamos a rede de testes e evidências para comparar o sistema atual com o novo.
• Implementação. Executamos a mudança de forma gradual e usamos testes desde cedo para ajustar a estratégia.
• Cutover e rollout. Ampliamos o tráfego com evidências, monitoramento e um rollback preparado.
• Estabilização e handover. Fechamos o ciclo com operações, aprendizados, documentação e transferência de conhecimento.

O segredo é tratar cada parte do sistema de acordo com seu risco. Um core contábil, um processo batch, um módulo de relatórios e um gateway de API podem coexistir no mesmo sistema e exigir estratégias diferentes.

Uma fatia com poucas evidências precisa primeiro de uma rede de segurança. Uma fatia com testes, CI, observabilidade e rollback pode avançar com gates mais exigentes e automatizados.

Assim, a migração deixa de ser um projeto gigante e difícil de governar. Cada parte tem um diagnóstico, ações necessárias e evidências de progresso.

Conclusão: engenharia de qualidade com IA para migrar com controle¶

O risco de uma migração de sistemas legados é definido pela capacidade de verificar o comportamento no novo ambiente. Quando a equipe consegue capturar linhas de base, comparar saídas, observar efeitos e revisar as diferenças com as pessoas que conhecem o negócio, a migração avança com evidências.

A IA amplia essa capacidade: ajuda a explorar bases de código, documentar regras, priorizar cenários e gerar testes. O controle aparece quando a engenharia de qualidade transforma esse resultado em evidências verificáveis: testes de caracterização, regressão, observabilidade, desempenho, rollback e critérios de aceitação.

Estamos muito entusiasmados com o que a IA torna possível nesse campo. Usá-la bem também exige olhar com honestidade para os seus limites. Por isso, a qualidade de software precisa estar no centro da estratégia: no diagnóstico, no planejamento, na implementação e no rollout.

Em sistemas críticos, a responsabilidade continua sendo humana. Modernizar com controle significa usar a IA para acelerar o trabalho e a engenharia de qualidade para provar que o negócio continua funcionando como deveria.