Como modernizar um sistema legado com agentes de código: passo a passo

Publicado em 12 de outubro de 2026 · atualizado em 13 de outubro de 2026

Modernizar um sistema legado com agentes de código é trocar o sistema antigo por partes, com o novo construído ao lado e o antigo ainda atendendo. Os agentes leem o código atual, escrevem testes que fixam o que ele faz hoje e constroem cada parte nova. O time decide a ordem, lê o que vai para produção e define quando cada parte assume.

Este guia parte de uma decisão já tomada: o sistema precisa mudar. Se essa conta ainda não foi feita, comece por o que é um sistema legado e quando modernizar.

Se ainda falta saber em que nível de maturidade a empresa está antes do passo a passo, use o autodiagnóstico de maturidade em modernização.

Antes de começar: por que trocar por partes

Reescrever tudo de uma vez parece mais simples. Martin Fowler, que deu o nome de strangler fig ao caminho alternativo, conta que ele e os colegas viram esse plano dar errado na maior parte das vezes. Substituir um sistema sério leva tempo, os usuários não podem esperar por funcionalidades novas, e é difícil descobrir os detalhes do que o sistema antigo faz (Fowler, Strangler Fig, 2024). Na troca por partes, cada pedaço novo é pequeno, e o risco de colocá-lo no ar também.

Agentes de código não mudam essa lógica. Eles tornam mais barato ler e alterar muito código, o que acelera os passos 1, 3 e 4. O que continua difícil é conferir, e por isso a supervisão entra desde o passo 1. Se a decisão de modernizar ainda depende de números, os dados de custo (Stripe, Protiviti, GAO) estão em o que é um sistema legado e quando modernizar.

O que muda numa modernização: arquitetura, stack e práticas

Levar o sistema como está para a nuvem, o chamado lift-and-shift, muda onde ele roda, mas mantém o mesmo código e os mesmos problemas. O guia de modernização de código publicado pela Anthropic, The Code Modernization Playbook, organiza, na visão da Anthropic, o que precisa mudar em três frentes, sempre preservando a regra de negócio que o sistema acumulou:

Arquitetura: como o sistema é dividido. Sair de um bloco único, em que qualquer mudança mexe em tudo, para partes que sobem e escalam separadas (o guia defende microsserviços e arquitetura nativa de nuvem). Assim uma tela nova vai para o ar sem pôr em risco o processamento central.
Stack: com que tecnologia ele roda. Linguagens e frameworks com suporte ativo, correções de segurança em dia e gente disponível no mercado para manter.
Práticas: como o time entrega. Integração e entrega contínuas, testes automatizados e ambientes descritos em código, para que homologação e produção sejam iguais e cada mudança possa ser desfeita.

Quando a migração pura ainda faz sentido e como combiná-la com a troca por partes está em lift and shift vs modernização.

As três andam juntas. Código novo entregue do jeito antigo, com deploy manual e sem testes, tende a virar o próximo legado. Os passos abaixo tratam das três: o inventário e a escolha das partes definem a arquitetura, a parte nova nasce na stack nova, e os testes de caracterização e o critério de corte já são a prática nova.

Passo 1. Faça o inventário

Antes de qualquer linha nova, os agentes leem o código e a documentação existentes. Essa leitura vira a base de consulta dos passos seguintes (na Ithaca, a Knowledge base). O inventário responde a cinco perguntas:

Quais funções o sistema cumpre para o negócio, e quem depende de cada uma.
Onde estão as regras. Em sistema legado, muitas só existem no código; a documentação descreve o sistema de anos atrás.
O que muda com mais frequência e o que consome mais horas de manutenção.
Com o que o sistema conversa: bancos, filas, outros sistemas, rotinas agendadas.
O que ninguém usa mais. Fowler lembra que boa parte do comportamento de um sistema antigo já não é desejada, e reconstruí-la é desperdício. O inventário é a hora de marcar o que vai ser desligado em vez de migrado.

Os agentes fazem o primeiro levantamento. O time confere com quem opera o sistema, porque uma regra encontrada no código pode ser um bug que virou funcionalidade. Quando quem opera o sistema é uma ou duas pessoas, e a tecnologia é COBOL, Delphi ou VB6, esse inventário tem prazo; veja falta de desenvolvedor COBOL, Delphi e VB6.

Passo 2. Escolha a primeira parte

Não comece pelo sistema inteiro nem pela parte mais crítica. Comece por uma parte que dá para conferir de ponta a ponta: entra um pedido, sai um resultado, e dá para comparar o resultado do antigo com o do novo. Entre essas, vale escolher a que mais consome manutenção hoje, onde o ganho aparece primeiro.

Para separar essa parte, é preciso achar uma costura: um ponto em que dá para desviar as chamadas do antigo para o novo sem mexer no resto, como uma rota de API, uma tela ou um tipo de mensagem numa fila. Se ainda não está claro onde o esforço vai, um sinal prático é a fatia da semana do time que vai para manutenção. O guia da Anthropic usa, como regra prática, uma fatia acima de 40% como sinal claro de que vale modernizar. É um critério do fornecedor, não um dado de pesquisa.

Se ainda falta traduzir o peso em horas e orçamento, o mapa de onde o custo aparece e um método simples de estimativa estão em custo da dívida técnica.

Passo 3. Fixe o comportamento atual com testes de caracterização

Um teste de caracterização registra o que o sistema faz hoje, certo ou errado. Michael Feathers, que descreveu a prática, resume assim: o objetivo é documentar o comportamento real do sistema, e não o comportamento que você gostaria que ele tivesse (Feathers, Characterization Testing, 2016).

Esses testes viram a régua da troca. A parte nova só entra quando passa nos mesmos testes que o antigo passa, ou quando o time decidiu, por escrito, mudar um comportamento.

Agentes de código escrevem testes de caracterização rápido e em volume. O que o time confere é a cobertura: se os testes pegam as regras de que o negócio depende, e não só os caminhos fáceis. O detalhe está em refatoração com IA sem perder exatidão.

Passo 4. Construa o sistema novo ao lado

O antigo continua atendendo enquanto os agentes escrevem a parte nova a partir do inventário e dos testes. O time revisa o desenho e o código.

Durante a convivência, alguma estrutura serve só para os dois sistemas conversarem: um roteador que decide quem atende cada chamada, uma sincronização de dados, um adaptador. Fowler chama isso de arquitetura de transição. É código que vai ser apagado no fim e, segundo ele, mesmo assim compensa, porque reduz o risco e antecipa o retorno.

Passo 5. Troque por partes

Com a parte nova passando nos testes, as chamadas começam a ir para ela. Quatro práticas reduzem o estrago se algo der errado:

Comece por uma fatia do tráfego (um grupo de usuários, um tipo de pedido) antes de passar tudo.
Compare os resultados do antigo e do novo com a mesma entrada, quando der.
Tenha a volta pronta: desviar as chamadas de novo para o antigo precisa ser simples e testado.
Uma parte de cada vez. A próxima começa quando a anterior estiver estável em produção.

Uma falha continua possível, e algumas trocas, principalmente as que mexem em dados, podem pedir janela de manutenção. O que a troca por partes muda é o tamanho do estrago.

Passo 6. Defina o critério de corte

Há dois cortes, e os dois precisam de critério escrito antes de acontecer.

Quando uma parte assume. Por exemplo: passa em todos os testes de caracterização; rodou com uma fatia do tráfego por um período combinado sem divergência que o time não tenha explicado; a volta foi testada; alguém do time leu e aprovou o que vai para produção.

Quando o antigo é desligado. Por exemplo: nenhuma chamada chega à parte antiga há um período combinado; os dados foram migrados e conferidos; as integrações que dependiam dela apontam para o novo. Sem esse critério, o antigo tende a ficar ligado "por garantia", e o custo de manter dois sistemas continua.

Duas regras que valem em todos os passos

Pessoas leem o que vai para produção. O time define o limite de autonomia dos agentes: o que podem fazer sem aprovação e o que precisa de aprovação antes de executar. A Ithaca opera no nível 4 da escala de autonomia proposta por Dan Shapiro, com uma regra a mais: pessoas do time leem o que vai para produção. O nível 5 é a dark factory, em que o código vai para produção sem que ninguém o leia.

Cada sessão fica registrada. Pedido, passos, modelo, custo, resultado e autoria. Numa modernização que dura meses, é esse registro que mostra por que uma regra foi mantida ou mudada e quem aprovou a troca. O que registrar está em observabilidade de agentes de código.

Exemplo: o sistema de assinaturas da Dr. Consulta

A Dr. Consulta modernizou seu sistema de assinaturas, com oito anos em produção, usando a plataforma de desenvolvimento agentic da Ithaca. O método foi construir ao lado e trocar por partes, com o sistema atual seguindo em operação. Em relação ao período anterior à modernização, o custo de infraestrutura ficou 75% menor, e uma feature representativa, que levava duas semanas, passou a levar até três dias. É um exemplo, não uma medição do backlog inteiro. O time da Dr. Consulta supervisionou os agentes de código o tempo todo. O que o caso mostra, e o que ele não prova, está no case Dr. Consulta.

Checklist

Inventário feito, incluindo o que será desligado em vez de migrado.
Primeira parte escolhida: conferível de ponta a ponta, com uma costura para desviar as chamadas.
Testes de caracterização cobrindo as regras de que o negócio depende.
Critério escrito para cada parte assumir, para a volta e para o antigo ser desligado.
Plano cobre arquitetura, stack e forma de entrega, e não só a troca de servidor.

O método da plataforma da Ithaca para esse trabalho está em modernização de sistemas legados sem parar a operação.

Perguntas frequentes

Por onde começar a modernizar um sistema legado?

Pelo inventário e por uma parte só. Levante o que o sistema faz, onde estão as regras e o que ninguém usa mais. Depois, escolha uma parte que dá para conferir de ponta a ponta, de preferência a que mais consome manutenção, e troque essa antes da próxima.

Dá para modernizar um sistema legado sem parar a operação?

É para isso que serve a troca por partes. O sistema novo é construído ao lado do antigo, que continua atendendo, e as funções passam por partes, cada uma conferida antes de entrar. Uma falha continua possível, e algumas trocas podem pedir janela de manutenção. Não há promessa de zero downtime, mas o estrago fica limitado ao tamanho da parte.

Migrar para a nuvem (lift-and-shift) é modernizar?

Sozinho, não. Levar o sistema como está para outro servidor muda onde ele roda e mantém o mesmo código, os mesmos acoplamentos e a mesma forma de entregar. Modernizar mexe em três coisas: como o sistema é dividido, com que tecnologia ele roda e como o time entrega. A migração pode ser um passo, mas não o último.

O que são testes de caracterização?

Testes de caracterização registram o que o sistema faz hoje, mesmo que pareça errado. Michael Feathers descreveu a prática para dar segurança a quem precisa mudar código sem especificação. Numa modernização, eles viram a régua: a parte nova só entra quando se comporta como a antiga, ou quando o time decidiu mudar aquele comportamento.

Qual é o papel das pessoas quando agentes de código fazem a modernização?

Decidir e conferir. O time escolhe a ordem das partes, define o que os agentes fazem sem aprovação, lê o que vai para produção e aprova cada corte. Cada sessão dos agentes fica registrada, então dá para saber depois quem aprovou o quê.

Agendar demonstração

Se você já tem a primeira parte candidata, o próximo passo é ver a plataforma funcionando sobre ela e conferir se dá para trocá-la de ponta a ponta. A implantação começa por ela, lado a lado com o seu time: agentes de código escrevem, o time supervisiona e aprova o que vai para produção, e cada sessão fica registrada. Agendar demonstração →

Referências

Martin Fowler, "Strangler Fig", 22 de agosto de 2024: https://martinfowler.com/bliki/StranglerFigApplication.html
Michael Feathers, "Characterization Testing", 8 de agosto de 2016: https://michaelfeathers.silvrback.com/characterization-testing
Anthropic, "The Code Modernization Playbook" (material de fornecedor, sem data no documento; acessado em 13 de outubro de 2026): https://resources.anthropic.com/code-modernization-download