Microsoft support for .NET 8 and .NET 9 ends on November 10, 2026. Applications will not stop running the following day. However, once these versions are out of support, they will no longer receive regular security servicing under Microsoft's lifecycle policy. For a production business system, migration should be a controlled engineering change—not simply a project-file edit.
1. What changes on November 10, 2026?
End of support applies to .NET runtime and SDK releases and the related Microsoft components covered by the lifecycle, including ASP.NET Core and Entity Framework Core. Existing applications can still execute, but developers should not expect new regular security patches for unsupported releases.
- .NET 8: LTS; end of support November 10, 2026.
- .NET 9: STS; end of support November 10, 2026.
- .NET 10: LTS; supported through November 14, 2028.
The date is not an automatic outage. The operational and security risk of remaining on an unsupported runtime grows over time and depends on Internet exposure, data sensitivity and available compensating controls.
2. Which applications should be included in the inventory?
Do not check only the public-facing website. A business solution may also include ASP.NET Core APIs, worker services, Windows services, scheduled jobs, desktop applications, microservices and batch processes. Include Docker images, installed production runtimes, CI/CD agents and database tooling.
dotnet --list-sdks
dotnet --list-runtimes
dotnet --infoSearch the codebase for TargetFramework, TargetFrameworks, global.json, Directory.Packages.props, Dockerfiles and pipeline definitions. An application can still target net8.0 even when the build machine has the .NET 10 SDK installed.
3. Do I need to upgrade from .NET 8 to .NET 9 first?
No intermediate .NET 9 production release is required. You can move an application directly to net10.0, but the compatibility changes introduced by both intermediate and target releases still matter. Not deploying .NET 9 is not the same as ignoring its breaking changes.
4. Practical migration workflow for ASP.NET Core applications
Step 1 — Establish a baseline
Record framework versions, dependencies, existing test results, pipeline status, critical response times and known production issues. Work in a dedicated branch and define a practical rollback route before touching production.
Step 2 — Install .NET 10 SDK and update project targets
Install a supported .NET 10 SDK on development machines and build agents. Update the target framework in the relevant .csproj files:
<PropertyGroup>
<TargetFramework>net10.0</TargetFramework>
</PropertyGroup>If the repository contains global.json, align its SDK version with one that is installed in every relevant build environment. Confirm IDE and CI pipeline compatibility.
Step 3 — Review packages and providers
Bring framework-coupled Microsoft packages to compatible versions, particularly ASP.NET Core and EF Core dependencies. Check third-party library compatibility and release notes. Avoid blindly upgrading unrelated packages.
dotnet restore
dotnet list package --outdated
dotnet build --configuration ReleaseFor EF Core, validate provider compatibility, entity mappings, generated SQL, migrations, transactions and concurrency behavior. Updating an EF Core provider does not automatically imply that the database schema needs to change.
Step 4 — Read the breaking-change documentation
Review .NET 9 and .NET 10 breaking changes, plus the relevant ASP.NET Core and EF Core notes. Behavioral changes can escape compile-time checks: an HTTP request, JSON payload or authentication flow may behave differently without any build error.
Examples documented for ASP.NET Core 10 include different login redirect behavior for recognized API endpoints and various deprecated APIs. Assess whether such changes affect your application rather than assuming every change applies.
Step 5 — Update runtime hosting and deployment
For framework-dependent deployments, install the required .NET 10 runtime on the host. For IIS, verify the ASP.NET Core Hosting Bundle. For Docker, update both SDK build images and the runtime or aspnet images. Check health probes, reverse-proxy settings and hosting constraints.
Step 6 — Validate runtime behavior, not just compilation
- Unit, integration and end-to-end tests for business-critical workflows.
- Authentication and authorization, including 401/403 behavior.
- Public API contracts: JSON, status codes, validation and error handling.
- Database queries, transactions, migrations and critical performance paths.
- Workers, queues, scheduled jobs, SMTP/HTTP integrations and retries.
- Logging, metrics, health checks and post-deployment monitoring.
Deploy to a representative staging environment first. Use progressive rollout where possible and make sure the rollback procedure can actually be executed.
5. How difficult is a .NET 10 migration?
Complexity depends more on dependencies and production constraints than on lines of code. A small, well-tested API with a simple deployment may be straightforward. A system combining several applications, legacy libraries, database providers, scheduled services and external integrations requires more up-front analysis.
Upgrading a modern app from .NET 8 to .NET 10 is also different from modernizing an application built on .NET Framework 4.x. These are separate migration paths.
6. What if you cannot migrate before November 10?
A rushed production deployment is not a sensible response to the deadline. Identify affected services, exposure, data sensitivity and known vulnerabilities; then agree on a realistic remediation window.
Temporary risk reductions may include tighter network segmentation, stronger access controls, monitoring, minimizing Internet-facing endpoints and updating other supported dependencies. These measures do not restore Microsoft support for .NET 8 or .NET 9 and should not replace the migration plan.
7. Pre-production checklist
- Inventory all
net8.0/net9.0projects and deployed runtimes. - Validate .NET 10 SDK, build agents and
global.json. - Review NuGet packages, EF Core providers and third-party libraries.
- Assess breaking changes against the real codebase.
- Update IIS, Linux, Windows or Docker hosting where required.
- Complete functional, regression, security and performance testing.
- Prepare rollback, backups and post-release observability.
Frequently asked questions
Will .NET 8 applications stop working on November 11, 2026?
No. The deadline affects regular support and security servicing, not the ability of existing binaries to run.
Is upgrading to .NET 10 mandatory?
There is no technical shutdown that forces an immediate upgrade, but .NET 10 LTS is the natural supported destination for applications currently targeting .NET 8 or .NET 9.
Is changing TargetFramework to net10.0 sufficient?
No. The SDK, packages, breaking changes, hosting setup and functional behavior must be validated before the release.
Do I need to rewrite my application?
Usually not. Most modern ASP.NET Core projects can be upgraded incrementally, with the effort depending on dependencies and custom code.
What if my application uses .NET Framework 4.8?
This deadline applies to .NET 8 and .NET 9, not .NET Framework. Microsoft states that .NET Framework 4.8 continues to be supported as long as it is installed on a supported version of Windows (check the official policy for details). If your application runs on .NET Framework, the path is different: it is a gradual modernization towards modern .NET, not a simple version upgrade.
Should I wait for .NET 11?
For a system that must stay supported for a long time, .NET 10 LTS is the natural target. .NET 11 is expected to be an STS release, with a shorter support period than an LTS, and it does not remove the need to leave .NET 8 and .NET 9 before the deadline. Moving to .NET 10 now does not prevent you from evaluating .NET 11 later.
Does anything change if I use Azure App Service or another managed service?
The support lifecycle is Microsoft's, but managed services may publish their own announcements and retirement dates for runtime versions. Check your provider's notices and the runtime versions available on your platform before planning the release.
Official Microsoft resources
In summary
End of support does not mean an outage. It means managing a risk.
Inventory your applications, validate compatibility and plan an upgrade to .NET 10 LTS with tests and rollback. Migration is a controlled engineering change, not just a target framework edit.
Related guides
Need to upgrade a business application to .NET 10?
I help software houses and development teams assess dependencies, plan ASP.NET Core and Web API upgrades, verify breaking changes, run regression tests and prepare controlled production releases.