FAQs for CMS v13.0.0

This document consolidates and deduplicates questions from pre-submitted forms, live Q&A, and chat during the Content Management System (CMS 13) Technical Webinar. Questions have been lightly edited for clarity and consistent tone while preserving their original intent.

What is CMS 13 and what are its key capabilities?

CMS 13 is the next major version of Optimizely's content management system, designed to help marketing and digital teams create, manage, and optimize content using AI-driven workflows and a modern content architecture.

Key capabilities include: Opal AI agents for content creation, optimization, and governance; Optimizely Graph for unified content retrieval and semantic search; Visual Builder for page creation and preview; Embedded DAM for asset management; and External Content to connect third-party systems.

What is the value proposition of CMS 13?

CMS 13 helps teams move faster with AI-assisted workflows and built-in content creation tools while maintaining quality and governance. It enables organizations to build on any frontend architecture, produce content faster with AI agents, create and personalize pages without developer dependency, connect content and data across systems, and improve discoverability across search and AI-driven channels.

Is CMS 13 a PaaS or SaaS product? How does it differ from CMS SaaS?

CMS 13 is the PaaS version of Optimizely's CMS. PaaS allows full control of the application, custom code in the process, and deployment flexibility. With SaaS, Optimizely manages all of that. The SaaS model does not allow custom code running in the process. Optimizely refers to its SaaS offering as "CMS SaaS."

When was CMS 13 available?

CMS 13 reached general availability on March 31, 2026.

Which customers are the best fit for CMS 13?

CMS 13 best suits organizations that manage large volumes of content, need faster publishing workflows, want to adopt AI-driven content creation, operate across multiple systems and channels, and require scalable infrastructure for global experiences.

What does CMS 13 not replace?

CMS 13 focuses on modernizing the CMS platform. It does not replace external analytics or experimentation platforms, specialized third-party search platforms, or dedicated SEO/GEO platforms. These can still be integrated through APIs and connectors.

What are the major selling points for upgrading from CMS 12 to CMS 13, particularly for clients not using Opal or Graph?

CMS 13 is an opinionated move toward a Graph-first, headless-capable platform. Graph is now mandatory and included in the license. Many headline features such as Content Manager, Content Variations, and the new C# SDK depend on it.

That said, the upgrade still delivers meaningful improvements. Visual Builder replaces on-page edit as a modern, unified editing experience that works with server-side MVC rendering without requiring Graph. The move to .NET 10 ensures long-term Microsoft support. Editors benefit from auto-translation with structure preservation, content templates and blueprints. Developers get a full REST API included by default and a cleaner multi-site management model through the new Applications concept. There are also security hardening improvements around file uploads and user management.

For clients not planning to adopt Graph, the upgrade is more about future-proofing and editorial quality-of-life than unlocking transformative new capabilities. The biggest features remain on the table until Graph is embraced.

What .NET version does CMS 13 require?

CMS 13 requires .NET 10.

What is the .NET support strategy for CMS 12, especially given that .NET 8 reaches end of support in November 2026? Will CMS 12 officially support .NET 10?

CMS 13 is built on .NET 10 (LTS). While CMS 12 supports .NET 8, moving to CMS 13 is the required upgrade path for teams looking to utilize .NET 10 and ensure their platform remains on a supported framework after .NET 8 reaches end-of-support in November 2026. CMS 12 will not officially support .NET 10.

Are there plans for .NET 11 support for CMS 13?

.NET 11 is expected to be released in November 2026 and is a Standard Term Support (STS) release. No specific announcement has been made regarding CMS 13 and .NET 11 support.

Will Dojo widgets continue to work without changes in CMS 13?

Existing Dojo property editors work in CMS 13. CMS 13 also introduces ES6 module-based custom property editors — a plain JavaScript function with no Dojo mixins or Dojo dependencies required. React, TypeScript, Vite, and Storybook are all supported for building custom editors. See Custom property editors in Optimizely CMS 13.

Are Razor pages and Blazor supported in CMS 13?

Razor pages are already supported in CMS 12 and continue to be supported. Razor components do not yet have first-class support. Blazor is not officially supported but is not discouraged either.

Are there plans to support Razor components (.razor) with tag helper equivalents?

There are no current plans to provide direct TagHelper equivalents for Razor components (.razor) within the traditional MVC framework. While Optimizely remains fully committed to supporting MVC and Razor for existing implementations, our engineering focus for CMS 13 is on enabling a more flexible, decoupled architecture.

Does the standard MVC implementation pattern remain supported in CMS 13?

Yes. MVC remains fully supported in CMS 13. There are no plans to drop MVC or Razor support. Tag helpers and HTML helpers are available for rendering Experiences and DAM integrations.

Is Optimizely Graph required for CMS 13?

Graph is strongly recommended and positioned as required from a sales perspective. The CMS can run without Graph, but key capabilities are unavailable, and functionality is significantly limited.

Is switching from Search & Navigation to Graph mandatory when upgrading to CMS 13?

Yes. Search & Navigation is not supported in CMS 13. Switching to Optimizely Graph is mandatory.

Is there a formal end-of-life date for Search & Navigation?

No formal end-of-life has been announced. Customers migrating to CMS 13 will typically have a 6-month overlap period, with extensions available on request.

Does switching to Graph require rebuilding the frontend?

No. CMS 13 supports .NET MVC, headless, hybrid, and mixed architectures. Graph replaces Search & Navigation for content retrieval while frontend flexibility is preserved.

What is involved in migrating from Search & Navigation to Graph?

A new .NET SDK aligned with the Find API simplifies migration. A full content sync can be triggered during deployment. A migration guide will be available at the launch. See the early access preview docs: https://docs.developers.optimizely.com/content-management-system/v13.0.0-CMS/docs/migrate-from-search-navigation-early-access-preview

Do you recommend moving to Graph in CMS 12 before upgrading, or waiting until CMS 13?

Waiting until CMS 13 is recommended. The Graph schema format is quite different between CMS 12 and CMS 13, so the benefits of migrating to Graph in CMS 12 are likely not worth the additional effort.

What is the upgrade effort if a site already uses Graph in CMS 12?

On the query side, it mainly involves adjusting queries — built-in metadata is now clearly separated from partner-defined data. On the server side, the new implementation is not based on Content Delivery API, so server-side extensions are not directly portable. The effort depends on the types of customizations in place.

How does the Graph schema in CMS 13 align with CMS SaaS? Are there differences?

In CMS 13, the Graph schema aligns more closely with SaaS. Built-in metadata is clearly separated from partner-defined properties, allowing both Optimizely and partners to evolve schemas over time without breaking each other. The REST API format and payload is consistent between SaaS and CMS 13.

What is the status of Search & Navigation features (synonyms, best bets, autocomplete, spellcheck) in Graph?

The Graph Search UI will be in beta at the time of the CMS 13 launch, including synonym management, best bet setup, and most analytics. Additional features are planned for Q2. Note: tracking, did-you-mean, spellcheck, and GDPR-related functionality are current gaps — check migration documentation for workarounds.

Will Graph support all CMS features like localization, translation, and personalization?

Yes. Optimizely Graph is designed to be a unified reflection of your content model and fully supports core platform capabilities such as localization and translation. Because Graph mirrors the CMS structure, localized content is indexed and remains retrievable based on the language settings defined within the system.

What happened to FilterForVisitor() in CMS 13?

FilterForVisitor is still available and works as expected in CMS 13, no changes were made to its API or behavior.

However, the underlying FilterAccess.QueryDistinctAccessEdit() methods that support content access checking were marked as obsolete in CMS 13. If you're using FilterAccess directly in your code, you may see deprecation warnings. The recommended replacement is IContentAccessEvaluator.HasAccess(), which provides the same access-checking functionality through a more modern, dependency-injection-friendly interface. The obsolete FilterAccess methods are scheduled for removal in a future major version.

Now that FilteredItems is gone for ContentArea, what is the best migration approach from CMS 12 to CMS 13?

In CMS 12, ContentArea.FilteredItems automatically filtered content area items by publish status, user permissions, and visitor group personalization. In CMS 13, this property is obsolete and will be removed in CMS 14. The reason is that ContentArea was hiding a ServiceLocator dependency rather than being a data class.

The migration approach depends on how you use it:

If you render content areas using HTML helpers or tag helpers, then no action is needed. The ContentAreaRenderer pipeline already applies filtering automatically during rendering, just as it did in CMS 12.

If you called FilteredItems directly in code, for example to count visible items or check whether a content area appears empty for a visitor, you should inject IEnumerable<IContentAreaItemsRenderingFilter> and apply the filters to contentArea.Items yourself. The built-in implementations ContentAreaItemAccessFilter (permissions) and VisitorGroupContentAreaItemsFilter (personalization) cover the same logic that FilteredItems handled. You can also register custom implementations of IContentAreaItemsRenderingFilter for additional filtering.

If you just need all items without filtering, use contentArea.Items directly.

What is the strategy for the Optimizely Graph .NET client package? The Optimizely.Graph.Client is deprecated, and there are new packages like Optimizely.Graph.Cms and Optimizely.Graph.Core. Can these be used for external data sources or .NET APIs hosted separately?

The strategy focuses on providing a more modern and flexible developer experience. While the older Optimizely.Graph.Client has been deprecated, it is replaced by the newer Optimizely.Graph.Cms and Optimizely.Graph.Query packages. These new packages are designed to allow for querying and indexing in a more flexible way. Specifically, they are intended to support integrations beyond just the core CMS, including external data sources and .NET APIs hosted separately within the DXP environment. Additionally, a new .NET SDK—designed to align more closely with the Search & Navigation (Find) API to simplify migrations—is currently in progress.

How can external data be easily indexed in Graph, and is it covered under the standard license?

External data can be indexed using the new .NET packages, such as Optimizely.Graph.Cms and Optimizely.Graph.Core, which are designed to allow querying and indexing of external data sources and separate .NET APIs in a flexible way. Regarding licensing, Optimizely Graph is included as a core capability of the CMS 13 offering for DXP customers. While it is designed to act as a unified reflection of your content model, you should consult your specific license agreement or account manager to confirm the volume and usage limits for third-party external data indexing under your standard package.

What is the best practice for enriching schema and data pushed into Graph?

The initial release of CMS 13 does not include any extension capabilities. In an upcoming minor release, we will include the capability to provide data for content type base types. These base types are usually used by add-on implementers and should not be used to extend existing types in the schema. We will also release indexing conventions, similar to the conventions in CMS 12. These conventions will let you exclude types and include computed properties on existing types. Instead of providing conventions to include .NET base types, we rely on contracts. Contracts, also known as abstract content types; are indexed automatically. We will also provide an abstraction to do conversions for custom property data types. @JohanP

Will Graph schema generation be possible locally from code before deploying or syncing content type changes?

The CMS handles Graph schema generation from Content Types automatically. Extension points exist (e.g., custom properties), but the schema is more restricted than in CMS 12 — built-in schemas cannot be changed, only extended. The conventions API (for computed properties) will be released in a minor release shortly after the initial launch.

Will developer Graph indexes be available for local development (similar to Search & Navigation developer indexes)?

Yes. Developer indexes will be available. Documentation will be provided. A self-service portal for short-lived developer indexes is under consideration; no confirmed timeline.

Will there be a Graph-compatible service running as a Docker container for local development or on-prem hosted solutions?

This is currently being investigated as part of the longer-term developer experience roadmap. While a cloud-connected index is presently required for Optimizely Graph, the product team is exploring the possibility of a Graph-compatible service that could run in a Docker container to support local development workflows and provide a solution for on-premise hosted environments.

Will GraphQL search include document indexing for PDFs?

Text is extracted from most document types and made searchable.

Will Graph leverage Virtual Roles the same way the Content Delivery API does?

Virtual roles marked as "Available as permission role" are included in Graph. Note that the evaluation of virtual roles is dependent on the context. For example, some criteria only work when they're evaluated in the same process as the CMS and do not work when the frontend is hosted outside the process.

Is Visual Builder available for PaaS (CMS 13) or only SaaS?

Visual Builder is available in both SaaS and PaaS (CMS 13).

Can existing CMS 12 pages and blocks be used in Visual Builder?

Yes. Visual Builder supports existing pages and blocks from CMS 12. Shared blocks cannot be used as elements within sections (though support for this is planned). Reviewing content modeling for CMS 13 is recommended to get the most out of Visual Builder.

VB basically does not support Forms and Language Manager.

Can the CMS 12 page/block architecture be combined with Visual Builder Experiences in CMS 13?

Yes. A mix of traditional Pages/Blocks and new Experiences/Sections is supported. Static properties can also be added to Experiences.

Except for Forms and LanguageManager.

What is the row/column structure in Visual Builder, and is it mandatory?

Rows and columns are a logical grouping within Visual Builder (Sections/Rows/Columns/Elements). They do not need to be rendered as rows and columns in the actual frontend — that is up to the implementation. Shared blocks can also be used at the section or element level.

Do Elements within Columns support ContentArea, or only ContentReference?

Elements inside Columns do not support ContentArea; ContentReference should be used. This matches the same content modeling rules in CMS SaaS.

Is On-Page Editing (OPE) supported in CMS 13?

Yes, as a configurable option. Documentation will be available at launch.

How does On-Page Editing work in CMS 13 for decoupled/headless implementations?

In CMS 13, On-Page Editing for decoupled or headless implementations is primarily powered by the new Visual Builder. It features a split-view interface where the left side serves as the editing pane and the right side provides a live preview of the content.

Key technical aspects include:

How much of experience pages can be read or updated using IContentLoader/IContentRepository?

The IContentLoader and IContentRepository fully support working with experiences.

How do Visitor Groups and Audiences work in CMS 13?

Visitor Groups and Audiences work in MVC-based implementations. They are not indexed to Graph, so for Graph-based delivery, the recommendation is to use the new Variations support for content and Experimentation for personalization. Deeper CMS/Experimentation integration is on the roadmap.

Will Experimentation and Personalization be more closely embedded into the CMS platform in CMS 13?

Yes. In CMS 13, AI-driven capabilities through Opal are more deeply embedded into the core experience than in previous versions. This integration allows for out-of-the-box tools and agents that assist with the creation, management, and optimization of content.

A critical component of this strategy is Optimizely Graph, which is now a required technology for CMS 13. Graph enables advanced personalization and semantic search by allowing the system to query content dynamically based on specific user contexts. This architecture ensures that personalized and optimized experiences can be delivered across any channel while maintaining high performance.

Will Experimentation and Personalization be more closely embedded into the CMS platform in CMS 13? (alternate)

We have no plans to announce for CMS 13 on this topic.

Is Opti ID required for CMS 13?

Opti ID is required to unlock AI capabilities (Opal) and certain platform features such as the Embedded DAM. It is only available in SaaS and DXP environments.

Is Opti ID mandatory for CMS 13 editors in PaaS?

Opti ID is required for accessing CMS-level features like Opal and DAM. For a more detailed breakdown of which editor flows require Opti ID vs. traditional login, please refer to the launch documentation.

What are the actual hard requirements for Opti ID? Can it be configured alongside traditional login methods?

Opti ID is intended for business users (editors and admins) who access the CMS. For end users and site visitors, any authentication scheme can be used. Opti ID is only available in DXP (not on-prem or self-hosted Azure).

We use Okta across our company for SSO, including the CMS. How would we manage that with Opti ID?

I'd like the Opti ID team to verify, but my layman's answer is that this should be handled by configuring Okta as an Identity Provider for Opti ID (Option 3): Get started with Opti ID – Support Help Center

They should first decide if they want to implement SSO with or without SCIM, then follow the relevant instructions for configuring with Okta as their IdP.

https://support.optimizely.com/hc/en-us/articles/44424935212941-Configure-Opti-ID-for-CMS-13https://support.optimizely.com/hc/en-us/articles/44424935212941-Configure-Opti-ID-for-CMS-13

We plan to allow customers to authenticate via our own B2C system for seamless passthrough to non-Optimizely systems. How does this interact with Opti ID requirements?

Opti ID is only for business users accessing the CMS. B2C authentication for public-facing site visitors is independent and fully supported alongside Opti ID for editors.

How will Opti ID work with multi-site setups in local development? The limited callback URLs in CMS 12 significantly limit local multi-site testing.

Plans exist for a self-service portal where redirect URIs can be managed by teams. No confirmed timeline has been announced.

Will Opti ID offer better integration with Microsoft Entra ID in the future?

This depends on what specific functionality is missing. If there is a specific integration gap, submitting that feedback through official channels is recommended.

Does CMS 13 enforce idle session timeouts and prevent multiple concurrent sessions (issues observed in CMS 12)?

Opti ID configuration can be adjusted to control session behavior, including idle timeouts. Default settings are configured and changing them is not recommended without specific need.

Is the Embedded DAM available for PaaS (DXP) customers?

Yes. The Embedded DAM is available for all CMS 13 DXP customers and requires Opti ID.

Can the DAM be activated for any DXP customer without additional cost?

DAM is included with CMS SaaS and CMS 13.

Is the DAM a cloud-only service, or can it be hosted on-prem?

DAM is a cloud service that requires Opti ID. Since Opti ID is not available on-prem, DAM is not available for on-prem customers.

Does the Embedded DAM replace the modal popup present in the CMS 12 DAM integration?

The Content Manager picker will eventually replace the old modal popup. In the initial CMS 13 release, the DAM library picker remains available as an option.

When using DAM, can the old media library be disabled?

Plans exist to fully disable the old media library, but this is not yet possible in CMS 13.0. CMS assets and DAM assets can coexist in the meantime.

Are there migration scripts or tooling to migrate blob storage assets from CMS to the DAM?

No official Optimizely migration tooling is planned at this stage. Migration is possible but non-trivial — all asset references must be updated. Third-party tools such as the Proxima DAM Migration Tool (from Epinova) are available. CMS assets and DAM assets can coexist, so a migration is not required upfront.

Will the DAM support consuming images through Cloudflare image resizing functionality?

The DAM product follows its own roadmap, and this is an area the team is actively exploring.

Will there be support to restrict DAM/CMP assets by user role or Visitor Groups?

Content types related to external content (including DAM and OCP) are public and visible to everyone in the initial CMS 13 release. Role-based restriction for DAM assets is not supported at launch.

Will DAM allow custom properties or additional metadata on assets?

In CMS 12, the DAM integration pulled asset metadata from CMP and stored it in a persistent cache within CMS. This reduced repeated lookups to CMP and improved performance.

In CMS 13, the DAM integration is built on Optimizely Graph, which serves as both the indexing and delivery layer for DAM assets. Asset metadata, including tags, labels, and custom fields defined in DAM, are indexed into Optimizely Graph and can be queried and used directly in content delivery.

Will Opal work with PaaS (CMS 13)?

Yes. Opal will be available in CMS 13 PaaS with a range of out-of-the-box agents as well as the tools, equivalent to what's already available in SaaS CMS.

Is Opal available for on-prem customers?

No. Opal requires Opti ID, which is not supported on-prem.

Will it be possible to publish content directly from Opal in CMS 13?

Yes. An Opal Tool can connect through the CMS API to create and edit content, enabling publishing directly from Opal.

Is there an additional cost for Opal in CMS 13, and do all CMS 13 customers get it automatically?

Opal carries additional cost via Opal credits. Opal credit packages are available, and these should be discussed with your Customer Success Manager (CSM). Opal is not installed automatically; it must be provisioned by Optimizely, and the supporting Nuget package must be installed for Opal Chat. Opal Chat will be released for CMS13 soon.

Can an AI chatbot be built using Opal AI Agents that answers user questions based on website content?

For use within Optimizely CMS (user interface): Yes, OpalChat is already available for CMS12, CMS13 and SaaS CMS:

https://nuget.optimizely.com/packages/Optimizely.Cms.OpalChat/

For use as a website chatbot for end customers to search for products/content (i.e. frontend chatbot):

No, Opal does not currently support this use case.

How does Opal handle multi-brand governance within a shared agent workflow?

Opal agents are configurable to users' needs and a combination of prompt engineering alongside Opal instructions can be used to provide brand governance in agent workflows.

Is the AI/agentic direction in CMS 13 baked into the platform or an optional add-on layer?

Opal is optional, it must be provisioned and installed for access within PaaS CMS.

Will Opal have data residency options, and can clients opt out of Opal?

The Opal application data residency is currently US-based but will also offer EU soon.

Opal is opt-in rather than opt-out. Opal will not appear if not provisioned. When installed, customers can disable Opal at any time via a simple toggle, and can designate access per individual user.

If sensitive data is involved, are there guarantees that Opal will not store or train on that data?

Any data you put into Opal stays private to your organization. Google Cloud (our underlying Opal LLM provider) does not utilize customer inputs or the LLM output for its LLM training purposes. Your data, including your Opal input and the Opal output, are not used by Optimizely to train, develop, or improve any GenAI features. All processing happens within Google Cloud, using secure, enterprise infrastructure. Customer data is protected with robust controls that minimize exposure only to provide services as contracted to you, our customer.

Refer to the latest Services Descriptions for the Optimizely Software Service for more details: https://world.optimizely.com/services/descriptions/

Will there be an MCP server for CMS, Graph, and CMP for integration into developer tools like Cursor or Claude Code?

Yes. An MCP server can be used by any LLM and client. A CMS MCP server has been confirmed.

What is the recommended upgrade path from CMS 12 to CMS 13?

The general steps are: (1) Configure Opti ID, (2) Enable Graph, (3) Update content models if using Visual Builder, (4) Migrate media assets if using Embedded DAM. Detailed documentation will be published at launch. Upgrade timing depends on implementation complexity — estimates range from 2 to 6 months on average.

What are the most common breaking changes when upgrading to CMS 13, and what remediation steps does Optimizely recommend?

CMS 13 is a recent release, and it remains to be seen which breaking changes will cause the most friction in practice. For the full list of breaking changes and detailed migration guidance, refer to our breaking changes documentation.

Which authentication and integration components require mandatory updates or replacement when moving to CMS 13? Is Opti ID mandatory?

Opti ID is required to enable AI capabilities and DAM. Search & Navigation must be replaced by Optimizely Graph. Other specific components will be documented in the migration guide at launch.

Are there recommended tools or automated approaches for refactoring deprecated APIs and legacy initialization/configuration code?

Migration tooling is being explored. AI-assisted migration tools are also under investigation. No specific tool has been announced for the initial launch.

Is a direct upgrade from CMS 11 to CMS 13 supported, or is going through CMS 12 recommended?

A direct upgrade from CMS 11 to CMS 13 is technically supported. The level of effort is similar to upgrading 11 to 12, as the majority of work involves upgrading the .NET framework. For highly customized solutions, breaking the upgrade into smaller steps may still be advisable.

Is a project migration process available in the PaaS Portal (similar to the CMS 11-to-12 migration)?

Documentation for migration via the PaaS Portal — including project migration steps — will be published alongside the CMS 13 release.

Can a CMS 12 instance run in parallel with a CMS 13 instance during migration?

Yes, refer to Project migration for CMS 12 with Optimizely Graph

What changes can be made in CMS 12 now to prepare for a future CMS 13 upgrade?

Switching from Search & Find to GraphQL is a recommended preparatory step. Adopting Opti ID while still on CMS 12 is also beneficial. Full guidance will be published at launch.

For agencies currently delivering CMS 12 projects, what is the realistic minimum-effort path to CMS 13, and are there any gotchas beyond the documented breaking changes?

We are actively monitoring early upgrades to CMS 13 and will continue to update our documentation as we learn which areas require additional guidance. The full list of breaking changes is documented and being made publicly available.

When will CMS 12 reach end of life (EOL)?

Optimizely fully supports the current major version and backports select fixes, primarily security-related, to the previous version. We provide a documented upgrade path to help customers migrate between major versions. We do not formally end-of-life CMS versions, but we encourage customers to stay current to benefit from the latest features, fixes, and security updates.

Will the Episerver Foundation template be updated for CMS 13?

Foundation (https://github.com/episerver/Foundation) is a reference implementation that demonstrates what a CMS solution can look like. It will be updated to CMS 13 by Optimizely Solution Architects in the near future.

What is the upgrade path for clients who are still on-prem? Will there be official documentation on which CMS 13 features are unavailable for on-prem customers?

The documentation will contain references to dependencies like Opti ID and Optimizely Graph.

What is the release cadence between CMS 13 PaaS and SaaS going forward?

We are planning for an annual release cadence for PaaS, which means the lifecycle of CMS 13 will be shorter than what customers have been accustomed to with previous major versions.

Is Commerce 14 compatible with CMS 13?

No. Commerce 14 is not compatible with CMS 13. Commerce 15 is required.

When will Commerce 15 be available?

Commerce 15 is targeted for late April 2026. A preview version is currently available: https://docs.developers.optimizely.com/commerce-connect/v15-pre-release/docs/overview-of-commerce-15-pre-release#/versionshttps://docs.developers.optimizely.com/commerce-connect/v15-pre-release/docs/overview-of-commerce-15-pre-release#/versions

Is there a recommended upgrade order for Commerce and CMS?

The recommendation is to upgrade Commerce to Commerce 15 before or alongside the CMS 13 upgrade.

Will the Commerce Service API continue to be supported in Commerce 15?

Yes. A Commerce 15-compatible version of the Commerce Service API will be released in Q2 2026.

Are there performance improvements for large product catalogs in Commerce 15? Some sites experience very slow catalog updates with millions of products and attributes.

There are some improvements to catalog language handling which can be significant in multi-language catalogs, but Commerce 15 is primarily a Compatibility release for CMS 13.

Will Experimentation and Personalization be embedded more closely into Commerce 15?

At present, there are no plans to implement changes related to Experimentation or Personalization in Commerce 15. Personalization and experimentation are primarily used in CMS in conjunction with commerce content pulled from Commerce 15.

Which packages officially supported by Optimizely will be available and compatible with CMS 13 at launch?

A full list is available internally. Partner packages are being updated — contact Product or Partnerships for details. Forms (traditional/classic) are supported quickly after the CMS 13 is released.

Do you plan to upgrade add-on packages such as Find, Forms, and LanguageManager to support CMS 13?

Traditional Forms will be supported quickly post launch. For Find, the move to Graph is required — no CMS 13 support for the Find package is planned. For Language Manager (EPiServer.Labs), it would come to public at the end of quarter 2.

What is the ETA for `EPiServer.Labs.LanguageManager` for CMS 13? Will the naming change, and will known issues be addressed?

Within Q2, it would be released. And the current name is preserved.

Is there a plan to maintain technical support for the Find package in CMS 13 to allow a phased migration away from Search & Navigation?

No, the packages will not be upgraded to support CMS 13. Search & Navigation will continue to work from CMS 12, but not from CMS 13.

Will Dojo widgets continue to work without changes in CMS 13?

Yes, existing Dojo property editors continue to work. CMS 13 also introduces a modern ES6-based approach for custom property editors with no Dojo dependency.

Will TinyMCE be updated in CMS 13?

Yes. CMS 13 will move to TinyMCE 8.

Will third-party add-ons such as Geta categories, NotFoundHandler, Geta Generic Links, and Advanced Preview be compatible with CMS 13?

Third-party add-on owners are responsible for updating their packages for CMS 13 compatibility. For Geta packages, submitting issues in their GitHub repository is recommended. The Geta Advanced Reviews author has confirmed CMS 13 support is coming soon.

Will security patches continue for supported Optimizely packages (e.g., NotFoundHandler) while customers are waiting to upgrade to CMS 13?

For Optimizely provided packages, the answer here is the same as for "When will CMS 12 reach end of life (EOL)?". The addons we provide follow the same patch policy as the CMS major version they are for. NotFoundHandler is a 3rd party package though.

Will Product and Content Recommendations features work in CMS 13?

Product Recommendations are expected to be supported. Content Recommendations are lightweight and may not require changes. Confirm with the relevant product team.

Are there plans to improve the CMS experience on mobile devices? Many buttons are currently unusable on mobile.

There are currently no additional feature announcements on this topic planned for CMS 13.

How should Graph be configured in a development environment? Will a Graph instance be required per developer?

Developer indexes will be available. A self-service portal for short-lived developer indexes is available, see https://docs.developers.optimizely.com/content-management-system/v13.0.0-CMS/docs/cms-13-overview?isFramePreview=true#request-a-developer-instance

Will developer Graph instances be included in DXP the way Search & Navigation developer indexes were?

For developer demo instances, there will be a page by end of Q2 where people can request instances directly and it will be automated via a form and conductor. In the meantime, we'll handle the process manually via support and Kevin Shea and I will do the provisioning. @anna

Are the new HTML/tag helpers documented anywhere?

Documentation is not published yet but will be available at launch.

Will there be a React skeleton project for Optimizely that supports inline editing in Visual Builder?

Coming slightly after the 13.0.0 release, we will release a version of the JS SDK that supports CMS 13. That will contain some samples and templates, https://github.com/episerver/content-js-sdk/. Note that inline editing is not supported for headless setups. Headless is fully supported in Visual Builder and On-Page-Edit only support floating property editors.

Will there be a CMS 13 template similar to Alloy for a quick-start empty project?

Yes. The CMS 13 launch includes a new template called Stride, in addition to Alloy. It is updated with the content model supported by Visual Builder.

Are there guides or resources for switching from a Razor frontend to a headless React/Next.js setup?

Follow the JS SDK guides and documentation. Changing the architecture requires a complete rewrite of the frontend.

Is it possible to generate the Graph schema locally from code before deploying in a PaaS-based setup?

CMS handles Graph schema generation from Content Types automatically. Local schema generation before deployment is not currently supported. The indexing conventions API (for computed properties/schema extensions) will be released in a minor post-launch release.

Is Opti ID available for on-prem environments?

No. Opti ID is only available in DXP (SaaS or PaaS) environments.

Can on-prem customers upgrade to CMS 13, and what features will be unavailable to them?

Yes, on-prem customers can upgrade to CMS 13. However, features that require Opti ID — including Opal AI, Embedded DAM, and Optimizely Connect Platform — are not available on-prem. Graph is required and runs in the cloud but can be accessed from on-prem.

Will on-prem customers be able to purchase a standalone Graph instance to use CMS 13 Graph features?

Optimizely Graph is a cloud-hosted service and is not available for self-hosted or on-premises deployments. However, any CMS instance that can connect to the Graph service can use it, regardless of where the CMS itself is hosted.

Can a CMS 13 instance be run locally for development purposes?

Yes. PaaS projects can be set up and run locally. Note that some cloud-dependent features (like Opti ID and Graph) require connectivity to cloud services.

Are there any changes to the IContentEvents event system in CMS 13?

No, but CMS 14 will likely see changes in this area driven by the development of webhooks.

What is the replacement for SiteDefinitions (IApplicationResolver)? Is there an equivalent of ISiteDefinitionRepository for the new Application model?

Yes, IApplicationResolver and IApplicationRepository replace the old services.

PageReference is being deprecated in CMS 13. What should be noted when transitioning to ContentReference?

If you want a reference where the user can only select pages, model it as a ContentReference and set the AllowedTypes to only allow PageData.

Are there changes to how custom Admin pages are created, managed, or rendered in CMS 13?

No, it works the same way as in CMS 12.

Will scheduled jobs be made async in CMS 13?

The scheduled jobs API have not changed in CMS 13. There are plans to fully support async scheduled jobs in a future release.

Is the SaaS CMS REST API available for PaaS (CMS 13), and are there any differences?

Yes. The REST API available in SaaS will be available in CMS 13 with the same format and payload.

What is the status of Content Delivery API support in CMS 13?

Content Delivery API is supported for backward compatibility but is not available at the CMS 13 launch — it is expected to be in a follow-up release. Graph is the recommended long-term delivery approach.

Not all packages around tradition headless would be released. We preferably release the most important ones like Content Delivery API and perhaps EPiServer.OpenIDConnect. And The API would only support traditional content types like pages, blocks. No experience / sections support.

What is the Content JS SDK strategy for CMS 13? Is it the preferred way to manage CMS models, and does it support headless PaaS scenarios?

A new version of the JS SDK will be released supporting both SaaS and CMS 13. It is the recommended approach for frontend model management. For PaaS + headless, managing types where they're primarily used is the recommendation. Full PaaS headless support is an area of ongoing development.

Where should the source of truth for CMS content models live in a headless PaaS setup using the JS SDK?

The recommendation is to manage types where they're primarily used. For PaaS + headless this is typically the .NET code, with the JS SDK used for syncing types to the frontend.

What is with PropertyList\ and PropertyDefinitionTypePlugIn in ContentGraph? They are not included in the schema when T is based on a POCO class.

Custom properties default to their base types in ContentGraph. For PropertyList<T>, the schema type is JSON. PropertyList<T> has effectively been superseded by IList<TBlock>, which has a better interface.

Is ConventionRepository the best way to get StandardContentBase classes into ContentGraph?

To include base types in Graph we recommend modeling them as contracts, also known as abstract content types. Contracts are indexed automatically in Graph.

What are the best practices for UI extension and extending the CMS 13 UI?

The same way you could do it in CMS 12 is still supported for CMS 13. But we also added a new way to create custom property editors without the need to write any Dojo, https://world.optimizely.com/blogs/grzegorz-wiechec/dates/2026/3/custom-property-editors-in-optimizely-cms-13/.

How will CDA-based Graph customizations (previously used for backwards compatibility with Search & Navigation) be achievable in CMS 13 + Graph?

The initial release does not support extending the schema or adding computed properties. The indexing conventions API, which enables this capability, will be released in a minor post-launch release.

How does the preview pane work in Visual Builder for headless implementations?

Documentation on enabling live preview is available at: https://docs.developers.optimizely.com/content-management-system/v13.0.0-CMS/docs/enable-live-preview

Will CMS 13 have better integration for frontend frameworks like Next.js?

Yes. The Content JS SDK (https://github.com/episerver/content-js-sdk) provides improved integration for Next.js and other JS-based frontends.

What is the recommended way to handle content types when running PaaS + headless with the new JS Content SDK?

Manage types where they're primarily used. For a primarily .NET PaaS implementation, content types are still managed in C# code, with the JS SDK used for type sync via Graph.

Is Blazor supported for headless CMS implementations in CMS 13?

No official SDK or first-class support exists yet. Blazor is not discouraged, and content retrieval via Graph or the .NET API is still possible.

Will there be a React skeleton project for Optimizely CMS 13 that supports inline editing in Visual Builder?

Coming slightly after the 13.0.0 release, we will release a version of the JS SDK that supports CMS 13. That will contain some samples and templates, https://github.com/episerver/content-js-sdk/. Note that inline editing is not supported for headless setups. Headless is fully supported in Visual Builder and On-Page-Edit only supports floating property editors.