The runtime deadline underneath your CMS

Most content platform roadmaps track the CMS vendor's release calendar. Fewer track the runtime the CMS is built on, even though that runtime has its own support policy and its own end dates. For a large group of enterprise websites built on Microsoft .NET, one of those dates falls on 10 November 2026, and two vendor dates follow it before the end of the year.

This article sets out what the dates are, how they affect three widely used .NET content platforms, what a platform owner should check, and how to choose between the available options. It is written to remain useful whether you read it shortly before the date or some weeks after it.

Microsoft publishes a support policy for .NET that distinguishes Long Term Support (LTS) releases from Standard Term Support (STS) releases. That policy lists 10 November 2026 as the end of support for both .NET 8 (an LTS release from November 2023) and .NET 9 (an STS release from November 2024). STS releases now receive two years of support, which is why the two versions share a date. The current LTS release, .NET 10, was released in November 2025 and is supported until 14 November 2028.

Microsoft defines end of support as the date when it "no longer provides fixes, updates, or online technical assistance." The policy page goes further and states that use of out-of-support .NET versions "may put your applications, application data, and computing environment at risk."

Nothing on a website stops working on the day support ends. The application continues to run, and the immediate effect is administrative rather than technical. What changes is that any security vulnerability found in the runtime after that date will not be fixed for that version, and the organisation is now carrying that exposure on every server, container and build agent that runs it.

The runtime date matters most where the CMS itself is tied to a specific .NET version. Each vendor has published its own position, and the positions differ.

Two points stand out from the table. The first is that the .NET date and the CMS dates are close together but not identical, so a plan that addresses only one of them can leave the other open. The second is that Optimizely's public guidance has developed during 2026, which is a normal part of a vendor responding to its customers but means platform owners should confirm the current position with the vendor rather than relying on an article written earlier in the year, including this one.

The same pattern applies to platforms not listed here. Any CMS, DAM connector, search integration or custom application built on .NET 8 or .NET 9 is affected by the runtime date, even if the vendor's own product has a later end date.

The checks below are designed to produce facts rather than opinions, and each one can usually be completed by the existing platform team in a few days.

• Record the .NET version for each production, staging and development environment, including build agents, containers, scheduled jobs and serverless functions, which are often missed.
• For each platform, find the vendor's current statement of which CMS version runs on which .NET version, and note the date of that statement.
• Map the add-ons and integrations, because commerce modules, search, forms, DAM connectors and custom packages often carry their own runtime constraints. Optimizely community guidance from October 2026, for example, describes how moving a CMS 12 solution with Commerce to .NET 10 also required a newer search package and a full reindex in every environment.
• Where the platform runs on a vendor-managed cloud service, read that service's end-of-service policy, because the vendor may set its own timetable for unsupported versions. Umbraco Cloud, for example, publishes an end-of-service policy that moves projects past their extended support period to dedicated hosting for a limited time before hosting for that version ends.
• Review the obligations that reference supported software. Security policies, client contracts, cyber insurance questionnaires and penetration test scopes often require supported software, and the runtime date can turn a compliant platform into a reportable exception.

Once the facts are in hand, the choice usually falls into one of four options. They are not mutually exclusive, and a sensible plan often combines two of them in sequence.

Patch the runtime in place

Where the vendor supports the current CMS version on .NET 10, moving the runtime alone is the smallest change. It still requires dependency updates, regression testing and attention to behaviour that changes between runtime versions, such as memory management, but it does not change the editing experience or the content model.

Upgrade to the vendor's next major version

Moving to Optimizely CMS 13, Umbraco 17 or Xperience by Kentico resets both the runtime and the CMS support clock. It is a larger project, with changes to code, configuration and sometimes the editor interface, and it is the option most vendors point to as their long-term path.

Re-platform when the evidence supports it

Replacing the CMS is a significant decision that should rest on evidence about the platform's fit for the business over the next several years. A runtime date alone is rarely sufficient reason, although it can be the prompt for an assessment that reaches that conclusion on other grounds.

Use extended or managed support as a bridge

Vendor extended support, such as Umbraco's XLTS, or a managed service that takes responsibility for monitoring and compensating controls, can buy time for a planned upgrade. CMS extended support and managed-service controls do not extend Microsoft's support lifecycle for the underlying .NET runtime. We recommend treating this as a bridge with a defined end rather than as a destination, because the cost of staying on an out-of-support runtime tends to rise as time passes.

In our experience, the organisations that handle runtime deadlines calmly are those that answer three questions before choosing an option.

The first is how long the organisation intends to remain on the current platform. If the answer is several years, an upgrade to the vendor's current major version usually costs less over that period than a runtime patch followed by an upgrade later. If the platform is already scheduled for replacement within a year or so, a runtime patch or a bridge is easier to justify.

The second is what the vendor supports for this specific solution, including its modules and integrations. Vendor positions are published, but they apply to the product, and the effort sits in everything built around it. A solution with heavy customisation or several integrations will usually find that the integration work outweighs the CMS work.

The third is what the organisation's own obligations require. If a contract or a security policy requires supported software, a bridge needs to be documented and agreed with whoever owns that obligation, not assumed.

We recommend recording the answers and the chosen option in a short decision record signed off by the platform owner and the security lead. It costs little, and it is the document an auditor or a new executive will ask for.

Many organisations will read this after 10 November 2026, and some will already be running an out-of-support runtime. The steps above still apply, with a slight change of order. We recommend starting with exposure, so that internet-facing applications and anything handling personal or payment data are addressed first, and putting interim controls in place (closer monitoring, web application firewall rules, tighter access) while the chosen option is delivered. The aim is a documented plan with dates, so that the period on an unsupported runtime is a managed exception with a known end.

The Enterprise CMS Health & Value Assessment gives platform owners a fixed-scope, evidence-led view of a CMS and its integrations, including runtime and version exposure, and produces a traffic-light scorecard and a roadmap of what to address now and what to plan next. Where the question is whether to stay on the current platform at all, the DXP Future State Assessment covers current-state platforms, target architecture and a controlled roadmap. Both are platform-agnostic and led by senior TBSCG consultants, and either may conclude that the right course is to wait. Our team is available to discuss which fits your situation.

• Microsoft, ".NET and .NET Core Support Policy."
• Optimizely, "FAQs for CMS 13."
• Bien Nguyen, "Optimizely CMS 12 now fully supports .NET 10," Optimizely World, May 25, 2026.
• Kenny Gutierrez, "So you've decided to move to .NET 10 but stay on CMS 12," Optimizely World, October 2, 2026.
• Umbraco, "Umbraco 13 End of Life (EOL)."
• Umbraco, "Long-term support and End-of-Life."
• Umbraco documentation, "Requirements" (Umbraco 13).
• Umbraco Cloud documentation, "End-of-Service Policy."
• Kentico, "Product Support Lifecycle Policy."
• Kentico DevNet, "Kentico Xperience 13 Refresh 11: Bye bye jQuery, hello .NET 8," 7 December 2023.