---
title: ".NET 8 & 9 End of Support: The CMS Deadline Everyone Is Missing"
slug: net-8-9-end-of-support-the-cms-deadline-everyone-is-missing
date: 2026-10-12
author: Abdul Wahab
categories: [Migration Guide, Kentico, Sitecore]
excerpt: ".NET 8 and .NET 9 both lose support on November 10, 2026 — seven weeks before key CMS vendor deadlines. Here's what CMS teams need to do."
tldr: ".NET 8 and .NET 9 end support November 10, 2026. Retarget your CMS to .NET 10 now — don't bundle it with a replatform that could slip past the deadline."
canonical: https://clonepartner.com/blog/net-8-9-end-of-support-the-cms-deadline-everyone-is-missing
---

# .NET 8 & 9 End of Support: The CMS Deadline Everyone Is Missing


# .NET 8 & 9 End of Support: The CMS Deadline Everyone Is Missing

Microsoft ends support for .NET 8 and .NET 9 on **November 10, 2026** — the same Patch Tuesday. After that date, both runtimes stop receiving security patches, servicing updates, and technical support. The recommended upgrade target is **.NET 10**, an LTS release supported through November 2028. ([devblogs.microsoft.com](https://devblogs.microsoft.com/dotnet/dotnet-8-9-end-of-support/))

If your content management platform runs on .NET 8 or .NET 9, this deadline applies whether or not your CMS vendor's own end-of-support date has arrived. For several major CMS platforms (tracked in our [CMS and DXP end-of-support calendar](https://clonepartner.com/blog/blog/cms-dxp-end-of-support-calendar-20262027)), the Microsoft runtime deadline lands **before** the vendor's own cutoff — the framework goes dark before the product does.

This date is widely missed in CMS migration planning. Most commentary about Kentico Xperience 13, Sitecore, and Optimizely deadlines was written before Microsoft announced the .NET 9 support extension. The .NET cutoff arrives **seven weeks before** Kentico Xperience 13's own end-of-support date of December 31, 2026, and **51 days before** Sitecore 10.0 and 10.1 extended support expires.

For the full calendar of 2026 software deadlines, see our [complete EOL calendar](https://clonepartner.com/blog/blog/software-end-of-life-2026-the-complete-eol-calendar). For the broader Microsoft end-of-support wave (SharePoint, Exchange, OOS), see our [Microsoft 2026 end-of-support guide](https://clonepartner.com/blog/blog/microsoft-2026-end-of-support-timeline-migration-guide).

## Why do .NET 8 and .NET 9 expire on the same day?

**.NET 8** is a Long Term Support (LTS) release, shipped November 14, 2023, with a three-year support window that closes on November 10, 2026. **.NET 9** is a Standard Term Support (STS) release, shipped November 12, 2024. Under the original 18-month STS policy, .NET 9 would have expired on **May 12, 2026**.

In September 2025, [Microsoft extended STS support from 18 to 24 months](https://devblogs.microsoft.com/dotnet/dotnet-sts-releases-supported-for-24-months/), effective starting with .NET 9. That extension moved the .NET 9 end-of-support date to the same day as .NET 8.

| Version | Released | Support Type | End of Support |
|---|---|---|---|
| .NET 8 | November 14, 2023 | LTS (36 months) | **November 10, 2026** |
| .NET 9 | November 12, 2024 | STS (24 months, extended) | **November 10, 2026** |
| .NET 10 | November 11, 2025 | LTS (36 months) | November 2028 |
| .NET 11 | November 2026 (expected) | STS (24 months) | ~November 2028 |

Teams that moved from .NET 8 to .NET 9 expecting extra runway gained none. Both tracks converge on the same date. November 10, 2026 is a Patch Tuesday, so either runtime may receive one final update that day if a critical issue exists.

**Note on .NET 11:** Even if your team waits for .NET 11's November 2026 release, it will be an STS release — not LTS. If you want the longest support runway, .NET 10 is the correct target. Both .NET 10 and .NET 11 will reach end of support around November 2028, but .NET 10 is already available now.

## What actually happens after November 10, 2026?

Your applications keep running. Nothing stops working on November 11. What changes is the risk posture:

- **No security patches.** Any vulnerability in the .NET runtime, ASP.NET Core, or Entity Framework Core disclosed after November 10 stays open on .NET 8 and .NET 9. Microsoft's [official announcement](https://devblogs.microsoft.com/dotnet/dotnet-8-9-end-of-support/) states that no new security updates will be issued for either version.
- **No technical support.** Microsoft support cases require a supported runtime version with the latest patch installed.
- **Visual Studio 2022 flags the components.** A future servicing update will mark .NET 8 and .NET 9 components as out of support in the IDE. The Visual Studio installer already supports bulk removal of out-of-support components and can be configured to remove them automatically during future updates.
- **Compliance exposure accumulates.** Vulnerability scanners flag end-of-life .NET runtimes. That becomes a finding in PCI DSS, SOC 2, and ISO 27001 audits — not on day one, but steadily as unpatched CVEs stack up.
- **Build pipeline friction.** Pipelines in Azure DevOps and GitHub Actions that use `UseDotNet@2` or `setup-dotnet` with strict security policies may begin failing builds that target unsupported SDKs.

> **Do not confuse the modern .NET lifecycle with the legacy .NET Framework lifecycle.** .NET Framework 4.8 is tied to the underlying Windows Server OS lifecycle and follows a different support calendar. The November 10, 2026 deadline applies specifically to the modern, cross-platform .NET 8 and .NET 9 runtimes.

## Cross-platform CMS deadline reference

The table below consolidates the information most upgrade teams need in one place. "Affected component" identifies which part of each CMS estate runs on modern .NET and is subject to the November 10 cutoff. Vendor EOL dates are the latest published figures as of mid-2026.

| CMS Platform | Affected Component | Current .NET Target | Recommended Target | .NET EOL | Vendor EOL |
|---|---|---|---|---|---|
| Kentico Xperience 13 | ASP.NET Core live site | .NET 8 or .NET 9 | .NET 10 (from Refresh 14) | Nov 10, 2026 | Dec 31, 2026 |
| Xperience by Kentico | Custom code / delivery | .NET 8 or .NET 9 | .NET 10 | Nov 10, 2026 | No announced date |
| Sitecore XP 9.x–10.2 | Identity Server 8.x | .NET 8 | No .NET 10 path without Sitecore upgrade | Nov 10, 2026 | Varies by version |
| Sitecore XP 10.3–10.4 | Identity Server 9.x | .NET 8 | .NET 10 (Identity Server 9.x) | Nov 10, 2026 | Dec 31, 2026 (10.0/10.1) |
| Optimizely CMS 12 | Full CMS stack | .NET 8 or .NET 9 | .NET 10 (Core 12.24.0+, UI 12.34.4+) | Nov 10, 2026 | No announced date |
| Sitefinity | ASP.NET Core Renderer only | .NET 8 | .NET 10 SDK (current system requirements) | Nov 10, 2026 | Per Sitefinity version |
| DNN Platform | Custom extensions/services | .NET Framework 4.8 (core) | .NET 10 for modern services | Not applicable (core) | Per DNN version |

**Key:** "No .NET 10 path without Sitecore upgrade" means the Identity Server component that ships with Sitecore XP 9.x through 10.2 does not support .NET 10. Upgrading Identity Server to a version that does requires first upgrading the Sitecore XP version.

## Which .NET CMS platforms sit on this deadline?

### Kentico Xperience 13

**Kentico Xperience 13** reaches its own [vendor end-of-support on **December 31, 2026**](https://clonepartner.com/blog/blog/kentico-xperience-13-end-of-support-2026-what-actually-changes) — seven weeks *after* the .NET deadline. The framework cutoff hits first.

Kentico's [September 2026 changelog](https://docs.kentico.com/changelog) states this directly: Microsoft ends support for .NET 8 and .NET 9 on November 10, 2026, and after that date those framework versions no longer receive security updates. The [Xperience 13 release notes](https://docs.kentico.com/13/release-notes-xperience-13) instruct teams to migrate ASP.NET Core projects to .NET 10, supported since Refresh 14.

The precedent is already set. When Microsoft ended .NET 6 support on November 12, 2024, Kentico [dropped .NET 6 from current Refreshes](https://devnet.kentico.com/articles/kentico-xperience-13-s-net-support-lifecycle-net-6). Projects updating to the latest Refresh must now target **.NET 8 through .NET 10**. After November 10, 2026, .NET 10 is the only supported framework in that range.

Xperience 13 is not one runtime story. The administration application runs on .NET Framework 4.8 — a different product with a different lifecycle tied to Windows. ASP.NET MVC 5 live sites also remain on the .NET Framework side. The .NET 8/9 deadline lands on the **ASP.NET Core live site** only.

**What to do:** Retarget your ASP.NET Core live-site project to `net10.0` before November 10. This is a framework upgrade, not a CMS replatform — the two are separate efforts.

### Xperience by Kentico

Kentico's modern SaaS platform also supports .NET 8 through .NET 10. The [September 2026 changelog](https://docs.kentico.com/changelog) states that .NET 8 and .NET 9 support "will be discontinued in a future release" and recommends updating project target frameworks to .NET 10 before the deadline. The same framework clock applies to custom code running against this platform.

### Sitecore XP and Identity Server

Sitecore's on-premises platform (XP/XM 9.x–10.x) runs on .NET Framework 4.8, which follows Windows's support lifecycle — not the modern .NET timeline. But critical supporting services run on modern .NET, and that is where this deadline bites.

**Sitecore Identity Server 8.x** is built on .NET 8 and supports Sitecore XP versions 9.1 through 10.4. Community testing by [Merkle's Sitecore practice](https://sitecore.merkle.com/.net8-eol-and-IdentityServer) confirms that Identity Server 8.x does not run on .NET 10. As of mid-2026, Sitecore has not published an official KB documenting this incompatibility — the Merkle finding represents the most detailed public analysis available. If your infrastructure team removes unsupported runtimes after November 2026, authentication breaks.

**This incompatibility is not uniform across XP versions.** Identity Server 9.x is available for XP 10.3 and newer and does support the path to .NET 10. Teams running Sitecore XP 9.x or 10.0–10.2 have no Identity Server upgrade path to .NET 10 without first upgrading Sitecore itself — and those versions are already in sustaining support (Sitecore's term for the phase after mainstream support ends, during which only critical security patches are issued) or end of life.

Sitecore's own .NET 6 advisory illustrates how this plays out operationally. When Microsoft ended .NET 6, Sitecore [called out Identity Server 7.x, Publishing Service 7.0, and older CLI versions](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003513) as affected and recommended upgrades to .NET 8-compatible versions. The same pattern will repeat with .NET 8. [Sitecore 10.5 server requirements](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB0087164) list the latest .NET 10 Windows Hosting Bundle for Identity Server.

Sitecore XM Cloud (SaaS) is managed by Sitecore and not directly affected. Teams using the ASP.NET Core SDK for XM Cloud rendering should verify their rendering host targets a supported .NET version.

**Sitecore 10.0** and **10.1** extended support end on **December 31, 2026**, so for some estates the vendor deadline lands later than the runtime deadline in connected services — the same layered clock problem as Kentico.

### Optimizely CMS 12

**Optimizely CMS 12 is fully compatible with .NET 10.** Optimizely [confirmed this in May 2026](https://world.optimizely.com/blogs/bien-nguyen/dates/2026/5/optimizely-cms-12-now-fully-supports-.net-10), recommending EPiServer.Cms.Core **12.24.0** or higher and EPiServer.Cms.UI **12.34.4** or higher. Commerce 14 added .NET 10 support from version **14.46.0**, so the full CMS 12 + Commerce 14 stack can run on .NET 10.

**CMS 12 on .NET 10 is a valid stopping point.** This is the part that changed since most Optimizely upgrade guidance was written. You do not need to jump to CMS 13 to address the .NET deadline — retarget to `net10.0` and update packages to the minimum versions above. For a well-maintained Optimizely codebase, this is a runtime modernization project, not a full product migration.

```xml
<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
  </PropertyGroup>
</Project>
```

### Sitefinity

**Sitefinity's core CMS backend runs on .NET Framework 4.8** — a Windows component with a separate support lifecycle. The backend itself is not affected by the November 10 cutoff.

The **ASP.NET Core Renderer** — Sitefinity's decoupled frontend layer — is the affected surface. Progress has already updated the requirement: [current Sitefinity system requirements](https://www.progress.com/documentation/sitefinity-cms/system-requirements) state that the ASP.NET Core Renderer requires **.NET SDK 10.0**. Teams still running the renderer on .NET 8 need to update. Progress also [states explicitly](https://www.progress.com/support/sitefinity-lifecycle-policy) that third-party framework support can end before support for a Sitefinity version ends, and in that case Progress recommends moving to a Sitefinity version that uses a newer framework.

If you are on Sitefinity's traditional MVC 5 frontend with no ASP.NET Core Renderer, this specific .NET deadline does not hit the rendering layer. It may still apply to custom ASP.NET Core microservices or APIs running alongside the CMS.

### DNN (DotNetNuke)

**DNN Platform's core runs on .NET Framework 4.8 and IIS.** The main application is not on modern .NET and is not directly affected by the .NET 8/9 end of support.

Where DNN intersects this deadline is in tooling: [DNN 10.4.0](https://github.com/dnnsoftware/Dnn.Platform/releases) targets .NET 10 for its deploy client and updated its .NET SDK dependencies. Custom extensions or modules built with ASP.NET Core are affected individually. If your DNN estate includes .NET 8 services running alongside the platform, scope those for a retarget.

## Why most teams will miss this deadline

Three factors compound to make this cutoff easy to overlook:

**The commentary was written before the dates aligned.** Most 2025-era migration guidance for Kentico, Sitecore, and Optimizely assumed .NET 9's STS support would expire in May 2026. The September 2025 extension moved it six months later. Articles written before that change reference the wrong .NET 9 date.

**CMS vendor deadlines distract from framework deadlines.** Teams plan around Kentico's December 31 cutoff or Sitecore's support phases, not the .NET lifecycle underneath. The vendor deadline feels more actionable — until you realize the framework goes unsupported first.

**"LTS" creates false comfort.** Teams hear ".NET 8 is LTS" and assume extended coverage. LTS means three years from the release date, not three years from when you adopted it. A project that started on .NET 8 in mid-2025 gets roughly 16 months of support remaining, not 36.

## Two clocks: runtime upgrade vs. CMS migration

This is the distinction that saves — or costs — teams months of unnecessary risk.

**Retargeting .NET** means updating your `.csproj` from `net8.0` to `net10.0`, resolving breaking changes, updating NuGet packages, and redeploying. The [official .NET 10 breaking changes list](https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-10/breaking-changes) is the authoritative reference. The most commonly impactful changes for CMS estates involve:

- **`System.Text.Json`**: Default behavior changes for nullable reference type handling and constructor-based deserialization in .NET 9–10 may break existing serialization if you rely on implicit defaults.
- **Cryptography APIs**: Several legacy APIs in `System.Security.Cryptography` deprecated in .NET 8 are removed or throw in .NET 10. PKCS and RSA usage in custom auth or license code needs review.
- **ASP.NET Core authentication middleware**: Changes to `IAuthenticationService` and cookie chunking defaults can affect session and federated auth implementations.
- **HttpClient and networking**: `SocketsHttpHandler` behavior changes for connection pooling and TLS renegotiation.

For a well-maintained codebase, retargeting can complete in days. For a codebase with significant dependencies on deprecated APIs or older NuGet packages, budget one to two weeks.

**Replatforming the CMS** — migrating from Kentico Xperience 13 to Xperience by Kentico, from Sitecore XP to XM Cloud, or from Optimizely CMS 12 to CMS 13 — is a separate effort measured in months: content migration, template rebuilds, integration rewiring, and QA. This process routinely takes 6 to 12 months.

The mistake that recurs: teams bundle the .NET retarget into a larger replatform project, the replatform slips past November, and they end up running an unpatched runtime while waiting on a vendor decision.

**Separate the two.** Retarget to .NET 10 now to stay patched. Make the CMS platform decision on its own timeline.

## What to do before November 10, 2026

**Inventory every .NET-dependent component, then rehearse the .NET 10 move in non-production before you touch production.** Do not limit the audit to the main website project. In CMS estates, the deadline often hides in the renderer, identity service, publishing service, CLI, build agents, container base image, or scheduled-job host.

### Step 1: Audit dependencies

Run these commands against every project in the estate before any upgrade work begins:

```bash
# Identify packages with known vulnerabilities (including EOL runtime dependencies)
dotnet list package --vulnerable

# Identify packages with available updates
dotnet list package --outdated

# Confirm current target framework per project
grep -r "<TargetFramework>" --include="*.csproj"
```

### Step 2: Verify compatibility before upgrading

- **Check vendor support matrices**, not community assumptions. "Compiles on .NET 10" is not the same as "supported on .NET 10." Kentico, Optimizely, and Sitefinity all publish explicit version minimums.
- **Verify third-party NuGet dependencies** support .NET 10 before upgrading production. Use `dotnet list package --outdated` to surface packages that need updates before the TFM change.
- **Check hosting environment support.** Azure App Service supports .NET 10 on both Windows and Linux App Service plans. AWS Elastic Beanstalk supports .NET 10 via the `.NET on Linux` platform branch. If you are running containers, verify your base images reference `mcr.microsoft.com/dotnet/aspnet:10.0` or equivalent.

### Step 3: Retarget and validate

- Update `.csproj` TFM to `net10.0`.
- Run `dotnet build` and resolve compilation errors before touching runtime behavior.
- **Retarget non-production first** and validate add-ons, search, media pipelines, scheduled jobs, serialization, and deployment automation before promoting to production.
- Review the [.NET 10 breaking changes](https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-10/breaking-changes) page for any APIs your codebase uses.

### Step 4: Update infrastructure

- **Update IDEs and build agents after retargeting.** Visual Studio installer supports bulk removal of out-of-support components.
- Update CI/CD pipeline configurations (`UseDotNet@2` in Azure DevOps, `setup-dotnet` in GitHub Actions) to target the .NET 10 SDK.
- Update container base images if applicable.

### Step 5: Separate runtime work from content work

If the deadline is forcing a CMS move, content migration, media, users, redirects, and attachments should have their own validation and cutover plan independent of the runtime upgrade.

At the project-file level, the first step is simple:

```xml
<PropertyGroup>
  <TargetFramework>net10.0</TargetFramework>
</PropertyGroup>
```

The hard part is everything around that line: package compatibility, hosting bundles, vendor modules, search libraries, CI images, and rollback planning.

## The real operational deadline

**November 10, 2026 is the runtime line. December 31, 2026 may still be the CMS line for some estates.** Treat the earlier date as the real operational deadline. An unsupported .NET runtime does not kill the site on day one — it kills your patch path, and the risk compounds every month you stay there.

If your vendor already supports .NET 10 on the stack you have, use that to buy time on the CMS platform decision. If the runtime deadline exposes deeper product EOL or architecture debt, use it as the forcing function to split runtime upgrade, application modernization, and data migration into parallel tracks.

The sequencing that works: **audit in July, retarget in August–September, validate in October, deploy before November 10.** That leaves December and the first quarter of 2027 for the CMS platform decision without running an unpatched runtime.

## Frequently asked questions

### When does .NET 8 end of support?

.NET 8 reaches end of support on November 10, 2026. After that date, Microsoft stops issuing security patches, servicing updates, and technical support. The recommended upgrade target is .NET 10, an LTS release supported through November 2028.

### Does .NET 9 have a longer support window than .NET 8?

No. Despite being released a year later, .NET 9 also reaches end of support on November 10, 2026 — the same day as .NET 8. Microsoft extended STS support from 18 to 24 months in September 2025, which moved .NET 9's end date from May 12, 2026 to align with .NET 8.

### Is Optimizely CMS 12 compatible with .NET 10?

Yes. Optimizely confirmed full .NET 10 compatibility for CMS 12 in May 2026 (EPiServer.Cms.Core 12.24.0+, EPiServer.Cms.UI 12.34.4+). Commerce 14 supports .NET 10 from version 14.46.0. You can retarget CMS 12 to .NET 10 without upgrading to CMS 13.

### What happens to my CMS after .NET 8 end of support?

Your CMS application keeps running — nothing stops on November 11. What stops is security patching for the runtime. Any .NET vulnerability disclosed after that date remains open on your system. Visual Studio 2022 will also flag .NET 8 and .NET 9 components as out of support, and compliance scanners will begin raising findings.

### Do I need to replatform my CMS to address the .NET 8 deadline?

Not necessarily. Retargeting from .NET 8 to .NET 10 is a framework upgrade (project file changes, NuGet updates, breaking-change fixes) that can often complete in days. A CMS replatform is a separate, larger effort. Separate the two so the framework upgrade doesn't wait on a platform decision.