Modernize o backend .NET sem apostar tudo em uma reescrita.

Na maioria dos backends críticos, a primeira opção não deveria ser reescrever. O caminho mais seguro costuma ser tornar o comportamento atual observável, proteger o que importa e substituir partes por etapas reversíveis.

Uma reescrita pode ser necessária quando a plataforma não permite mais operar, contratar, corrigir vulnerabilidades ou atender requisitos essenciais. Mas “o código está ruim” não basta para justificar trocar de uma vez um sistema que concentra regras aprendidas ao longo dos anos.

Por que reescritas completas falham

O sistema legado contém dois tipos de conhecimento:

• o comportamento documentado;
• as exceções que só aparecem nos dados, integrações e rotinas reais.

Uma equipe nova costuma enxergar o primeiro e descobrir o segundo tarde. Enquanto o sistema antigo continua mudando, a nova implementação persegue um alvo móvel. O resultado pode ser duplicidade de manutenção, atraso e uma troca de risco técnico por risco operacional.

Antes de decidir, responda:

• quais fluxos realmente impedem evolução;
• quais partes ainda são estáveis;
• quais contratos externos não podem mudar;
• que evidência prova equivalência;
• como voltar atrás se uma etapa falhar.

Etapa 1: torne o problema reproduzível

Modernização começa por executar o sistema de forma conhecida.

Registre:

• versão do runtime e SDK;
• dependências e fontes de pacote;
• configuração necessária por ambiente;
• comandos de build, teste e execução;
• bancos, filas e serviços externos;
• falhas atuais que já existem na baseline.

O objetivo é separar defeito preexistente de regressão introduzida pela mudança. Sem uma baseline reproduzível, cada erro durante a modernização vira debate.

Também vale identificar dependências sem manutenção, pacotes presos a APIs antigas e componentes que só funcionam em um ambiente específico.

Etapa 2: descubra os fluxos que não podem quebrar

Nem toda linha merece a mesma proteção. Mapeie os caminhos que concentram valor ou risco:

• autenticação e autorização;
• criação e alteração de registros importantes;
• cálculos e regras de elegibilidade;
• integrações externas;
• processamento assíncrono;
• relatórios ou eventos usados por outras áreas;
• tratamento de dados sensíveis.

Para cada fluxo, descreva entrada, saída, estado persistido, efeitos colaterais e falhas esperadas.

Esse inventário define a ordem da modernização. Componentes periféricos podem esperar; bordas críticas precisam de evidência antes da alteração.

Etapa 3: adicione testes de caracterização

Testes de caracterização registram o que o sistema faz hoje, inclusive comportamentos estranhos que ainda não podem ser mudados. Eles não declaram que o legado está correto. Criam um alarme para mudanças não intencionais.

Comece por:

1. exemplos representativos;
2. limites e entradas inválidas;
3. autorização por perfil ou organização;
4. persistência e transações;
5. contrato das APIs;
6. repetição e idempotência;
7. falha de dependências externas.

Quando o código é difícil de instanciar, teste pela borda mais estável disponível: endpoint, serviço, repositório ou banco efêmero. Depois aproxime os testes do domínio conforme as dependências forem separadas.

Evite alterar expectativas apenas para deixar a suíte verde. Uma diferença precisa ser classificada como correção desejada ou regressão.

Etapa 4: instale observabilidade antes da troca

Logs estruturados, métricas e rastreamento ajudam a responder se o novo caminho se comporta como o anterior. Não registre dados pessoais, tokens ou payloads sensíveis por conveniência.

Observe pelo menos:

• taxa e categoria de erro;
• latência por operação;
• dependência que falhou;
• correlação entre requisições;
• volume processado;
• filas pendentes e tentativas;
• versão da aplicação em execução.

Observabilidade sem ação definida vira armazenamento caro. Para cada sinal, estabeleça quem olha e qual decisão ele suporta.

Etapa 5: crie bordas substituíveis

O objetivo não é aplicar uma arquitetura de referência em todo o código. É criar pontos onde uma parte possa mudar sem contaminar as demais.

Algumas bordas úteis:

• interfaces para integrações externas;
• serviços de aplicação para casos de uso;
• adaptadores para persistência;
• modelos de entrada separados de entidades;
• configuração tipada;
• relógio, identificadores e mensageria injetáveis quando necessário.

Extraia uma borda porque existe uma troca, um teste ou uma dependência concreta. Abstrações sem pressão real apenas mudam a forma da complexidade.

Etapa 6: escolha a estratégia por componente

Cada parte pode seguir um caminho diferente.

Manter

Código estável, compreendido e compatível não precisa ser refeito para parecer moderno.

Encapsular

Uma dependência antiga pode continuar atrás de um adaptador enquanto o restante evolui. Isso reduz a área de contato e prepara uma troca futura.

Atualizar no lugar

Bibliotecas e runtime podem avançar em passos pequenos, corrigindo incompatibilidades com feedback rápido de build e testes. O destino — .NET 8 ou outra versão suportada e compatível com o contexto — deve ser uma decisão baseada em dependências, janela de suporte e ambiente, não um número escolhido por marketing.

Substituir por fluxo

Quando um módulo concentra defeitos ou bloqueios, implemente o novo caminho para um caso de uso delimitado. Direcione uma parcela controlada, compare sinais e preserve retorno ao anterior.

Retirar

Funcionalidade sem uso comprovado pode ser desativada depois de medir chamadas e dependências. Remover antes de observar transforma suposição em incidente.

Etapa 7: trate dados como uma migração própria

Código pode voltar rapidamente; dados gravados por uma versão nova podem não voltar.

Para cada mudança de schema:

• prefira alterações compatíveis antes das destrutivas;
• separe expansão e contração;
• faça backfill observável;
• valide contagens e invariantes;
• limite lotes;
• tenha backup e procedimento de restauração;
• defina como versões diferentes convivem durante a transição.

Uma coluna renomeada de uma vez pode quebrar aplicação, jobs e relatórios. Adicionar, preencher, migrar leitura, migrar escrita e só depois remover cria etapas verificáveis.

Etapa 8: desenhe rollback antes do deploy

Rollback não é apenas publicar o binário anterior. Pode envolver feature flag, roteamento, compatibilidade de banco, filas e eventos já emitidos.

Um plano útil responde:

• qual sinal interrompe a mudança;
• quem tem autoridade para interromper;
• qual comando ou ação reverte;
• quanto tempo a reversão leva;
• quais dados precisam de reconciliação;
• como confirmar que o estado voltou ao esperado.

Se a mudança não é reversível, o critério de entrada precisa ser proporcionalmente mais forte.

Um recorte de contexto regulado, sem extrapolar a evidência

Há experiência publicável em backend .NET 8 para uma plataforma de seguros e serviços financeiros, com requisitos de confidencialidade, segregação por organização e rastreabilidade.

Essa descrição não identifica cliente ou seguradora e não afirma produção, homologação, integração externa ou conformidade regulatória. O que ela sustenta é um tipo de restrição: acesso precisa respeitar fronteiras, decisões precisam deixar rastro e mudanças precisam ser verificadas.

Esses princípios ajudam em qualquer backend crítico, mesmo quando o domínio é outro.

Como saber se a modernização está avançando

Não use apenas porcentagem de arquivos migrados. Procure capacidades:

• build reproduzível;
• fluxo crítico protegido por testes;
• falha importante observável;
• dependência isolada;
• componente atualizado sem mudar contrato;
• migração de dados verificada;
• deploy com retorno definido;
• documentação suficiente para outra pessoa operar.

Cada capacidade reduz incerteza para a próxima etapa.

Quando a reescrita pode ser justificável

Considere uma reconstrução mais ampla quando:

• o runtime não pode ser mantido com segurança;
• a plataforma impede requisitos essenciais;
• não existe caminho incremental viável;
• contratos e dados podem ser congelados;
• há capacidade para operar antigo e novo durante a transição;
• equivalência pode ser testada;
• o custo de manter o legado foi medido, não apenas percebido.

Mesmo nesse cenário, migrar por domínio ou fluxo costuma oferecer feedback melhor do que uma troca única.

Fontes oficiais para aprofundar

• Migrate from ASP.NET Framework to ASP.NET Core — Microsoft Learn, atualizado em 8 de julho de 2026. O guia diferencia migração direta e incremental e recomenda etapas para aplicações grandes, complexas ou que precisam continuar operando.
• Strangler Fig Pattern — Azure Architecture Center, atualizado em 2 de junho de 2026. O padrão descreve coexistência, substituição gradual e retirada controlada do legado.

Resumo

Modernizar backend .NET é reduzir o risco de mudança enquanto a capacidade de entrega aumenta. Reproduza, observe, proteja, crie bordas, escolha uma estratégia por componente e preserve rollback.

O melhor primeiro passo pode ser uma avaliação técnica curta com inventário de runtime, dependências, fluxos críticos, dados e opções de sequência. Essa avaliação deve terminar com decisões e evidências — não com uma recomendação automática de reescrita.