Modernización de .NETCada tecnología de esta lista, llevada a producción
El .NET heredado no es un único problema. Una app de WebForms, una capa de servicios WCF y un cliente WinForms se atascan por razones completamente distintas, y una estimación solo vale lo que valga la experiencia real de quien la hace con esa tecnología. Hemos escrito código de producción en todas ellas, incluidas las de VB.NET que nadie quiere abrir, así que la evaluación es memoria y no una fase de investigación que usted paga.
2002 – 2012ASP.NET WebForms↳ASP.NET Core con Razor Pages o Blazor
El ciclo de vida de la página, ViewState y los controles de servidor no tienen equivalente, así que el marcado realmente se reescribe. La lógica de negocio que hay debajo normalmente no, y separar ambas cosas es la mayor parte del trabajo.
2003 – 2010Servicios ASMX y WCF↳APIs de ASP.NET Core, gRPC o CoreWCF
Los bindings, los behaviors y los contratos SOAP no se trasladan. Cuando quienes llaman al servicio son terceros que usted no puede cambiar, CoreWCF mantiene vivo el contrato mientras todo lo que hay detrás se migra.
2007 – 2015Silverlight y clientes basados en plugins del navegador↳Un frontend web o una app móvil
No hay nada a lo que migrar: el runtime ha desaparecido de todos los navegadores. Estos proyectos empiezan con una conversación de alcance sobre lo que la aplicación realmente necesitaba hacer.
2008 – 2019DataSets, EF6 y ADO.NET hecho a mano↳EF Core, o Dapper donde se justifique
La capa de datos es donde una migración sencilla se encarece. La traducción de consultas, las transacciones y la carga diferida se comportan de forma distinta, y se nota en producción, no al compilar.
2009 – 2016ASP.NET MVC 5 y Web API 2↳ASP.NET Core MVC
Lo más parecido a una migración mecánica de esta lista. El trabajo real está en el hosting, la configuración, la inyección de dependencias y el pipeline de middleware, no en sus controladores.
2002 – hoyWinForms y WPF↳.NET actual para escritorio, o MAUI si tiene que estar en un teléfono
Ambos siguen funcionando en .NET moderno, así que rara vez es una reescritura. Lo que la bloquea son las suites de controles de terceros abandonadas y la interoperabilidad COM, que es lo primero que buscamos.
Cualquier versiónBibliotecas de clases de .NET Framework↳.NET actual, con multi-targeting durante la migración
Las bibliotecas compartidas son lo que permite que el sistema antiguo y el nuevo funcionen en paralelo. Conseguir primero que tengan multi-targeting suele ser lo que desbloquea todo lo demás de esta lista.
Continuopackages.config, csproj heredados, IIS en Windows Server↳Proyectos de estilo SDK, contenedores, CI que funciona sola
Poco vistoso, y es lo que hace repetible todo lo demás. Además da resultados mucho antes de que termine la migración, por eso a menudo es lo correcto para empezar.
Sin reescrituras de golpe
Nada de esta lista se reemplaza de una sola vez. El enfoque que funciona es el patrón strangler: levantar la nueva tecnología junto a la antigua, trasladar una parte cada vez detrás de las mismas URL y mantener ambas en marcha hasta que no quede nada en el lado antiguo. Sobre el papel parece más lento, y es la única versión de esto que hemos visto terminar.
