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.
  • Het management hield modernisering tegen.

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.

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 Asp.net monolithe webforms project. De Asp.net webforms dienden omgezet te worden naar de nieuwe Razor technology. 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: .NET Core presteert uitstekend.
  • 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:

  1. De achtergrondtaken.
  2. De ouderwetse ASHX-endpoints naar een minimal API.
  3. 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 een dikke week onderzoek lag er een uitgewerkt plan met een flink aantal epics en stories, een werkende proof of concept en een gefaseerde aanpak waarmee het team direct kan starten. Op deze manier kreeg de organisatie inzicht in de risico’s, afhankelijkheden en verwachte doorlooptijd van de migratie.

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.

Werkt uw applicatie nog op .NET Framework of WebForms? Vertel ons kort wat u heeft. We denken graag vrijblijvend met u mee en reageren binnen één werkdag.

Neem contact met ons op of laat uw nummer achter via bel me terug.