.NET Framework and .NET 8 to .NET 10
Cohash gets .NET applications onto .NET 10, the current long-term support release. A .NET 8 or 9 app is usually just a retarget, package updates and a test run. With .NET Framework apps we port libraries first, then move ASP.NET to ASP.NET Core, incrementally and side by side if needed. We swap out Windows-only dependencies and containerize where it's worth it. Nothing ships without tests and a rollback.
- 01Portfolio scan
- 02.NET 8 and 9 retargets first
- 03Libraries before applications
- 04Incremental web migration
- 05Hosting and pipeline
The story
Told without the client's name or anything that could identify them.
A product engineering team ran a mix of .NET 8 services and older .NET Framework 4.x apps with WCF services and Web Forms pages, all on Windows Server VMs. With .NET 8 and 9 reaching end of support on 10 November 2026 and Framework 4.6.2 following on 12 January 2027, security scanners were about to flag both. We scanned the portfolio first and retargeted the .NET 8 and 9 apps to .NET 10 ahead of the November date. The Framework apps then moved library by library, with an ASP.NET Core front taking over endpoints one at a time and each WCF service moved to CoreWCF, gRPC or REST based on its callers.
why it was urgentThe date most teams are working toward is 10 November 2026, when .NET 8 and .NET 9 both reach end of support. .NET 10 LTS is supported to 14 November 2028. Framework apps have their own clock: support for 4.6.2 ends on 12 January 2027. Microsoft has also deprecated .NET Upgrade Assistant and now points people to the GitHub Copilot modernization agent instead.
- openSecurity scanners will start flagging .NET 8 runtimes as unsupported after 10 November 2026.
- recurringCore business apps still run on .NET Framework 4.x with WCF services and Web Forms pages.
- blockedNuGet packages pinned years ago block any target framework change.
- openEverything has to live on Windows Server VMs. That keeps the hosting bill and the patching work high.
The estate, before and after
Before: .NET 8 services and Framework apps on Windows VMs
Browsers hit Web Forms pages, and internal callers used WCF SOAP services on .NET Framework 4.x, running next to the .NET 8 and 9 services. It all sat on Windows Server VMs. Pinned NuGet packages and Windows-only APIs got in the way of any framework change.
Read the diagram as text
- Browsers → .NET Framework 4.x apps: HTTP
- Internal callers → .NET Framework 4.x apps: WCF SOAP
- .NET Framework 4.x apps → Shared libraries: references
- .NET 8 and 9 services → Shared libraries: references
- .NET Framework 4.x apps → Windows Server VMs: deployed to
- .NET 8 and 9 services → Windows Server VMs: deployed to
- .NET Framework 4.x apps → Registry and COM: Windows APIs
After: .NET 10 apps behind an ASP.NET Core front
Browser traffic now lands on an ASP.NET Core app, which peels routes off the remaining ASP.NET app one by one. The services are on .NET 10 LTS, old WCF callers talk CoreWCF, gRPC or REST, and CI deploys to Linux containers or App Service when the dependencies allow it.
Read the diagram as text
- Browsers → ASP.NET Core front: HTTP
- Internal callers → CoreWCF: gRPC or REST
- ASP.NET Core front → .NET 10 services: migrated routes
- ASP.NET Core front → Remaining ASP.NET app: proxied routes
- CoreWCF → .NET 10 services: service calls
- .NET 10 services → Shared libraries: references
- Remaining ASP.NET app → Shared libraries: references
- .NET 10 services → Linux containers or App Service: runs on
- CI pipeline → Linux containers or App Service: deploy
How we run it, phase by phase.
5 phases take you from .NET Framework 4.x, .NET 8 and .NET 9 apps to .NET 10 LTS. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Portfolio scan
Every solution goes on a list. Target framework, project type, NuGet dependencies, deployment target, and any Windows-only API it touches, such as the registry, WCF server, System.Web or COM. Read down that list and the quick retargets separate from the real ports.
- phase 02
.NET 8 and 9 retargets first
Quick retargets go to net10.0 first. We update packages, work through the breaking changes listed in the release notes and run the tests. That's the fastest progress you'll make before the November deadline.
- phase 03
Libraries before applications
In the Framework apps, shared class libraries go to .NET Standard 2.0 first, or we multi-target them. That way the old apps and the new ones can both use them in the middle of the port.
- phase 04
Incremental web migration
We put an ASP.NET Core app in front of the old ASP.NET app and move endpoints over one at a time. With WCF services, the callers decide where each one goes, whether CoreWCF, gRPC or REST.
- phase 05
Hosting and pipeline
Switch CI to build against .NET 10. Move apps to Linux containers or App Service where their dependencies let you. From then on, runtime patching rides along with the regular release cycle.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Every app targets a supported runtime
.NET 8 and 9 apps now target net10.0, the LTS release supported to 14 November 2028, with package updates and breaking changes worked through behind tests.
- result 02
Shared libraries serve old and new apps
We moved class libraries to .NET Standard 2.0 or multi-targeted them. Framework apps kept working the whole time the apps calling them were being ported.
- result 03
Web endpoints moved over one at a time
An ASP.NET Core app in front of the old ASP.NET app takes over routes incrementally, so each move ships with its own rollback.
- result 04
Each WCF service has a decided replacement
We moved WCF services to CoreWCF, gRPC or REST based on what their callers needed, and wrote the choice into each app's port plan.
- result 05
Runtime patching is part of normal releases
CI builds against .NET 10 now. Where dependencies allowed, we moved apps to Linux containers or App Service. Runtime updates ship with the regular release cycle.
Risks we plan for
-
System.Web and Web Forms
ASP.NET Core has nothing that maps straight onto Web Forms. So those pages are either rewritten in Razor Pages or Blazor, or left on Framework with a date for dealing with them.
-
Third-party packages with no modern build
Some vendor libraries never shipped for modern .NET. Each one needs a replacement, a wrapper or a conversation with the vendor.
-
Behavior changes hidden by thin tests
Framework and .NET have different defaults for serialization, globalization and configuration. If an app has few tests, we write characterization tests before porting it, so we know what it did before.
Where AI helps, and where it needs guardrails
For upgrades, Microsoft now points people at the GitHub Copilot modernization agent in Visual Studio, and AWS Transform has a Windows agent for .NET and SQL Server. They draft plans and code changes fast. We still review every commit and test between steps, and we keep the agents out of production configuration and secrets.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- document01
Portfolio scan with target, effort drivers and order per solution
yours to keep - document02
Retargeted .NET 8 and 9 apps on .NET 10
yours to keep - plan03
Port plan per .NET Framework app, with Web Forms and WCF decisions
yours to keep - tests04
CI pipelines building and testing against .NET 10
yours to keep - document05
Runtime patching process tied to Microsoft's monthly releases
yours to keep
Platforms and services on this move
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Why does .NET 8 end support at the same time as .NET 9?
Microsoft's support policy page lists both ending on 10 November 2026, even though .NET 8 is an LTS release. .NET 10 is the LTS release to target, with support to 14 November 2028.
02Is .NET Framework 4.8 going away?
No separate end date for 4.8 and 4.8.1. They live and die with the Windows version they run on. Older 4.x versions do end, and 4.6.2 goes on 12 January 2027. New features only land in modern .NET.
03How long does a Framework port take?
It depends on how much of the app depends on System.Web, WCF and Windows-only APIs, and how good the test coverage is. A class library can take days and a large Web Forms app much longer. We scan first and size each app.
04Should we rewrite instead?
Rarely all at once. Incremental migration keeps the app running while pieces move. A rewrite makes sense only when the business logic itself needs to change.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyAuth0 Rules and Hooks to Actions before end of life
Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.
read the case study085b4781 - 01Microsoft: .NET and .NET Core support policydotnet.microsoft.com ↗
- 02Microsoft Lifecycle: .NET Frameworklearn.microsoft.com ↗
- 03Microsoft Learn: .NET Upgrade Assistant overview (deprecation notice)learn.microsoft.com ↗
- 04AWS Transformaws.amazon.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it