Optimizely CMS 13 went generally available on April 1, 2026, roughly two years after CMS 12. It is the largest single release the platform has shipped since the rebrand from Episerver — a new default editor, a new content-browsing surface, a platform jump to .NET 10, mandatory Optimizely Graph, mandatory Opti ID, and the deprecation of Search & Navigation (Find).

If you are running a CMS 12 site today, almost every layer of the stack you touch is changing. This post is the map of what changed, ordered by where it actually matters.

The Editor: Visual Builder Replaces On-Page Edit

Visual Builder is now the default editing experience. On-page edit is still reachable, but the path Optimizely wants you on is Visual Builder for pages, blocks, experiences, and media — in a single unified UI with autosave, interactive property highlighting, synchronized preview, and consolidated content creation dialogs.

What changes in practice:

  • For editors: drag-and-drop layout, real-time device preview, embedded DAM access. The learning curve is real if your editors have been on classic edit since the Episerver days.
  • For developers: Visual Builder now supports ASP.NET MVC alongside the original headless/React story. That removes the “Visual Builder is only for headless sites” caveat that held the feature back in CMS 12.
  • For component design: Visual Builder rewards small, composable blocks with well-defined editable regions. Big monolithic page templates with embedded layout logic do not translate well. If your CMS 12 site is built on a few large page types with hardcoded layout, expect to redesign the component model on the way to 13.

The MVC support in Visual Builder is the quiet headline. It means traditional render-server Optimizely sites — which are still the majority of production deployments — get the new editor without rewriting the front end.

Content Manager: Search-First, Powered by Graph

The tree view is no longer the primary content navigation surface. Content Manager is — a search-first interface backed by Optimizely Graph, with filtering by content type, status, and language.

For a site with a few hundred pages, this is a UX upgrade. For a site with 50,000+ content items, it is the difference between editors being able to find anything and editors maintaining personal spreadsheets of URL slugs to bookmark.

The architectural implication is that Optimizely Graph is no longer optional. It backs Content Manager. It also backs the JavaScript SDK, headless delivery, and most of the new search experiences. Which leads into the next change.

Optimizely Graph and Opti ID Are Now Mandatory

CMS 13 makes Optimizely Graph and Opti ID (Optimizely’s unified SSO) mandatory components included in your license. There is no “headless-only” or “no-SSO” flavor of CMS 13.

The licensing impact is mostly neutral — they are bundled — but the deployment impact is real:

  • Every CMS 13 site now ships content to Graph in addition to the local content store. Plan for the indexing pipeline, the network egress, and the eventual-consistency window.
  • Opti ID becomes the identity provider for editor logins. If you have a custom-rolled authentication setup against Active Directory or a third-party IdP, you are integrating it through Opti ID now, not bypassing it.

The Find deprecation is the other side of this coin: CMS 13 does not support Optimizely Search & Navigation. If your site uses Find for editor-facing search, marketer-facing search, or developer-facing search APIs, that all migrates to Graph. The migration is non-trivial because Find and Graph have different data models, different query languages, and different indexing semantics.

Content Variations

Content Variations let you maintain multiple published variations of the same content item in the same language. Each variation has its own version history and publishing lifecycle, and you can promote changes from a variation back to the original.

This is interesting for a few specific use cases:

  • Regional variations within a single language (US English vs. UK English on the same page)
  • Segment-targeted copy without paying for a full experimentation product
  • Staging editorial changes in parallel with live content without forking the URL

It is not a replacement for Optimizely Experimentation — there is no traffic splitting or statistical analysis. It is a content-modeling primitive, not an A/B testing tool. Treat it as “lightweight branches for a single content item” and you will use it correctly.

The Developer Surface

.NET 10 platform. CMS 13 targets .NET 10, released in November 2025. That brings the usual benefits — perf, primary constructors, collection expressions, the matured AsyncEnumerable story — and the usual cost, which is that every NuGet dependency in your codebase needs a compatible version. If you have not already moved your custom code to .NET 8 or 9, the jump is larger than it looks.

JavaScript SDK. Optimizely now ships a first-party React-ready JavaScript SDK for modeling, fetching, and rendering CMS content. This is the SDK developer teams have been building themselves on top of Graph since CMS 12 went headless-capable. Now it is supported, documented, and updated by Optimizely.

REST API. A new CMS REST API sits alongside Graph for cases where GraphQL is awkward — bulk operations, server-to-server scripting, content import/export pipelines.

DAM integration as a separate NuGet. The new DAM integration ships as EPiServer.Cms.DamIntegration.UI. Editors can browse, search, and select Optimizely DAM assets directly from within the CMS editing UI. It is opt-in: you install the package if you have DAM, you skip it if you do not.

ISR (Incremental Static Regeneration) support. Headless sites can update individual pages without rebuilding the entire static output. For sites with thousands of statically-generated pages, this collapses publish-to-live time from minutes to seconds. For traditional MVC render-server sites, ISR is irrelevant — you already had per-request rendering.

Preview for headless sites. Headless preview gets a proper first-party flow instead of the various custom shims teams have been writing.

The Breaking Changes That Will Hit Every Codebase

CMS 13 cleans up a lot of API debt accumulated since the Episerver era. The big ones:

  • PageReference → ContentReference everywhere. PageData.PageLink → ContentLink. This is a sweeping find-and-replace across most CMS 12 codebases; the surprise is how many places it touches.
  • SiteDefinition → Application Model. The flat single-site concept is replaced by a more flexible Application Model that handles multi-tenant and composable scenarios more cleanly. If your codebase reaches into SiteDefinition.Current or ISiteDefinitionRepository, those call sites need to be reworked.
  • ContentArea.FilteredItems is obsolete. Use Items and apply filtering via IEnumerable<IContentAreaItemsRenderingFilter> or the HTML/tag helpers.
  • PropertyLongString → PropertyString hierarchy change. The type hierarchy was restructured. Custom properties that inherit from PropertyLongString need attention.
  • Search & Navigation (Find) is not supported. Already mentioned, but worth repeating because it is the largest single migration vector.
  • Many previously-obsolete methods are now removed. If your codebase has been running with deprecation warnings turned off, CMS 13 is the release where those become build errors.

Optimizely’s official upgrade guidance is clear on the steps but not on the effort. From experience auditing CMS 12 codebases for the upgrade: budget roughly 1-3 sprints of dev effort for a typical mid-size site, plus separate budget for Find-to-Graph migration if it applies. Larger or more customized sites scale up from there.

AI Features (Opal)

Optimizely is positioning CMS 13 as “AI-powered” via Opal AI agents embedded into editorial workflows: copy generation, SEO optimization, content repurposing, intent-based search.

Treat this as a separate axis from the CMS upgrade itself. The AI features are useful where they are useful — editors writing draft copy, generating SEO metadata, surfacing related content. They are not the reason to upgrade. The reason to upgrade is the platform changes underneath; Opal is something you decide whether to turn on after.

Should You Upgrade

Three rough buckets:

Upgrade now, prioritize it:

  • Sites already on .NET 8+ with low Find usage and a modular component model
  • Headless or hybrid-headless sites where Visual Builder’s MVC limitations had been blocking adoption
  • Editorial teams already complaining about the tree view at scale

Plan the upgrade carefully, do not rush:

  • Sites with heavy Find customization (the Graph migration is the long pole)
  • Sites still on .NET 6 or earlier (the .NET 10 jump is its own project)
  • Sites with monolithic page templates that need component-model rework to use Visual Builder properly

Wait six months:

  • Sites on CMS 11 that have not yet upgraded to 12 — do the 11→12 step first
  • Sites in active redesign — upgrade alongside the redesign rather than as a separate project
  • Sites with bespoke editor add-ons that have not been updated by their vendors for CMS 13 yet

There is no LTS-style “we will support CMS 12 forever” branch waiting in the wings. CMS 12 is still supported, but it is the trailing platform now. The migration is when, not if.

What This Means for Optimizely Partners

For agencies and consultancies, CMS 13 is the largest billable upgrade event since 11→12. Three things to plan for:

  • Internal training. Visual Builder, Content Manager, the JS SDK, and the Application Model are all new enough that even senior CMS 12 developers need ramp-up time.
  • Updated starter kits. Whatever Alloy-derived template your firm uses for new projects, it needs a CMS 13 equivalent before you can quote new builds confidently.
  • Find-to-Graph playbooks. This will be the most common technical sticking point on upgrades for the rest of 2026. The agency that has a tested migration playbook will win the work.

CMS 13 is not a rewrite the way Episerver-to-Optimizely was a rewrite — but it is the largest API-surface change the platform has had in years, and the editor change is the most disruptive editorial UX shift since Episerver 7.5. Plan accordingly.