.NET 8 Support Ends November 10, and Umbraco 13 Follows on December 14

Microsoft’s .NET 8 support ends on November 10, 2026, and .NET 9 ends the same day. Five weeks later, on December 14, Umbraco 13 reaches end of life. Umbraco 13 is the long-term support release that runs on .NET 8, so an Umbraco 13 site loses both layers of patching before the year ends.

This piece walks through what ends and when, what losing .NET 8 support means for patches, which versions to move to, and how the Umbraco 13 to 17 upgrade works. It also covers the Azure Functions in-process model and PowerShell 7.4, which end on the same November date. It closes with a plan for small organizations whose website or AMS integration runs on .NET.

The short version: before .NET 8 support ends, move .NET apps to .NET 10, the current LTS release, supported to November 14, 2028. Move Umbraco 13 sites to Umbraco 17 LTS, or buy extended support as a bridge. Move Azure Functions to the isolated worker model. If none of that has started by late October, the realistic goal is a decision and a dated plan, not a finished upgrade.

Everything that ends on November 10 and December 14

The Microsoft lifecycle page for 2026 lists .NET 8, PowerShell 7.4 and the Azure Functions in-process model under November 10. The table below adds the other dates that matter to web teams.

The .NET dates come from the .NET support policy, last updated September 8, 2026. Microsoft’s product lifecycle listing shows November 11 for the same releases, likely a time zone display difference. We use the support policy date.

The same quarter carries other Microsoft dates. Office 2021 ended on October 13, as we covered in our Office 2021 end of support post. For the full quarter across CMS, PHP and browsers, see the Q4 2026 platform calendar.

What the end of .NET 8 support means for patches

The support policy defines end of life plainly. It is "the date when Microsoft no longer provides fixes, updates, or online technical assistance." Once .NET 8 support ends, a vulnerability found in .NET 8 or ASP.NET Core 8 stays unfixed.

Apps do not stop running when .NET 8 support ends. A .NET 8 site will serve pages on November 11 the same way it did the day before. The risk grows over time, as new vulnerabilities are disclosed and no patches follow.

Microsoft ships .NET updates on Patch Tuesday, the second Tuesday of each month. November 10 is itself a Patch Tuesday, so a final .NET 8 update may ship that day. The policy is careful here: there is "no guarantee that there will be a .NET release on any given Patch Tuesday." As of September 2026, the latest .NET 8 patch was 8.0.31, released September 8.

Hosting behaves the same way. Azure App Service’s language runtime support policy says apps on an ended runtime "continue to run unchanged." It also says App Service "can’t provide security patches or related customer support for that runtime version." To get App Service support again, you must upgrade the app to a supported version.

Why .NET 9 ends the same day as .NET 8

This surprises people. .NET 9 shipped a year after .NET 8, yet .NET 9 and .NET 8 support both end on November 10.

The reason is the support policy. LTS releases get three years from release. STS releases get "one year after a subsequent release," which works out to two years because Microsoft ships every 12 months. .NET 8 arrived in November 2023 and .NET 9 in November 2024, so both land on the same date.

Teams that moved to .NET 9 to stay current gained nothing on the calendar. They face the same upgrade on the same deadline.

Move to .NET 10 LTS, not .NET 11

.NET 10 is the current LTS release. It shipped November 11, 2025, and is supported until November 14, 2028. It is the target for nearly every web app, integration and function that runs on .NET 8 today.

.NET 11 is close. The support policy lists .NET 11 RC1 as a go-live release dated September 8, 2026, with a final release expected in November under the annual cadence. For most small teams that is not a reason to wait. Our read: land on .NET 10 now and take the next upgrade on a normal schedule. Chasing a release that has not shipped adds risk to a deadline project.

Two Microsoft resources help scope the work:

• Breaking changes in .NET 10: the compatibility list covers ASP.NET Core, Entity Framework Core, the SDK and containers. One example: default .NET container images now use Ubuntu.
• Upgrade tooling: Microsoft’s documentation marks .NET Upgrade Assistant as deprecated. It points to the GitHub Copilot modernization chat agent in Visual Studio 2026 and Visual Studio 2022 17.14.16 or later.

For a typical ASP.NET Core app, the core change is small. You change the target framework from net8.0 to net10.0, update Microsoft packages to their 10.x versions, and fix what the build reports. The testing, not the edit, takes the time.

Umbraco 13 end of life on December 14

Umbraco 13 shipped December 14, 2023, as an LTS release. Its full support phase ended December 14, 2025, and it has received security fixes only since then. On December 14, 2026, those stop too.

The Umbraco 13 end of life page says the version "will no longer receive updates or support from Umbraco HQ," including "critical security patches and technical support." Sites keep running, but Umbraco advises against staying.

Umbraco lists three paths:

• Upgrade to Umbraco 17 LTS or later.
• Rebuild on Umbraco 17 LTS or later, optionally on Umbraco Cloud.
• Buy Extended Long-Term Support (XLTS) for 6, 12 or 24 months of security patches past the end of life date. Umbraco does not publish XLTS pricing on the page.

For Umbraco Cloud projects on version 13, the same page lists a longer tail. XLTS ends December 14, 2028. Projects then move to dedicated hosting, and hosting ends December 14, 2029. Cloud customers should confirm what applies to their plan with Umbraco.

The five weeks between November 10 and December 14

Here is the uncomfortable overlap. Umbraco’s version 13 documentation says the release "is based on .NET 8." From November 10, Microsoft stops patching that runtime. Umbraco still supports version 13 until December 14.

So an Umbraco 13 site spends five weeks without .NET 8 support while the CMS itself is still in support. The version 13 requirements page lists ".NET 8.0 and higher," but we found no Umbraco documentation that supports running version 13 on .NET 10. Treat that as untested unless Umbraco says otherwise.

In practice, apply the last .NET 8 patch Microsoft ships, and keep the upgrade plan moving. Without .NET 8 support underneath it, the CMS support window alone does not keep the site current.

The Umbraco 13 to 17 upgrade path

Umbraco 17 is the target. It shipped November 27, 2025, as an LTS release, and is supported until November 27, 2028. The Umbraco support timeline describes it as the LTS "supporting .NET 10 LTS."

Umbraco 18 is also out, with 18.2.0 released September 17, 2026. It is a standard-term release, as is Umbraco 19, scheduled for December 10. The next LTS on Umbraco’s calendar is version 21, in December 2027. For a client site that should sit still for two years, 17 is the choice.

Umbraco’s June 2026 post, Going from Umbraco 13 to 17, describes two routes:

• In-place upgrade: upgrade the existing solution and run the required migrations.
• Fresh build: start a new Umbraco 17 solution and move content and schema with Umbraco Deploy import and export.

The post says both routes work. The right one depends on how much legacy code the site carries and whether the project is also a redesign.

What breaks between Umbraco 13 and 17

The effort sits in version 14, which Umbraco 17 inherits. Umbraco’s version-specific upgrade notes list the changes that hit real sites:

• New backoffice: AngularJS is gone. The editor interface is rebuilt with Web Components and Lit, so custom backoffice extensions need rewriting.
• Macros removed: macros and partial view macros are gone. Umbraco points to partial views and blocks in the Rich Text Editor.
• Nested Content and Grid Layout removed: Block Grid replaces Grid Layout. Block List or Block Grid replaces Nested Content.
• Legacy media picker removed.
• Packages: any AngularJS-based package needs a version built for the new backoffice, or a replacement.

Content on Grid Layout or Nested Content needs data migration, not just a code change. That is the part to scope first, because it drives the estimate.

Hosting implications for Umbraco 17

The Umbraco 17 requirements set the hosting baseline:

• Runtime: .NET 10.0 or higher on the server.
• Database: SQL Server 2016 or later, with a case-insensitive collation, or SQLite.
• Servers: Windows with IIS (with the WebSocket Protocol feature for SignalR), or supported Ubuntu versions on Linux.
• Tooling: the requirements list Node.js 24.11.1 or higher.

For a self-hosted IIS server, the practical step is installing the .NET 10 runtime alongside .NET 8 before cutover. Check that your SQL Server version is still in Microsoft support, since Umbraco aligns its database support with Microsoft’s. On a shared or managed host, ask whether .NET 10 is available on your plan today.

Move Azure Functions to the isolated worker model

Losing .NET 8 support reaches beyond websites. Many small integrations live in Azure Functions: a nightly member sync, a payment webhook, a form handler that writes to the AMS. If those functions use the in-process model, support for that model ends November 10.

Microsoft’s migration guide, updated September 16, 2026, recommends the isolated worker model on .NET 10. The main changes:

• Project file: target `net10.0` and replace `Microsoft.NET.Sdk.Functions` with the `Microsoft.Azure.Functions.Worker` packages.
• Startup: add a `Program.cs` that builds the host. It replaces any `FunctionsStartup` class.
• Bindings: swap `Microsoft.Azure.WebJobs` packages for their Worker equivalents. Input and output binding names change.
• Setting: set `FUNCTIONS_WORKER_RUNTIME` to `dotnet-isolated`.

Microsoft recommends deploying through a staging slot, testing there and then swapping to production. That avoids runtime mismatch errors during the cutover.

PowerShell 7.4 and the scripts nobody owns

PowerShell 7.4 LTS ends November 10, and so does PowerShell 7.5. The PowerShell lifecycle page lists PowerShell 7.6 LTS as the replacement, supported to November 14, 2028. Microsoft notes PowerShell follows the lifecycle of the .NET version it is built on.

This matters for the scheduled task on a server that exports members every night. Find those scripts, install 7.6, and test them.

A .NET 8 support plan for small organizations

Most nonprofits and associations do not have a .NET team. They have a website, an AMS integration someone built years ago, and a vendor. Here is a plan that fits that reality.

1. Inventory by the end of October. List every site, integration, function and script. Check each project file for `net8.0` or `net9.0`, or run `dotnet –list-runtimes` on each server. Confirm the list by checking that every item has a named owner.
2. Separate .NET from .NET Framework. Older integrations often run on .NET Framework 4.8, which follows a different lifecycle and is not part of the November 10 date. Confirm which one each item uses.
3. Ask vendors in writing. For hosted AMS connectors, SSO bridges and plugins, ask which .NET version they run and when they move to .NET 10. Record the answer and date.
4. Rank by exposure. Public websites and anything that handles payments or logins go first. Internal reports can follow.
5. Upgrade to .NET 10 in staging. Test logins, forms, payments and scheduled jobs before production. Confirm each one against a known-good record.
6. Decide on Umbraco 13 by mid-November. Pick upgrade, rebuild or XLTS. If the upgrade cannot finish by December 14, buy XLTS as a bridge and date the upgrade.

Budget conversations go faster when the date is not in question. The .NET 8 support end date is published and fixed. Only the plan is open.

The same logic applies to other platforms this year. Drupal 10 ends December 9, covered in our Drupal 10 end of life guide. Joomla 5 stopped getting bug fixes on October 13, as our Joomla 5 post explains.

Frequently Asked Questions