Werk je nog op .NET 5? Omdat deze versie sinds mei 2022 end-of-support is, loop je onnodige risico’s op het gebied van security, compliance en stabiliteit. In dit artikel ontdek je waarom upgraden naar .NET 8 (LTS) of .NET 9 (STS) loont en hoe je met slimme stappen en tools zoals de .NET Upgrade Assistant snel profiteert van meer performance, lagere kosten en moderne tooling-met minimale downtime.
Wat is .net 5 nu
.NET 5 was in 2020 de start van het “nieuwe” .NET: één uniform, cross-platform platform dat de lijn van .NET Framework en .NET Core samenbracht, met één SDK, runtime en set libraries voor web, cloud, desktop, mobiele en microservice-scenario’s. Nu, anno vandaag, is .NET 5 vooral relevant als tussenstation in die overgang, maar niet meer als keuze voor nieuwe projecten. De ondersteuning stopte in mei 2022, wat betekent dat je geen beveiligingsupdates of bugfixes meer krijgt en daardoor onnodige risico’s loopt, zeker als je aan compliance-eisen moet voldoen. Apps op .NET 5 blijven natuurlijk draaien, maar je zit vast aan verouderde dependencies, minder goede package-beschikbaarheid en beperkingen in tooling en hosting.
Functioneel bracht .NET 5 destijds mooie stappen zoals hogere performance, single-file publish, trimming en C# 9, maar alles wat .NET 5 introduceerde is inmiddels ruimer, sneller en stabieler beschikbaar in recente versies. In de huidige praktijk gebruik je .NET 5 dus alleen nog als je een bestaande app onderhoudt die nog niet is gemigreerd. Voor nieuwe of doorontwikkelde projecten kies je beter een LTS-versie (Long-Term Support) zoals .NET 8 voor stabiliteit, of een STS-release (Short-Term Support) zoals .NET 9 als je de nieuwste features wilt en sneller kunt upgraden. Kort gezegd: .NET 5 markeerde de start van het verenigde .NET, maar is nu end-of-life en vraagt om een upgradepad.
Plaats in het .net-ecosysteem
.NET 5 markeerde de stap naar één verenigd platform: je werkte voortaan met één SDK, runtime en set libraries voor web, cloud, desktop en containers, op Windows, Linux en macOS. Het introduceerde de target framework moniker net5.0, die de oude scheidslijn tussen .NET Framework en .NET Core in de praktijk verving en multi-targeting eenvoudiger maakte. In het ecosysteem fungeert .NET 5 nu vooral als brugversie: de fundamenten die je toen gebruikte (ASP.
NET Core, EF Core, gRPC, single-file publish, trimming, C# 9) lopen door in moderne releases. Omdat ondersteuning is gestopt, kies je vandaag een actuele lijn (.NET 8 LTS of .NET 9 STS), maar vrijwel alle API’s, NuGet-pakketten en deployment-patronen die je kent uit .NET 5 blijven werken en zijn beter, sneller en breder ondersteund.
Einde van ondersteuning: gevolgen voor je apps
Wanneer een versie end-of-support is, zoals .NET 5 sinds mei 2022, krijg je geen beveiligingsupdates, bugfixes of officiële support meer. Je apps draaien nog wel, maar je neemt onnodig risico op kwetsbaarheden en storingen die je niet snel kunt patchen. In audits en compliance-checks (denk aan ISO/SOC2 of NIS2) is dit lastig te verantwoorden. Je merkt het ook praktisch: container base-images en build agents worden niet langer geüpdatet, CI/CD-omgevingen verwijderen oude SDK’s, en steeds meer NuGet-pakketten en tools laten net5.
0 vallen waardoor builds breken of features verdwijnen. Cloudplatforms bieden beperkt of geen ondersteuning, en vulnerability-scanners blijven waarschuwingen geven. Het gevolg: hogere onderhoudskosten, meer incidenten en minder bewegingsruimte voor nieuwe ontwikkelingen. De enige duurzame oplossing is een gepland upgradepad naar een actuele LTS-release.
[TIP] Tip: Migreer van .NET 5 naar .NET 8 LTS voor support.
Moet je .net 5 nog gebruiken
Kort antwoord: liever niet. .NET 5 is sinds mei 2022 end-of-support, dus je krijgt geen beveiligingsupdates, bugfixes of officiële hulp meer. Dat levert risico’s op voor security en compliance, en je merkt steeds vaker dat packages, build-agents en cloudomgevingen net5.0 laten vallen. Ook performance en tooling lopen achter bij moderne releases; wat .NET 5 destijds bracht, is in .NET 6, 7, 8 en 9 sneller, stabieler en breder beschikbaar. De verstandige keuze voor productie is .NET 8 (LTS) als baseline; kies .NET 9 (STS) alleen als je snel kunt upgraden naar de volgende release.
Wanneer zou je .NET 5 toch nog kort gebruiken? Alleen als er een harde migratieblokkade is, een app op korte termijn wordt uitgefaseerd of je in een gecontroleerde freeze zit. Zet er dan meteen een einddatum op, beperk het internetoppervlak, en plan de upgrade. Containerization helpt bij isolatie, maar vervangt geen ontbrekende runtime-patches. Conclusie: .NET 5 is technisch een tussenstation geweest; maak er geen eindbestemming van en plan je overstap nu.
Risico’s voor security, compliance en performance
Omdat .NET 5 end-of-support is, krijg je geen securitypatches meer en blijf je zitten met bekende kwetsbaarheden in runtime en libraries. Je ziet dat terug in vulnerability-scans, verhoogde risico’s op exploits en strengere eisen van klanten. Voor compliance is dat lastig: auditors vragen om ondersteunde platforms en je kunt bevindingen onder ISO, SOC2 of NIS2 moeilijk wegpoetsen. Ook je keten veroudert: container base-images, build agents en NuGet-pakketten laten net5.
0 vallen, waardoor je minder snel kunt patchen of buildbreaks krijgt. Performance lijdt mee, omdat je verbeteringen uit nieuwere .NET-versies mist, zoals snellere JIT en GC, efficiëntere JSON/HTTP-stacks en PGO-optimalisaties. Dat kost je onnodig CPU en geheugen, verhoogt latency en drukt direct op kosten en gebruikerservaring.
Wanneer tijdelijk aanhouden nog verdedigbaar is
Tijdelijk doorgaan met .NET 5 kan nog te verantwoorden als je een kort, strak afgebakend venster nodig hebt om te migreren, bijvoorbeeld door een release-freeze, een piekseizoen of een kritieke third-party dependency die nog geen support voor .NET 8/9 heeft. Het moet dan gaan om weken tot hooguit enkele maanden, met een harde einddatum en een helder upgradeplan. Beperk risico’s actief: minimaliseer internetblootstelling, zet een reverse proxy of WAF ervoor, draai in containers met least-privilege, pin dependencies, voer extra security-scans uit en monitor kwetsbaarheden continu.
Bevries features zodat je alleen fixes uitvoert, documenteer een expliciete risicoacceptatie en test de migratie alvast in een parallelle omgeving. Is de app binnen korte tijd end-of-life, dan volstaat een gecontroleerde, afgeschermde doordraai tot uitfasering.
[TIP] Tip: Gebruik .NET 8 LTS; stop nieuwe .NET 5 deployments, plan migratie nu.
Beste keuze vandaag: LTS of STS
De keuze tussen LTS (Long-Term Support) en STS (Short-Term Support) draait om ritme en risico. LTS-releases krijgen ongeveer drie jaar support en zijn ideaal als je stabiliteit, voorspelbare updates en makkelijke compliance zoekt. STS-releases krijgen circa 18 maanden support, leveren de nieuwste features en performance, maar vragen om discipline: je moet vaker upgraden om binnen support te blijven. Praktisch gezien kies je vandaag .NET 8 (LTS) als veilige basis voor productie, zeker als je afhankelijk bent van audits, vendor-certificeringen en een brede set third-party libraries.
Ga voor .NET 9 (STS) als je de nieuwste optimalisaties nodig hebt en je team gewend is aan een doorlopende upgradecyclus met geautomatiseerde tests en CI/CD. Check altijd of je cloudplatform, container-images, build agents en NuGet-pakketten de gekozen lijn volledig ondersteunen. Kom je van .NET 5, dan is migreren naar .NET 8 meestal het kortste en stevigste pad; kies alleen voor .NET 9 als je specifieke features nodig hebt en je al een gepland upgradepad naar de volgende release klaar hebt liggen.
LTS VS STS: verschillen en wanneer je welke kiest
Onderstaande tabel zet .NET Long-Term Support (LTS) en Standard Term Support (STS) naast elkaar, zodat je snel ziet wat vandaag de beste keuze is-zeker als je nu nog op .NET 5 zit.
| Aspect | LTS | STS | Uitleg / wanneer kiezen |
|---|---|---|---|
| Ondersteuningsduur | 3 jaar ondersteuning (security & servicing) | 18 maanden ondersteuning (security & servicing) | Kies LTS voor stabiliteit en minder upgrade-druk; kies STS als je binnen 18 maanden weer kunt upgraden. |
| Release-ritme & stabiliteit | Verschijnt elke 2 jaar (even versies: .NET 6, 8); doorontwikkelde features | Jaarlijks (oneven versies: .NET 5, 7, 9); snelste innovaties | STS als je vroeg nieuwe taal/runtime/ASP.NET Core-features nodig hebt en de volgende upgrade al in je roadmap staat. |
| Risico & compliance | Lager risico; vaak vereist in gereguleerde sectoren en door vendors | Hoger veranderingsritme; vraagt strakke release governance | LTS voor bedrijfskritisch/regulated; STS voor productteams met volwassen CI/CD en snelle iteraties. |
| .NET 5 nu (context) | Niet van toepassing; aanbevolen doel: .NET 8 (LTS) | .NET 5 was een kortetermijnrelease (EOL mei 2022) | Zit je op .NET 5? Migreer nu: LTS voor rust; STS alleen als je frequente upgrades kunt borgen. |
Kern: LTS is de veilige default met 3 jaar support; STS is zinvol als je snel wilt innoveren en tijdig kunt doorupgraden. Vanaf .NET 5 is migreren naar een actuele LTS (zoals .NET 8) doorgaans de beste stap.
LTS (Long-Term Support) geeft je ongeveer drie jaar beveiligingsupdates en stabiliteit met minder upgrade-momenten, ideaal voor productie, SLA’s en compliance. STS (Short-Term Support) heeft circa 18 maanden support en levert sneller nieuwe features en performance, maar vraagt om discipline: je plant upgrades als routine in je releasecadans. Kies LTS als je voorspelbaarheid, brede vendor-ondersteuning en weinig risico wilt; .
NET 8 is dan je veilige basis. Ga voor STS, zoals .NET 9, als je team sterke CI/CD en geautomatiseerde tests heeft en je voordeel haalt uit de allernieuwste runtime- en taalverbeteringen. Check altijd of je cloud, container-images en NuGet-pakketten je keuze dekken. Kom je van .NET 5, dan is .NET 8 LTS meestal de snelste, stevigste stap; kies STS alleen met een duidelijk upgradepad.
Aanbeveling: .net 8 (LTS) nu, en de rol van .net 9 (STS)
Kies .NET 8 (LTS) als je nieuwe basis: je krijgt drie jaar support, brede ondersteuning in clouds, container-images en tooling, plus stevige performance- en stabiliteitswinst met o.a. PGO, Native AOT, snellere HTTP/JSON-stacks en verbeteringen in ASP.NET Core en EF Core. Voor de meeste teams is dit de veiligste stap, zeker als je uit .NET 5 komt en snel naar een ondersteunde, voorspelbare lijn wilt.
.NET 9 (STS) pak je wanneer je voordeel haalt uit de allernieuwste runtime- en taalfeatures en je gewend bent aan frequente upgrades. Zie .NET 9 als sprintrelease: perfect om innovaties vroeg te benutten, mits je een strak upgradepad aanhoudt naar de volgende release binnen het STS-venster. Zo combineer je snelheid met beheersbaar risico.
Snelle beslisregel per type project
Twijfel je tussen .NET 8 (LTS) en .NET 9 (STS)? Gebruik deze snelle beslisregels per projecttype.
- Productiesystemen, klantsoftware en bibliotheken met SLA’s/compliance of lage veranderdruk: kies .NET 8 (LTS) voor voorspelbare patches, brede vendor-support en rust in je releasecadans; eventueel multi-targeten naar STS voor early adopters.
- Nieuwe producten of teams die snel willen innoveren en profiteren van de nieuwste runtime- en taalfeatures: kies .NET 9 (STS) als je gewend bent elke 12-18 maanden te upgraden, met volwassen CI/CD en goede testdekking.
- Interne tools of kortlopende experimenten: STS is prima. Migreer je vanaf .NET 5, ga direct naar .NET 8; kies alleen STS als een specifieke feature doorslaggevend is en je upgradepad naar de volgende release al vastligt.
Hanteer je risicoprofiel, veranderdruk en lifecycle als laatste check. In twijfelgevallen is .NET 8 (LTS) de veilige default.
[TIP] Tip: Kies LTS; .NET 5 wordt niet meer ondersteund, upgrade direct naar 8.
Migreren van .net 5 naar een moderne .net-versie
Begin met een inventarisatie: welke projecten, NuGet-pakketten, hostingomgevingen en CI/CD-stappen zijn betrokken, en welke target frameworks gebruik je nu. Richt je vervolgens op .NET 8 (LTS) als standaarddoel; kies .NET 9 (STS) alleen als je team een strak upgrade-ritme heeft. Werk je TFM’s bij naar net8.0 of net9.0, update SDK’s in je build-agents en vervang container base-images door de 8.0/9.0 varianten. Gebruik de .NET Upgrade Assistant en laat je solution eerst compileren, update daarna pakketten (bijv. ASP.NET Core, EF Core, Serilog, Swashbuckle) en los breaking changes op met de ingebouwde analyzers en obsolete-warnings. Check configuratieverschillen in Program.
cs/Hosting, cookie- en CORS-defaults, en pas EF-migrations aan met scripts of zero-downtime patronen. Voeg parallelle testbranches toe voor rook- en belastingstests, monitor met health checks en OpenTelemetry, en rol uit via blue/green of canary zodat je snel kunt terugdraaien. Profiteer van performancefeatures zoals PGO, verbeterde GC en snellere JSON/HTTP-stacks; overweeg Native AOT voor tools of services met strakke cold-start-eisen. Als je dit aanpakkt als een kort, gefaseerd traject, krijg je sneller builds, lagere kosten en vooral weer een ondersteunde, veilige basis waarop je zonder frictie kunt doorontwikkelen.
Voorbereiden: inventarisatie en compatibiliteit
Begin met een heldere inventarisatie van je solution: welke projecten, target frameworks, NuGet-pakketten en SDK-versies gebruik je, op welke omgevingen draait alles (Windows/Linux, x64/ARM), en welke container base-images of build agents hangen eraan. Breng afhankelijkheden met dotnet list package –outdated in kaart en check of kritieke libraries compatibel zijn met net8.0 of net9.0. Zet de .NET Upgrade Assistant en de API-analyzers aan om obsolete-meldingen en breaking changes vroeg te vangen, vooral in ASP.
NET Core-hosting, authentication/cookies, EF Core-providers en JSON-serialisatie. Controleer ook integraties met cloud-services, native bindings en OS-capabilities. Leg per app vast wat het doel-TFM wordt, welke blockers er zijn en welke work-arounds of upgrades nodig zijn, zodat je migratieplan realistisch en risicogestuurd is.
Upgraden: stappen en tooling
Zo pak je de upgrade van .NET 5 naar .NET 8/9 gestructureerd aan. Deze stappen en tooling brengen je snel en veilig van code naar productie.
- Zet een upgrade-branch op, update je SDK via global.json en build-agents, wijzig het Target Framework naar net8.0 (of net9.0), draai de .NET Upgrade Assistant en gebruik analyzers om obsolete API’s en breaking changes te vinden (met extra aandacht voor Program.cs/hosting, authenticatie en EF Core).
- Werk NuGet-pakketten bij naar versies die je doel-TFM ondersteunen, los compileerfouten en analyzer-warnings op, zet waar mogelijk warnings as errors, en pas project- en csproj-instellingen aan het moderne hosting- en config-model aan.
- Update Dockerfiles naar .NET 8/9 base-images, review publish-opties (ReadyToRun, eventueel AOT), vernieuw je CI-pipeline (dotnet restore/build/test/publish), voer unit- en integratietests en een rooktest uit, en plan een gecontroleerde uitrol met rollback.
Documenteer je keuzes en herhaal de aanpak per service of project. Zo minimaliseer je risico’s en profiteer je direct van de performance- en security-verbeteringen.
Testen, uitrollen en nazorg
Begin met een volledige regressieset: unit-, integratie- en contracttests zodat je API’s en events nog exact leveren wat consumenten verwachten. Leg een performance-baseline vast op .NET 5 en vergelijk die met de nieuwe build, inclusief geheugen, GC-pauzes en latency, zodat je regressies snel ziet. Rol gecontroleerd uit via canary of blue/green met feature flags en backward-compatibele database-migraties, en gebruik readiness/liveness-probes om verkeer pas toe te laten bij gezonde instances.
Monitor direct na livegang met logs, metrics en traces (bijv. OpenTelemetry) en let op errorrates, timeouts en CPU/geheugen. Houd een rollback-pad paraat, plan snelle hotfixes en draai extra security-scans op images en dependencies. Werk documentatie en runbooks bij, tune eventuele nieuwe defaults (Kestrel, HTTP/2/3, TLS), en plan het opruimen van tijdelijke compat-shims zodra alles stabiel draait.
Veelgestelde vragen over net 5 nu
Wat is het belangrijkste om te weten over net 5 nu?
.NET 5 was de eerste ‘unified’ release na .NET Core, maar is een Short-Term Support-versie zonder ondersteuning sinds mei 2022. Dat betekent geen security-fixes, verhoogde compliance-risico’s en aanbevolen migratie naar een huidige LTS-versie.
Hoe begin je het beste met net 5 nu?
Start met inventariseren: frameworks, packages en OS-support. Kies op basis van cadans: productie -> LTS (.NET 8), innovatie -> STS (.NET 9). Gebruik Upgrade Assistant, target net8.0, los breaking changes op, automatiseer tests, gefaseerde uitrol.
Wat zijn veelgemaakte fouten bij net 5 nu?
Doorontwikkelen op .NET 5 zonder support, vergeten container-base images en runtimes te upgraden, afhankelijkheden niet bijwerken, LTS/STS-ritme negeren, onvoldoende compatibiliteitstesten, geen rollback-strategie, en performance-regressies overslaan door ontbrekende profiling, benchmarks en realistische loadtests zonder compensating controls.