Como modernizar um sistema legado .NET sem reescrever tudo

Quando a reescrita total é uma má decisão

Se o sistema ainda sustenta processos críticos, possui regra de negócio acumulada e depende de integrações já em produção, trocar tudo de uma vez cria risco operacional alto. Além disso, times costumam subestimar prazo, regressão e custo de reaprendizado.

O efeito prático é conhecido: meses de projeto, pouca entrega real, backlog paralelo aumentando e a operação continuando dependente do legado antigo.

O que modernizar primeiro

• Componentes mais frágeis ou com maior custo de manutenção
• Integrações que travam fluxo operacional
• Rotinas que geram fila manual ou retrabalho
• Partes do sistema que impedem automação, observabilidade ou evolução arquitetural

O padrão que torna isso possível: Strangler Fig

Modernizar sem reescrever não é força de vontade, é técnica. O padrão que sustenta essa abordagem tem nome: Strangler Fig, descrito por Martin Fowler a partir da figueira-mata-pau, que cresce em volta da árvore hospedeira até substituí-la por completo.

Na prática funciona assim: você coloca uma camada de roteamento na frente do sistema antigo. Cada funcionalidade nova ou reescrita passa a ser atendida pelo código novo; todo o resto continua indo para o legado. A cada entrega, uma fatia a mais migra. O sistema antigo vai sendo estrangulado aos poucos, e em nenhum momento existe um "dia da virada".

A diferença prática para a reescrita total é o risco: se uma fatia dá errado, você reverte aquela rota — não o projeto inteiro. E a operação nunca fica esperando o novo sistema ficar pronto para receber valor.

Antes de tocar no código: testes de caracterização

O maior risco de mexer em legado não é o código ser feio. É ninguém saber exatamente o que ele faz. Boa parte dos sistemas antigos tem comportamento que ninguém documentou e que a operação já incorporou como regra — inclusive bugs que viraram processo.

A técnica que resolve isso é o teste de caracterização: em vez de escrever testes do que o sistema deveria fazer, você escreve testes do que ele faz hoje, inclusive o comportamento estranho. Eles não validam corretude — validam que você não mudou nada sem querer.

Sem essa rede, qualquer refatoração vira aposta. Com ela, você ganha permissão para mexer. É a razão de Working Effectively with Legacy Code, do Michael Feathers, continuar sendo a referência do tema duas décadas depois.

Isolar o legado com uma camada anticorrupção

Quando o código novo precisa conversar com o antigo, existe um risco silencioso: os modelos ruins do legado vazam para dentro do código novo, e em pouco tempo você tem dois sistemas com o mesmo problema.

A camada anticorrupção (anti-corruption layer) evita isso. É uma fronteira de tradução: o código novo trabalha com o modelo que faz sentido para o domínio, e essa camada traduz para o formato que o legado entende. Quando o legado finalmente sai, você joga a camada fora — e o código novo não precisa mudar.

O que trava especificamente em .NET

Em sistemas .NET, o bloqueio para sair do .NET Framework raramente é o código de negócio. São as dependências presas ao Windows e ao ecossistema antigo:

• Web Forms — não tem caminho de migração direto; exige reescrita da camada de apresentação
• WCF — do lado servidor, precisa virar API ou usar CoreWCF
• System.Web — acoplamento com HttpContext espalhado pela aplicação
• Dependências de terceiros sem versão para .NET moderno
• Integrações COM, serviços do Windows e agendamentos amarrados ao servidor

O caminho mais previsível é atacar isso por camadas: extrair a lógica de negócio para bibliotecas compatíveis com .NET Standard ou .NET moderno, deixando por último a camada presa ao .NET Framework. Isso permite que grande parte do código já rode nos dois mundos enquanto a fronteira ainda não migrou.

Os erros que fazem a modernização falhar

• Big bang disfarçado — chamar de "modernização por etapas" um projeto que só entrega valor no final. Se a operação não recebe nada por seis meses, é reescrita com outro nome.
• Refatorar sem rede — mexer na estrutura antes de ter testes de caracterização. É quando aparece a regressão que ninguém explica.
• Modernizar o que não dói — começar pela parte tecnicamente mais interessante em vez da que custa caro. Dá satisfação técnica e nenhum resultado.
• Trocar de stack sem resolver o problema — migrar de framework mantendo o mesmo acoplamento e a mesma ausência de testes. Muda a versão, não o custo de manutenção.
• Não desligar o antigo — deixar o legado no ar "por segurança" indefinidamente. Manter dois sistemas custa mais que manter um ruim.

Quando modernizar não é a resposta

Nem todo legado precisa ser tocado. Se o sistema é estável, muda pouco, não trava integração nova e ninguém tem medo de fazer deploy, ele está fazendo o trabalho dele. Código antigo que funciona e não atrapalha não é dívida técnica — é software amortizado.

Modernização se justifica quando existe custo mensurável: backlog parado, incidente recorrente, integração que não avança, ou dependência de poucas pessoas para mexer em partes críticas. Sem um desses, o projeto vira estética cara.

Como reduzir risco no processo

O caminho mais seguro combina diagnóstico técnico, priorização por impacto, entregas menores e validação próxima da operação. Isso permite capturar ganho real sem colocar o negócio inteiro em dependência de uma grande virada.

Quando bem conduzida, a modernização abre espaço para automação, melhoria de UX, padronização de código e uso de IA aplicada onde faz diferença.

Quando sair do artigo e falar com um fornecedor

Se a empresa já sente backlog parado, medo de deploy, integrações frágeis ou dependência de poucas pessoas, a conversa deixa de ser apenas educacional. Nessa hora, vale abrir uma conversa comercial para entender escopo inicial, prioridade e risco de execução.

Se esse é o seu caso, comece pela consultoria .NET para modernização ou vá direto para a página de modernização de sistema legado .NET, onde a ArrexTec explica como conduz diagnóstico e execução por etapas.

Perguntas frequentes

É possível modernizar um sistema legado sem reescrever o código?

Sim. A abordagem incremental — Strangler Fig, extração de módulos e camada anticorrupção — permite substituir o sistema por partes, mantendo o legado em produção enquanto as fatias novas assumem o tráfego. Reescrever tudo de uma vez é uma escolha, não uma exigência técnica.

Quanto tempo leva modernizar um sistema legado .NET?

Depende do acoplamento e da cobertura de testes, não do tamanho do código. O que muda o prazo de forma decisiva é o quanto a lógica de negócio está misturada com a camada presa ao .NET Framework. A vantagem da abordagem incremental é que a primeira entrega útil sai em semanas, não no fim do projeto.

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

Sim, e é justamente o motivo de existir a abordagem incremental. Como o sistema antigo continua atendendo tudo que ainda não migrou, não existe janela de indisponibilidade para uma virada geral. O risco fica contido na fatia que está sendo trocada.

Preciso migrar do .NET Framework para o .NET moderno?

Não necessariamente de imediato, mas o .NET Framework não recebe mais evolução. Em geral vale extrair primeiro a lógica de negócio para bibliotecas compatíveis com o .NET moderno e deixar a camada acoplada ao .NET Framework (Web Forms, WCF, System.Web) por último.

Como saber por onde começar?

Pelo que custa caro hoje: o que gera incidente recorrente, o que trava integração nova, o que ninguém tem coragem de alterar. Começar pela parte tecnicamente mais interessante é o erro mais comum — dá satisfação técnica e nenhum resultado mensurável.