Existe uma conversa que acontece em muitas empresas mais ou menos uma vez por ano. Alguém aponta que a aplicação interna da qual todo mundo depende foi escrita há muito tempo, sobre um framework do qual ninguém mais fala, por pessoas que em sua maioria não trabalham mais aqui. Outra pessoa pergunta quanto custaria substituí-la. O número que volta é grande. Todos concordam que é importante. Nada acontece. Doze meses depois a mesma conversa recomeça, do zero.
Ela trava porque a pergunta está errada. “Quanto custaria substituir isso?” não tem resposta útil, porque a maioria dessas aplicações não deve ser substituída. Elas devem ser movidas, em partes, numa ordem, deixando algumas partes exatamente onde estão.
“É velho” não é um motivo
Idade não é defeito. Uma aplicação que roda corretamente há doze anos provou algo que uma nova não provou. Se ela dá dinheiro, quem a usa é fluente nela e nada nela está pegando fogo, então a versão do framework é um fato, não um problema.
O que de fato força uma decisão é mais estreito, e vale dizer com franqueza, porque se nada disso for verdade você talvez esteja prestes a gastar sem retorno:
- Você não consegue contratar para aquilo. É o gatilho real mais comum e o menos discutido. Quando o grupo de pessoas dispostas a mexer num código fica pequeno demais, o risco deixa de ser técnico.
- Algo do qual ela depende perdeu suporte. Não a aplicação. Algo embaixo dela: o sistema operacional, o framework, a versão do banco, uma integração de pagamento, uma biblioteca com vulnerabilidade conhecida e sem versão corrigida.
- O negócio precisa de algo que a arquitetura não entrega. Acesso mobile, uma API para um parceiro, login único, uma integração que pressupõe um fluxo de autenticação moderno.
- Ela está bloqueando outra coisa. Saída de um data center, uma exigência de compliance, uma aquisição, uma atualização de ERP que muda o contrato por baixo.
- O custo de uma mudança pequena virou absurdo. Quando uma alteração de duas linhas leva três semanas porque ninguém consegue testar com segurança, isso é um imposto real e mensurável, e ele acumula.
Se um desses for verdade, o projeto tem caso de negócio. Se nenhum for, a recomendação honesta é fazer o trabalho de segurança e dependências, deixar registrado como a coisa se comporta, e rever daqui a um ano. Preferimos dizer isso a vender uma reescrita que ninguém precisava.
Os caminhos, e quanto cada um custa de fato
Web Forms
Esse é o duro. O ASP.NET Web Forms só roda em .NET Framework. Nunca foi trazido adiante e nunca será. Não existe camada de compatibilidade nem conversão automática que produza uma aplicação moderna funcionando, porque o modelo inteiro, com seu ciclo de vida de página, view state e controles de servidor, não tem equivalente do outro lado.
Então a camada de interface é uma reescrita. O que não é são todas as camadas atrás dela. Na maioria das aplicações Web Forms que analisamos, boa parte do valor real está em classes de regra de negócio e acesso a dados que são C# comum e migram para o .NET atual com muito menos atrito do que se imagina. O formato realista é: manter a lógica, portá-la, e reconstruir as telas em Razor Pages, MVC ou Blazor conforme o quanto precisam ser interativas.
A armadilha é dimensionar a aplicação inteira como reescrita porque o front-end é. É assim que um projeto de nove meses acaba orçado como algo perto de três.
Serviços ASMX e WCF
O ASMX está na mesma posição do Web Forms: só .NET Framework, sem caminho adiante. O WCF é mais matizado, porque existe o CoreWCF e ele consegue levar um serviço adiante praticamente intacto se você realmente precisa da pilha WS-*, dos contratos SOAP ou dos transportes.
Normalmente você não precisa. A maioria dos endpoints ASMX e WCF internos faz algo que uma API JSON simples sobre HTTP faz de forma mais direta, e quem consome é seu e você pode atualizar. O destino costuma ser minimal APIs ou controllers do ASP.NET Core, com o contrato limpo no caminho em vez de reproduzido fielmente. Manter um envelope SOAP vivo só porque ele estava lá em 2011 é uma decisão que vale tomar de propósito, e não por inércia.
Onde você não puder mudar quem consome, porque do outro lado há um parceiro ou um dispositivo, rode a API nova em paralelo e mantenha um endpoint fino de compatibilidade. Sai bem mais barato do que parece e desacopla o seu cronograma do deles.
WinForms, e a migração que as pessoas erram
WinForms não está morto, e essa é a correção que mais economiza dinheiro. WinForms e WPF rodam no .NET atual, no Windows. Uma aplicação WinForms de linha de negócio pode sair do .NET Framework para o .NET 10 e continuar sendo WinForms. Você ganha o runtime moderno, dependências atuais, mais performance e uma plataforma com suporte, sem reescrever uma única tela.
Isso importa porque a resposta reflexa a “temos uma app antiga em WinForms” é cada vez mais “reescreve em MAUI”, e para muitas aplicações essa é simplesmente a ferramenta errada. MAUI é para multiplataforma: iOS, Android, Windows e macOS a partir de uma base de código. Se sua aplicação roda em desktops Windows dentro do seu próprio prédio e sempre vai rodar, o MAUI não te compra nada e te custa uma reescrita completa de interface.
O MAUI é a resposta certa quando o requisito realmente mudou de formato. Seus técnicos de campo precisam dela no celular. Seu time de vendas precisa dela num iPad. Você quer uma base de código para desktop e mobile em vez de dois times. Esses são motivos reais, e quando se aplicam vale fazer o trabalho direito. Escrevemos o detalhe desse caminho à parte no guia de migração de Xamarin para .NET MAUI, e boa parte vale igualmente vindo do WinForms.
A ordem que funciona: chegar primeiro ao .NET atual, ainda em WinForms, e tratar a ida para o MAUI como uma decisão separada, tomada depois, pelos próprios méritos. Fazer as duas ao mesmo tempo é como esses projetos acabam sem conseguir dizer o que quebrou.
A opção que ninguém orça
Deixe como está. Corrija a stack de baixo, resolva as dependências com vulnerabilidades conhecidas, escreva o que a aplicação faz e coloque-a sob um contrato de manutenção. Para uma aplicação que funciona e não está bloqueando nada, essa é frequentemente a opção de maior retorno disponível, e é a que você nunca vai ouvir de quem vende uma reconstrução.
Onde a IA acelera de verdade e onde não
Migrar é sobretudo um problema de tradução através de uma fronteira conhecida, e é exatamente nisso que as ferramentas de IA atuais são boas. Usadas com disciplina, mudam a economia de forma relevante. Usadas como varinha mágica, produzem código confiante, plausível e errado num ritmo que nenhum revisor humano acompanha.
Onde ajuda
- Ler o código e te dizer o que tem ali. Cada tela, cada procedure, cada ramo de regra de negócio, transformados num registro estruturado do que a aplicação faz e por quê. Num código que ninguém entendeu por completo em uma década, essa é de longe a aplicação de maior valor, e é tediosa o bastante em velocidade humana para nunca ser feita.
- A tradução mecânica. Code-behind de Web Forms para um controller e um view model. Método ASMX para um endpoint de minimal API. Acesso a dados antigo para algo atual. São transformações consistentes e repetitivas, e consistência em volume é justamente o ponto forte.
- Gerar os testes que você nunca teve. A aplicação antiga é uma especificação viva do próprio comportamento até o momento em que você a desliga. Caracterizar esse comportamento como testes, enquanto ela ainda roda, dá contra o que conferir a nova. Essa única prática separa as migrações que dão certo das que dão errado, e quase ninguém fazia antes de ficar barato.
- Triagem de dependências e vulnerabilidades. Descobrir quais de quatrocentos pacotes importam de fato, o que quebra se você mexer neles e em que ordem.
Onde não ajuda
- Decidir o que manter. Parte do que sua aplicação faz é regra de negócio deliberada. Parte é contorno de uma limitação que não existe mais. Parte é bug ao qual todo mundo se adaptou em silêncio anos atrás. Distinguir exige conversar com quem usa. Nenhum modelo sabe qual é qual, e um “bug” reescrito com confiança que na verdade era uma regra é como se perde um mês.
- Arquitetura. Se isso deve ser um serviço ou quatro, se aquela fila é necessária, quais são os modos de falha quando uma dependência fica lenta. São julgamentos cujas consequências aparecem no ano três.
- Qualquer coisa que você não verificar. Código gerado que compila não é código gerado que está correto. A carga de revisão é real, não some, e um time que pula essa parte transforma uma migração numa queda.
O enquadramento honesto: a IA não elimina o projeto. Ela elimina quase toda a arqueologia, quase toda a tradução mecânica e a desculpa para não ter uma suíte de testes. Isso é uma fração grande do custo e a maior parte do risco, o que é uma afirmação bem diferente de “a IA reescreve sua app”.
Preparar para o futuro, ou seja, para a próxima migração
“Preparar para o futuro” normalmente não significa nada. Concretizado, significa uma coisa só: deixar a próxima dessas mais barata. Frameworks vão continuar mudando. A meta não é escolher uma stack que dure para sempre, porque nenhuma dura. A meta é ficar numa posição em que mudar de novo seja um projeto e não uma crise.
O que realmente entrega isso, em ordem aproximada de valor:
- Uma suíte de testes que descreva comportamento. O maior determinante de uma migração futura ser segura. Se você levar uma única coisa deste artigo, leve essa.
- Regra de negócio que não more na interface. A razão de as migrações de Web Forms doerem é que uma década de regras foi parar em arquivos de code-behind. Lógica que mora na própria camada migra para o que vier depois quase de graça.
- Requisitos escritos. Não documentação do código, que apodrece. Um registro das decisões e dos porquês, que não.
- Dependências entediantes e atuais. Menos bibliotecas, escolhidas por serem mantidas e não por serem espertas, atualizadas por rotina em vez de no desespero.
- Configuração e segredos fora da aplicação. Barato de fazer, e remove uma categoria inteira de dor na migração.
- Um deploy que você consegue rodar quando quiser. Se publicar é difícil, tudo depois de publicar também é.
O que uma stack envelhecida realmente expõe
Segurança em aplicações legadas é discutida no abstrato, o que a torna fácil de adiar. No concreto, nas aplicações que auditamos aparece sempre a mesma lista curta:
- Um framework ou runtime fora de suporte. O .NET Framework 4.6.x perdeu suporte em abril de 2022, e muita aplicação ainda está nele. Ir para 4.8 costuma ser simples e é uma melhoria real mesmo que você nunca saia do .NET Framework.
- Um sistema operacional fora de suporte. O Windows Server 2012 R2 saiu de suporte em outubro de 2023 e segue em produção em mais lugares do que se gostaria de admitir.
- Configuração de TLS e cifras herdada da instalação original. Versões antigas de protocolo ainda habilitadas, que reprovam em scans modernos e cada vez mais quebram integrações com provedores de pagamento e parceiros.
- Dependências com vulnerabilidades publicadas e correções disponíveis. A maioria pouco glamourosa dos achados reais. Nada exótico, apenas nunca feito.
- Autenticação anterior à prática atual. Controle de sessão caseiro, senhas com um algoritmo que estava bom em 2013, nenhum caminho para multifator.
- Segredos em arquivos de configuração. Parados no controle de versão, legíveis por todo mundo que algum dia clonou o repositório.
Quase nada disso exige a reescrita. Exige alguém olhar, e depois fazer o trabalho em ordem de prioridade. O que é o argumento da última seção.
Revisão, auditoria, e a versão desconfortável desta conversa
Às vezes o trabalho útil não é uma migração. É uma leitura externa do código e do time em volta dele, entregue a quem precisa decidir e vem recebendo respostas conflitantes.
O que isso produz:
- Um retrato do as-built. O que a aplicação realmente é, do que depende, onde o risco está concentrado, o que é código morto e o que só parece.
- Uma posição de segurança e dependências. Achados ordenados por serem de fato alcançáveis, não um despejo de scanner com quatrocentos críticos que ninguém vai ler.
- Um conjunto de opções orçadas. Ficar e manter, migrar em partes, reconstruir. Com números reais e o raciocínio à vista, incluindo o caso de fazer o mínimo.
- Uma leitura honesta da entrega. Se o time consegue executar o plano, o que falta, e se a restrição é de gente, de processo ou de ferramenta. Essa é a parte que clientes pedem em particular e muitas vezes é a pergunta de verdade.
Vamos dizer quando um time interno está indo bem e não precisa da gente, porque uma revisão que sempre conclui “contrate quem revisou” não vale nada para quem lê.
Uma sequência que funciona
- Capture o as-built primeiro, enquanto o sistema antigo ainda roda. Antes de qualquer trabalho na plataforma nova. A janela fecha quando ele apaga, e tudo depois fica mais barato se isso vier primeiro.
- Faça o trabalho de segurança e dependências imediatamente. É independente de qualquer outra decisão, é comparativamente barato, e é a parte com prazo definido por outra pessoa.
- Caracterize o comportamento como testes contra o sistema antigo, para que o novo tenha contra o que ser medido.
- Mova o runtime antes da arquitetura. Primeiro .NET atual, mesmo formato. WinForms continua WinForms. Depois você decide sobre a interface, à parte e pelos próprios méritos.
- Migre em fatias que consigam ir para produção. Um serviço, um grupo de telas, uma integração. O que não consegue subir em seis meses também não consegue ser corrigido em seis meses.
- Rode antigo e novo em paralelo até um corte real. Com usuários de verdade no caminho novo antes de desligar o antigo.
A conclusão
A maioria das aplicações .NET legadas está em situação melhor do que a conversa sobre elas sugere. O framework estar fora de moda não é um problema de negócio. Não conseguir contratar, não conseguir corrigir e não conseguir alterar com segurança são problemas de negócio, e têm soluções diferentes com preços diferentes.
Consiga primeiro o inventário honesto. Faça o trabalho de segurança de qualquer jeito. Mova o runtime antes da arquitetura. Use a IA para a arqueologia e a tradução, não para o julgamento. E desconfie de quem recomenda uma reescrita completa antes de ter lido seu código.
Tem uma dessas no seu mapa de riscos?
Construímos em .NET 10 e .NET MAUI, e passamos muito tempo dentro de aplicações que outras pessoas escreveram e que ninguém entendia por completo. Se você quer uma leitura direta do que suas opções custam de fato, seja uma migração, uma passada de segurança e dependências, ou uma revisão externa do código e do time, conte para nós o que você opera. Vamos dizer se a resposta for deixar como está, e isso é um resultado genuíno e não uma gentileza. Você também pode ver como abordamos software sob medida e mobile multiplataforma.