Hoe moderniseer je een oude .NET applicatie?
Draait uw bedrijfskritische applicatie nog op .NET Framework 4? Dan is de vraag niet of u moet moderniseren, maar wanneer en hoe. In dit artikel laten we zien hoe wij dat onlangs aanpakten bij een bekende eCommerce-organisatie, zodat u kunt beoordelen waar uw eigen applicatie staat.
Een kijkje in de keuken
Ik mocht kort geleden meekijken bij een bekende eCommerce-organisatie. De webshops en interne applicaties draaiden nog volledig op .NET Framework 4.x. Veel organisaties bevinden zich in dezelfde situatie. Niet omdat de software slecht is, maar omdat bedrijfskritische systemen vaak jarenlang worden uitgebreid zonder dat er ruimte ontstaat voor een grotere moderniseringsslag.
Op een gegeven moment begint dat tegen te werken:
- Het verschil tussen de gebruikte versie en de actuele .NET-versies wordt steeds groter. Daardoor neemt de complexiteit van een migratie toe.
- Teams die jarenlang op dezelfde versie blijven werken, ontwikkelen minder ervaring met moderne technieken en architecturen. Nieuwe projecten vallen daardoor vaak terug op bekende patronen uit het verleden.
- Oplossingen die met moderne .NET-technologie relatief eenvoudig gerealiseerd kunnen worden, vragen binnen een verouderd platform vaak om creatieve omwegen en extra maatwerk.
Het gevolg is dat de technische schuld langzaam groeit. Niet omdat de applicatie vandaag niet meer werkt, maar omdat veranderingen steeds meer tijd, risico en ontwikkelbudget vragen.
Herkent u dit?
De oorzaken waren herkenbaar:
- Het team had geen moderne .NET-kennis.
- Alle aandacht ging naar nieuwe features.
- Management geeft geen prioriteit aan het moderniseren van de applicatie.
Als manager zou ik hier nerveus van worden. Niet omdat de sites morgen stoppen met werken, maar omdat het betekent dat er jarenlang niet structureel in de techniek is geïnvesteerd. En dat schuift de rekening door: hoe langer u wacht, hoe duurder en riskanter de modernisering wordt.
Wat gebeurt er als u niets doet
- Het wordt lastiger om nieuwe ontwikkelaars te vinden die graag in WebForms en .NET Framework werken.
- Verouderde componenten ontvangen geen beveiligingsupdates meer.
- Integreren met moderne systemen kost steeds meer tijd en maatwerk.
- De migratie wordt elk jaar groter en duurder.
- De continuïteit van het systeem wordt afhankelijk van een klein aantal specialisten.
Waarom moderniseren niet zomaar kan
Bijwerken naar modern .NET is meer dan een nieuwe versie kiezen. In dit geval moest:
- de authenticatie worden herschreven;
- de middleware opnieuw worden opgezet;
- elk gebruikt NuGet-package worden bijgewerkt, voor zover dat nog mogelijk is;
- elke gekoppelde library in kaart worden gebracht en naar een nieuwe versie gaan;
- elke ASHX-handler worden onderzocht en omgezet naar een (minimal) API;
- elke achtergrondtaak verhuizen naar een eigen Windows Service.
Het oude project bestond uit een groot monolithisch ASP.NET WebForms-project. De WebForms-schermen moesten worden omgezet naar Razor Pages of Blazor-componenten binnen een moderne ASP.NET Core-architectuur. Dat is al een flink project, maar nog niet de grootste uitdaging.
De grootste uitdaging: de code zelf
Alle WebForms-pagina’s moeten ook gemigreerd worden. De vraag is dan hoe de code is georganiseerd:
- Is de code verdeeld over projecten?
- Is er een klassieke three-tier-opzet (presentatie, businesslogica, data)?
- Of staat vrijwel alle logica in de WebForms zelf?
Hoe verder naar het laatste, hoe groter het werk. Bij deze organisatie stond de logica voornamelijk in de WebForms zelf, en nieuwe features zaten in losse libraries die rechtstreeks in de solution waren gelinkt. Dat maakte de uitdaging alleen maar groter. Het totale gebrek aan structuur in de code was de grootste valkuil van het project.
Onze aanpak in zes stappen
AI is hierbij een prima hulpmiddel, maar de volgorde en de keuzes blijven mensenwerk.
1. Een proof of concept in Clean Architecture
We startten met een klein project in Clean Architecture. Daarmee ziet iedereen in de praktijk hoe de nieuwe opzet eruitziet, en kun je de aanpak testen voordat je er veel in investeert.
2. Het bestaande gedrag in kaart brengen
- De functionaliteit in de WebForms hebben we (deels) beschreven in Gherkin, in
.feature-bestanden. Dat maakt het later eenvoudig om unit tests te schrijven, en het helpt ook AI-agents. - De oorspronkelijke authenticatie is onderzocht en vergeleken met ASP.NET Core Identity.
- De logica in de middleware is volledig geanalyseerd.
3. Alvast een deel overzetten
- Een deel van de oude ASHX-endpoints staat nu in een minimal API.
- Een deel van de achtergrondtaken draait in een Windows Service.
- Een aantal pagina’s is overgezet naar het proof-of-concept-project.
4. Demo met bewijs
In een demo hebben we laten zien:
- Performance: Tijdens de proof of concept zagen we direct de voordelen van modern .NET op het gebied van performance.
- Data access: best practices met Entity Framework.
- Clean Architecture: hoe het werkt en waarom.
- Hoe de oude logica past: de code die nu kriskras door het project staat, krijgt een plek in Clean Architecture met DDD in het achterhoofd.
5. Big bang of gefaseerd?
We onderzochten beide en kozen voor een gefaseerde aanpak, in deze volgorde:
- De achtergrondtaken.
- De ouderwetse ASHX-endpoints naar een minimal API.
- Daarna de gekoppelde functionaliteit stap voor stap, steeds de WebForms-formulieren die bij elkaar horen.
Zo wordt het werk in logische delen opgeknipt in plaats van alles in één keer over te zetten.
6. Overzicht van het werk
- Het werk is verdeeld in onderwerpen en geplaatst in een flink aantal epics.
- Per epic zijn alvast veel stories aangemaakt, met een onderwerp; de uitwerking volgt later.
- Epics en stories zijn met het team doorgenomen, en samen hebben we een indicatie van de doorlooptijd gemaakt.
Het resultaat
Na deze stappen was duidelijk:
- welke functionaliteit er bestaat;
- waar de grote valkuilen zitten;
- hoe lang het ongeveer duurt.
Kortom: na slechts één week onderzoek lag er een uitgewerkt plan:
- een werkende proof of concept;
- inzicht in de grootste technische risico’s;
- een eerste planning;
- een backlog met epics en stories;
- een concreet migratiepad Kortom een gefaseerde aanpak waarmee het team direct kan starten.
Wat betekent dit voor uw applicatie?
Een oude .NET-applicatie hoeft geen blok aan uw been te zijn. Met een goed proof of concept, een duidelijke volgorde en een eerlijke inschatting wordt het een beheersbaar project. Zeker als u merkt dat:
- nieuwe features steeds langer duren;
- niemand in het team zich meer thuis voelt in de code;
- packages niet meer te updaten zijn;
- u niet weet wat modernisering gaat kosten.
Draait uw applicatie nog op .NET Framework of WebForms? Dan helpt een korte scan vaak al om inzicht te krijgen in:
- technische risico’s;
- migratiecomplexiteit;
- verwachte doorlooptijd;
- mogelijke aanpak.
Wij denken graag vrijblijvend mee.
