.NET Core vs .NET Framework in 2026: Wanneer migreren en wanneer blijven

Na meer dan 10 jaar op de Microsoft-stack heb ik aan beide kanten van dit spectrum gewerkt — greenfield .NET 8-services en legacy ASP.NET Web Forms-applicaties die nog steeds kritieke bedrijfsprocessen draaien. De vraag die ik van CTO’s en tech leads krijg is altijd dezelfde: moeten we migreren? Het eerlijke antwoord is: dat hangt ervan af, en migratie is niet altijd de juiste keuze.

Dit is wat ik heb geleerd door dit werk in de praktijk te doen.

Wat is het verschil tussen .NET Core en .NET Framework?

.NET Framework is de originele Windows-only runtime die met Windows werd meegeleverd en zijn laatste feature-release bereikte bij versie 4.8.1. .NET Core (tegenwoordig gewoon “.NET” vanaf versie 5) is de cross-platform, open-source opvolger die Microsoft actief doorontwikkelt — met .NET 9 als huidige nieuwste versie en .NET 10 later dit jaar.

Het belangrijkste verschil is niet alleen cross-platform ondersteuning. Het is het hele ontwikkelmodel. .NET Core bracht side-by-side versioning, een modulair NuGet-gebaseerd framework, container-native design en dramatisch betere prestaties. .NET Framework gaf je een enkele monolithische installatie gekoppeld aan je Windows-versie.

In de praktijk geldt: als je iets nieuws bouwt in 2026, gebruik je .NET 8 of .NET 9. De vraag wordt pas interessant als je bestaande .NET Framework-applicaties hebt en moet beslissen wat je ermee doet.

.NET Framework vs .NET 8/9: Een gedetailleerde vergelijking

Zo verhouden de twee stacks zich op de dimensies die er echt toe doen voor besluitvorming:

Dimensie	.NET Framework 4.8.x	.NET 8 / .NET 9
Ondersteuningsstatus	Ondersteund (wordt meegeleverd met Windows), geen nieuwe features	Actief doorontwikkeld, .NET 8 is LTS tot nov 2026
Platform	Alleen Windows	Windows, Linux, macOS, containers
Prestaties	Voldoende voor de meeste workloads	2-5x sneller bij webworkloads, aanzienlijk beter geheugengebruik
Deployment	GAC, IIS-afhankelijk, machine-brede installaties	Self-contained, side-by-side, container-vriendelijk
Webframework	ASP.NET MVC 5, Web Forms, WCF	ASP.NET Core, Minimal APIs, gRPC, Blazor
Cloud-native	Beperkte containerondersteuning	Eersteklas Docker/Kubernetes-ondersteuning
Dependency injection	Externe libraries (Autofac, Unity, etc.)	Ingebouwd, eersteklas
Configuratie	web.config / app.config XML	appsettings.json, omgevingsvariabelen, Azure Key Vault
CI/CD	MSBuild, oudere tooling	dotnet CLI, uitstekende GitHub Actions/Azure DevOps-ondersteuning
NuGet-ecosysteem	Krimpend — veel libraries zijn alleen .NET 6+	Volledige toegang tot het ecosysteem
Werving	Steeds moeilijker om developers te vinden	Sterke talentenpool, wordt actief onderwezen
Langetermijnrisico	Laag risico op korte termijn, toenemend risico na verloop van tijd	De primaire investering van Microsoft

Het prestatieverschil is echt, maar wordt vaak overdreven in migratiepitches. Ja, ASP.NET Core verwerkt meer requests per seconde. Maar als je interne ERP 200 gelijktijdige gebruikers bedient en prima draait op Framework — dan is ruwe doorvoer niet je probleem.

Moet je migreren van .NET Framework naar .NET Core?

Migratie is zinvol wanneer de kosten van blijven hoger zijn dan de kosten van verhuizen — en die berekening is voor elk systeem anders. Ik heb teams zes maanden zien besteden aan het migreren van een interne tool die prima werkte, alleen maar omdat “Framework oud is.” Dat is geen businesscase.

Dit is wanneer migratie duidelijk de moeite waard is:

Je hebt Linux- of containerdeployments nodig. Hier is geen workaround voor. Als je infrastructuurstrategie op Kubernetes is gebaseerd, heb je .NET 8+ nodig.
Je loopt tegen prestatielimieten aan. Als je horizontaal schaalt omdat Framework het niet bijhoudt, overtreffen de kosten van meer servers die van migratie.
Je NuGet-dependencies laten Framework-ondersteuning vallen. Dit versnelt. Wanneer je authenticatiebibliotheek of ORM stopt met het publiceren van Framework-compatibele packages, leef je op geleende tijd.
Je kunt geen developers vinden. Junior en medior .NET-developers in 2026 hebben vaak nog nooit .NET Framework aangeraakt. Je talentenpool krimpt elk jaar.

De verborgen kosten van migratie waar niemand over praat

De meeste migratieschattingen die ik zie dekken codewijzigingen en testen. Ze dekken zelden al het andere.

CI/CD-pipeline revisie. Je buildserver heeft waarschijnlijk Framework-specifieke tooling — MSBuild targets, IIS deployment-scripts, aangepaste PowerShell die ervan uitgaat dat web.config bestaat. Dat verandert allemaal. Bij een recent project kostte alleen al het pipelinewerk drie weken.

Teamtraining. De middleware-pipeline, dependency injection-patronen en het configuratiesysteem van ASP.NET Core zijn fundamenteel anders dan wat Framework-developers kennen. Plan tijd in zodat je team de nieuwe patronen goed kan leren, niet alleen copy-pasten van Stack Overflow.

Integraties met derden. Als je afhankelijk bent van COM interop, Windows-specifieke API’s of legacy SOAP-services via WCF client, verwacht dan verrassingen. WCF client-side wordt gedeeltelijk ondersteund via CoreWCF, maar het is geen drop-in vervanging.

Testlacunes. Als je Framework-applicatie minimale testdekking heeft — en laten we eerlijk zijn, veel legacy .NET-apps hebben dat — migreer je zonder vangnet. Je zult tests moeten schrijven voor of tijdens de migratie, en die kosten lopen snel op.

Parallel onderhoud. Tenzij je een big-bang cutover kunt doen, draai je weken of maanden twee versies van hetzelfde systeem. Dat betekent dubbele bugfixes, dubbele deployments en dubbele cognitieve belasting voor je team.

Wanneer .NET Framework daadwerkelijk de juiste keuze is in 2026

.NET Framework 4.8.x is de juiste keuze wanneer je applicatie stabiel is, aan de bedrijfsbehoeften voldoet en de kosten van migratie hoger zijn dan de waarde die het oplevert. Dat is geen controversieel standpunt — het is pragmatisme.

Ik werk momenteel aan een project bij Boskalis waar we ASP.NET Web Forms-applicaties migreren. Maar niet allemaal. Sommige van die systemen kun je nu beter op Framework laten, omdat:

Het interne tools zijn met een kleine gebruikersgroep. De prestatievoordelen van .NET 8 zijn irrelevant wanneer 50 mensen het systeem gebruiken.
Ze zwaar leunen op Web Forms. Er is geen Web Forms-equivalent in ASP.NET Core. Migratie betekent een complete UI-herschrijving, geen port. Dat is een ander project met een ander budget.
Ze werken. Het systeem is stabiel, gepatcht en doet wat het bedrijf nodig heeft. “Het draait op oude technologie” is geen bug.
.NET Framework 4.8.x wordt meegeleverd met Windows en wordt ondersteund gedurende de levensduur van het besturingssysteem. Je Windows Server 2022-machines blijven het draaien met beveiligingspatches tot 2031.

Het belangrijke onderscheid is tussen ondersteund en actief doorontwikkeld. Framework wordt ondersteund. Het krijgt beveiligingsfixes. Het krijgt alleen geen nieuwe features meer. Voor veel applicaties is dat prima.

Een besliskader voor je .NET-stack

Wanneer een klant me vraagt of ze moeten migreren, loop ik deze vragen door:

Wordt de applicatie actief doorontwikkeld? Als je regelmatig features toevoegt, migreer dan. Je wilt toegang tot moderne tooling en libraries.
Verandert je deployment-doel? Overstap naar cloud-native infrastructuur of containers? Migratie is niet optioneel.
Wat is je testdekking? Onder de 40%? Plan aanzienlijke tijd in voor het schrijven van tests voordat je aan de migratie begint.
Heb je Web Forms- of WCF server-side dependencies? Zo ja, dan is dit geen migratie — het is een herschrijving. Prijs het dienovereenkomstig.
Wat is de verwachte resterende levensduur van de applicatie? Als deze over 2-3 jaar wordt uitgefaseerd, laat hem dan op Framework staan. Besteed het migratiebudget aan de vervanger.
Kun je developers vinden en behouden? Als je Framework-expertise geconcentreerd is in een of twee mensen, is dat een bedrijfscontinuiteitsrisico ongeacht de technische merites.

Als de antwoorden richting migratie wijzen, begin dan met het strangler fig-patroon — bouw nieuwe features in .NET 8/9 naast de bestaande Framework-applicatie en routeer geleidelijk verkeer naar de nieuwe services. Het is langzamer dan een big-bang herschrijving, maar het is een stuk veiliger.

Veelgestelde vragen

Is .NET Framework dood?

Nee. .NET Framework 4.8.x wordt nog steeds ondersteund door Microsoft en wordt meegeleverd met Windows. Het ontvangt beveiligingspatches en betrouwbaarheidsfixes. Het wordt echter niet meer actief doorontwikkeld — geen nieuwe features, geen prestatieverbeteringen. Het zit in onderhoudsmodus, en dat is een belangrijk onderscheid. Voor bestaande stabiele applicaties blijft het een bruikbare runtime.

Kunnen .NET Framework en .NET 8 naast elkaar draaien?

Ja. Het zijn volledig onafhankelijke runtimes. Je kunt .NET Framework 4.8 en .NET 9-applicaties op dezelfde server draaien zonder conflicten. Dit is wat het strangler fig-migratiepatroon mogelijk maakt — je kunt stapsgewijs functionaliteit verplaatsen naar .NET 8/9 terwijl je Framework-applicatie blijft draaien.

Hoe lang wordt .NET Framework 4.8 nog ondersteund?

.NET Framework 4.8.x volgt de levenscyclus van de Windows-versie waar het bij wordt geleverd. Op Windows Server 2022 betekent dat ondersteuning tot oktober 2031. Op Windows 11 volgt het de ondersteuningscyclus van het besturingssysteem. Je staat niet voor een dreigend end-of-life scenario.

Wat is de beste .NET-versie om naar te migreren in 2026?

Richt je nu op .NET 8 voor productiemigraties — het is de huidige Long-Term Support release met ondersteuning tot november 2026. Als je een migratie start die later dit jaar landt, overweeg dan .NET 10 (de volgende LTS-release, verwacht in november 2026). Vermijd migratie naar oneven versies zoals .NET 9 voor langlevende productiesystemen, aangezien die slechts 18 maanden ondersteuning krijgen.

Hoe lang duurt een migratie van .NET Framework naar .NET 8 doorgaans?

Dat hangt volledig af van de complexiteit van de applicatie. Een rechttoe rechtaan ASP.NET MVC 5 API met goede testdekking kan 4-8 weken duren. Een ASP.NET Web Forms-applicatie met COM-dependencies en data-access die zwaar leunt op stored procedures kan 6-12 maanden duren — omdat het in feite een herschrijving is. Het eerlijke antwoord is: laat iemand met ervaring je specifieke codebase beoordelen voordat je je aan een tijdlijn committeert.