.NET-moderniseringElke stack op deze lijst, in productie opgeleverd
Legacy .NET is niet één probleem. Een WebForms-app, een WCF-servicelaag en een WinForms-client lopen elk om totaal verschillende redenen vast, en een schatting is maar zo goed als degene die echt in die stack heeft gewerkt. We hebben in al die stacks productiecode geschreven — ook de VB.NET-projecten die niemand wil openen — dus de analyse is een kwestie van ervaring, niet van een onderzoeksfase waarvoor jij betaalt.
2002 – 2012ASP.NET WebForms↳ASP.NET Core met Razor Pages of Blazor
De page lifecycle, ViewState en server controls hebben geen equivalent, dus de markup wordt echt herschreven. De businesslogica eronder meestal niet — en die twee uit elkaar halen is het grootste deel van het werk.
2003 – 2010ASMX- en WCF-services↳ASP.NET Core-API’s, gRPC of CoreWCF
Bindings, behaviours en SOAP-contracten laten zich niet overzetten. Waar de aanroepers derden zijn die je niet kunt veranderen, houdt CoreWCF het contract in leven terwijl alles erachter verhuist.
2007 – 2015Silverlight en browserplugin-clients↳Een web-frontend of een mobiele app
Er is niets om naartoe te migreren — de runtime is uit elke browser verdwenen. Deze trajecten beginnen met een gesprek over wat de applicatie eigenlijk moest doen.
2008 – 2019DataSets, EF6 en zelfgeschreven ADO.NET↳EF Core, of Dapper waar het de moeite loont
De datalaag is waar een eenvoudige migratie duur wordt. Queryvertaling, transacties en lazy loading gedragen zich allemaal anders, en dat merk je in productie in plaats van tijdens het compileren.
2009 – 2016ASP.NET MVC 5 en Web API 2↳ASP.NET Core MVC
Het dichtst bij een mechanische migratie op deze lijst. Het echte werk zit in hosting, configuratie, dependency injection en de middleware-pipeline — niet in je controllers.
2002 – vandaagWinForms en WPF↳Actuele .NET-desktop, of MAUI als het op een telefoon thuishoort
Beide draaien nog op modern .NET, dus dit is zelden een herschrijving. Wat het blokkeert, zijn verlaten controlsuites van derden en COM-interop, en dat is het eerste waar we naar zoeken.
Elke versie.NET Framework-class libraries↳Actueel .NET, multi-targeted tijdens de overstap
Gedeelde libraries zijn wat het oude en nieuwe systeem naast elkaar laat draaien. Die eerst multi-targeted krijgen, is meestal de sleutel tot al de rest op deze lijst.
Doorlopendpackages.config, legacy csproj, IIS op Windows Server↳SDK-style projecten, containers, CI die vanzelf draait
Weinig glamoureus, en het is wat de rest herhaalbaar maakt. Het betaalt zich ook terug lang voordat de migratie klaar is, en daarom is het vaak het juiste om als eerste te doen.
Geen big-bang rewrites
Niets op deze lijst wordt in één keer vervangen. De aanpak die werkt, is een strangler: zet de nieuwe stack naast de oude op, verplaats stukje per stukje achter dezelfde URL’s en laat beide draaien tot er aan de oude kant niets meer overblijft. Op papier lijkt het trager, en het is de enige versie hiervan die we ooit hebben zien afronden.