Matt Dunn
Illustration of one path splitting into three routes, each ending at a different destination

CMS 12 after 10 November: three paths and how to choose

By , Optimizely Strategy MVP · · 10 min read

Today, 10 November 2026, Microsoft ends support for .NET 8 and .NET 9.

Optimizely released CMS 12 in September 2021 on .NET 5, and it has moved up through Microsoft’s releases since. Most CMS 12 sites now run on .NET 8, which Optimizely has supported since November 2023. If your site hasn’t been updated to .NET 10, it stops getting security patches from today. With AI-driven cyber threats and new CVEs announced almost every day, it’s never been more important to keep your whole technology stack up to date.

From here you have three realistic paths: stay on CMS 12 and move to .NET 10, upgrade to CMS 13 (Optimizely’s PaaS version), or move to CMS (SaaS). I’ve compared them on cost, risk and what each one gives you, for the digital directors and product owners who have to choose one and fund it.

Path 1: stay on CMS 12 and move to .NET 10

CMS 12 officially supports .NET 10 as well as .NET 8, and has been fully compatible since May. Use EPiServer.CMS.Core 12.24.0 and EPiServer.CMS.UI 12.34.5 or later. Older CMS 12 versions do run on .NET 10, but package restore shows NuGet vulnerability warnings until you update.

If you run Commerce, Commerce Connect 14 has supported .NET 10 since August. You need EPiServer.Commerce 14.46.0 or later and, if you use Search & Navigation, EPiServer.Find.Commerce 12.3.0 or later.

Of the three paths, this one costs least: typically a few weeks, or a few months if you run Commerce, Search & Navigation or a lot of add-ons. Most of that time goes on updating packages and checking third-party add-ons.

What you get is time. .NET 10 is a long-term support release, supported until 14 November 2028, and your editors won’t see any change. It also sets the scene for what comes next. CMS 13 runs on .NET 10, so the framework move is already behind you when you upgrade, and that project can concentrate on the platform. .NET 11 arrives this month as a shorter, standard-term release. If Optimizely adds support for it, or for the next long-term release after it, a site already on .NET 10 is one small step away.

The risks sit with CMS 12 itself. It’s now the previous version, which only gets selected fixes, mostly for security. Optimizely doesn’t formally end-of-life CMS versions, but it’s planning an annual release cadence for PaaS, so CMS 14 will arrive sooner than past major versions did. New capabilities go into CMS 13, including the embedded DAM and the Agent Platform features that rely on Optimizely Graph.

Path 1 suits heavily customised sites, organisations without budget for a bigger change this financial year, and anyone already planning a move to SaaS who needs somewhere safe to stand in the meantime.

Path 2: upgrade to CMS 13

CMS 13 reached general availability on 31 March 2026 and runs on .NET 10. This is the path that gives your editors and marketers new tools.

Visual Builder replaces on-page editing as the default editing experience. It works with server-rendered MVC sites as well as headless ones, so you don’t need a new front end to use it.

The embedded DAM puts the Optimizely DAM library in the CMS side panel. CMS 12 can connect to the DAM through a picker, but in CMS 13 editors browse, filter and manage assets, folders, tags and renditions without leaving the CMS. The DAM is included with CMS 13 and CMS (SaaS). It needs Opti ID and Optimizely Graph, and it only runs in DXP, so on-premises sites can’t use it. If you want media that’s stored in the CMS moved into the DAM, plan for that separately. There’s no official tool for it, though CMS and DAM assets can sit side by side, so it doesn’t have to happen on day one. Sites already using the DAM with CMS 12 get a scheduled job, in CMS 13.3.0 and later, that migrates their asset references.

Mark, the assistant in Optimizely Agent Platform (formerly Opal), already has a chat in CMS 12. In CMS 13 it uses Graph to index, interpret and act on your content, and a set of CMS tools lets editors ask it to create and update drafts, publish pages, run SEO analysis, check pages for AI discoverability and add schema markup, manage content types and Visual Builder styles, and upload media. It can only touch content the user already has permission to change. Mark needs Opti ID, Optimizely has to provision it, and it’s paid for with credits on top of your licence.

Optimizely Graph sits underneath most of this. It’s included in the CMS 13 licence for DXP customers. CMS 13 can run without it, but Content Manager, Content Variations, the new C# SDK, external content, the embedded DAM and Mark all depend on it. If you plan to index external data, check your licence for volume limits.

An upgrade to CMS 13 takes 2 to 6 months on average, depending on how complex your implementation is. Third-party packages are the biggest single piece of work. Dynamic Properties, Mirroring and the legacy plugin system have been removed. The old migration tools are deprecated, and GitHub Copilot or a similar AI-assisted tool is now the suggested way to update your code. The database migration can’t be reversed either, so your pre-upgrade backup is your only way back.

Commerce sites have a second upgrade hiding in here. Commerce Connect 14 doesn’t work with CMS 13, so you also need Commerce Connect 15. That alone is a good reason for some commerce sites to take path 1 first.

Path 2 suits organisations that want Visual Builder, the embedded DAM and Mark’s CMS tools now, and expect to stay on a .NET platform they extend in code.

The hidden cost: Search & Navigation

This is the part most CMS 12 roadmaps underestimate. Search & Navigation (formerly Find) isn’t supported in CMS 13, so you’ll need to replace it with Optimizely Graph or your own search provider. Search & Navigation keeps working on CMS 12, and Optimizely hasn’t announced an end-of-life date for it. Customers moving to CMS 13 typically get a six-month overlap, with extensions on request.

For a brochure site with a basic search box, the move is a modest piece of work. For sites that depend on search, such as site search, filtered listings or product search, it’s often bigger than the CMS upgrade. Graph has gaps around tracking, did-you-mean, spellcheck and GDPR-related functionality, and it doesn’t yet have Search & Navigation’s admin interface or built-in analytics. A Search Management portal with analytics, pinned results and synonyms is in beta, and it needs Opti ID.

Timing matters too. Don’t move search to Graph while you’re still on CMS 12: the Graph schema is quite different in CMS 13, so you’d be rewriting the queries again after the upgrade. So I’d run search as its own workstream, in two stages:

  1. Start now, on CMS 12, whichever path you choose. Inventory every query and feature, and decide what you’ll rebuild, replace or drop.
  2. Build later, against the CMS 13 or SaaS schema. Write the new Graph queries and run old and new side by side before you switch.

Path 3: move to CMS (SaaS)

CMS (SaaS) is Optimizely’s headless, managed CMS, built around Graph and Visual Builder. Optimizely runs the platform, so you never have to plan a version upgrade again. The catch is that SaaS doesn’t allow custom code to run in the CMS process.

That makes it a rebuild. Your front end becomes a separate application that reads content through Graph, your custom .NET code has to be redesigned or retired, and your content has to be migrated. I couldn’t find an official tool for moving a CMS 12 site to SaaS, so plan it as a full project.

In return you get no more upgrade cycles, headless content for every channel, and features that reach SaaS first. The DAM is included, and some Agent Platform agents only work with SaaS. The WCAG Compliance Auditor agent, for example, requires CMS (SaaS).

Path 3 suits organisations that were already planning a front-end rebuild, have modest server-side customisation, and want to stop budgeting for platform upgrades.

How to choose

Path 1: CMS 12 on .NET 10 Path 2: CMS 13 Path 3: CMS (SaaS)
Typical effort Weeks to a few months 2–6 months on average A rebuild project
Main risk CMS 12 is now the previous version; new features go to CMS 13 Add-ons, removed features, search migration, Commerce 15 Custom code that can’t move; content migration
What you get Supported .NET until Nov 2028, and the framework ready for CMS 13 Visual Builder, plus the embedded DAM, Mark and other features built on Graph No upgrades, headless, SaaS-first features
Search & Navigation Keeps working (check your Find packages for .NET 10; Commerce sites update EPiServer.Find.Commerce) Must be replaced, usually with Graph Must be replaced, usually with Graph

There are four questions which will help most organisations choose:

  1. Do you run Commerce Connect? If you do, CMS 13 also means Commerce 15, and path 1 buys time to plan both.
  2. How much do you rely on Search & Navigation? The heavier the use, the sooner you should start planning the move to Graph, whichever path you choose.
  3. Is a front-end rebuild already on your roadmap, and is your customisation modest? If both are true, path 3 can absorb them.
  4. Do your editors and marketers need Visual Builder, the embedded DAM or Mark’s CMS tools this year? If they do, path 1 on its own won’t get you there.

My recommendation

For most CMS 12 sites I’d do two things in parallel.

First, close the security gap. Move to .NET 10 on CMS 12 now. It’s the quickest way off an unsupported framework, and it’s the first step towards CMS 13 anyway.

Second, run the bigger decision as a funded discovery rather than a rushed upgrade. Make the search inventory the first workstream, because CMS 13 and SaaS both need it.

What to do this month

  1. Update to EPiServer.CMS.Core 12.24.0 and EPiServer.CMS.UI 12.34.5 or later, and move your site to .NET 10. Commerce sites also need EPiServer.Commerce 14.46.0 or later.
  2. List your Optimizely and third-party packages, and check each one for .NET 10 and CMS 13 versions.
  3. Inventory your Search & Navigation queries and features.
  4. If you run Commerce, add Commerce 15 to the roadmap conversation now.
  5. Book a half-day with your product owner, architect and finance lead to choose a path and a budget.

Frequently Asked Questions

What is the 10 November deadline for Optimizely CMS 12?

On 10 November 2026 Microsoft ends support for .NET 8 and .NET 9. Most Optimizely CMS 12 sites run on .NET 8, so a site that hasn't moved to .NET 10 stops getting security patches that day.

Does Optimizely CMS 12 support .NET 10?

Yes. CMS 12 runs on .NET 8 or .NET 10. Use EPiServer.CMS.Core 12.24.0 and EPiServer.CMS.UI 12.34.5 or later. Commerce sites need EPiServer.Commerce 14.46.0 or later.

What does CMS 13 add that CMS 12 doesn't have?

Visual Builder as the default editing experience, the embedded DAM inside the CMS, CMS tools that let Mark from Optimizely Agent Platform (formerly Opal) act on your content, and features built on Optimizely Graph such as Content Manager and Content Variations. The DAM and Mark need Opti ID, and Mark is paid for with credits.

How long does an upgrade to CMS 13 take?

2 to 6 months on average, depending on how complex the implementation is. Third-party packages are the largest area of effort, and the database migration is not reversible.

Is Search & Navigation supported in CMS 13?

No. CMS 13 sites must replace it, usually with Optimizely Graph. Inventory your queries and features now, and build the Graph version against the CMS 13 or SaaS schema.

Which path should most CMS 12 sites take?

For most sites, move CMS 12 to .NET 10 now to close the security gap and, alongside it, run CMS 13 or SaaS as a funded discovery that starts with a search inventory.

Sources

Checked on 7 November 2026.