Modernização .NETCada stack desta lista, entregue em produção
O .NET legado não é um problema só. Um app WebForms, uma camada de serviços WCF e um cliente WinForms travam por motivos completamente diferentes, e uma estimativa só é tão boa quanto a experiência de quem realmente viveu naquela stack. Já escrevemos código de produção em todas elas — inclusive nas de VB.NET que ninguém quer abrir — então a avaliação é memória, não uma fase de pesquisa paga por você.
2002 – 2012ASP.NET WebForms↳ASP.NET Core com Razor Pages ou Blazor
O ciclo de vida da página, o ViewState e os server controls não têm equivalente, então a marcação precisa mesmo ser reescrita. A lógica de negócio por baixo geralmente não — e separar as duas coisas é a maior parte do trabalho.
2003 – 2010Serviços ASMX e WCF↳APIs em ASP.NET Core, gRPC ou CoreWCF
Bindings, behaviors e contratos SOAP não migram. Quando quem chama os serviços são terceiros que você não pode mudar, o CoreWCF mantém o contrato vivo enquanto tudo por trás dele muda.
2007 – 2015Silverlight e clientes baseados em plugins de navegador↳Um front-end web ou um app mobile
Não há para onde migrar — o runtime sumiu de todos os navegadores. Esses projetos começam com uma conversa de escopo sobre o que a aplicação realmente precisava fazer.
2008 – 2019DataSets, EF6 e ADO.NET feito à mão↳EF Core, ou Dapper onde ele se justifica
A camada de dados é onde uma migração simples fica cara. Tradução de consultas, transações e lazy loading se comportam de outra forma, e isso aparece em produção, não na compilação.
2009 – 2016ASP.NET MVC 5 e Web API 2↳ASP.NET Core MVC
O mais próximo de uma migração mecânica nesta lista. O trabalho de verdade está em hosting, configuração, injeção de dependência e no pipeline de middleware — não nos seus controllers.
2002 – hojeWinForms e WPF↳.NET desktop atual, ou MAUI se o lugar dele for no celular
Os dois ainda rodam no .NET moderno, então raramente é uma reescrita. O que trava são suítes de controles de terceiros abandonadas e interop com COM — a primeira coisa que vamos procurar.
Qualquer versãoBibliotecas de classes do .NET Framework↳.NET atual, com multi-targeting durante a mudança
Bibliotecas compartilhadas são o que permite que o sistema antigo e o novo rodem lado a lado. Colocá-las em multi-targeting primeiro costuma ser o que destrava todo o resto desta lista.
Contínuopackages.config, csproj legado, IIS no Windows Server↳Projetos no estilo SDK, contêineres, CI que roda sozinho
Nada glamoroso, e é o que torna o resto repetível. Também se paga muito antes de a migração terminar, e por isso muitas vezes é a coisa certa a fazer primeiro.
Nada de reescrever tudo de uma vez
Nada nesta lista é substituído em uma única entrega. O formato que funciona é o strangler: levantar a nova stack ao lado da antiga, mover uma fatia de cada vez por trás das mesmas URLs e manter as duas rodando até não sobrar nada do lado antigo. No papel parece mais lento, e é a única versão disso que já vimos chegar ao fim.
