Optimizely CMS 13: What Partners Need to Know Before the Upgrade

Update, April 2026: I originally published this post in early March while CMS 13 was still in preview. CMS 13 went GA on March 31, and several details I speculated on turned out differently. Rather than quietly editing, I've corrected the specifics inline and flagged what changed. I've also written a companion post on what the Graph SDK means for your Find migration, which covers the biggest shift since I originally wrote this.

After four years on CMS 12, Optimizely's next major PaaS release is almost here. CMS 13 is landing in Q1 2026 shipped on March 31, 2026, and the timing feels significant. Not just as a version bump, but as a platform alignment moment that's been building for a while.

I've been watching the previews closely, and I've had more clients ask me about this release unprompted than any Optimizely update I can remember. There's a lot to unpack, but this isn't going to be a features list. What I want to do is give you a practical, partner-side perspective on what CMS 13 actually changes, what the CMS 12 to CMS 13 upgrade path honestly looks like, and what you should be doing right now with your clients.

Why CMS 13 Is Different From a Normal Version Bump

If you lived through the CMS 11 to CMS 12 migration, you probably still have the scars. That was a genuine platform re-architecture. Moving from .NET Framework to modern .NET was transformational and, for many teams, painful.

CMS 13 is not that. Optimizely has been clear that the 12→13 path is considerably lighter. But that framing carries a risk: teams hear "lighter migration" and start treating it like a routine package update. It isn't.

What CMS 13 really represents is the PaaS platform catching up to where SaaS has been living for over a year. Optimizely's SaaS and PaaS versions share a common codebase, which means the features shipping in CMS 13 for PaaS customers aren't hypothetical. They've been in production on SaaS. That's actually reassuring from a stability standpoint, but it also means the architectural direction has already been set. Graph is the backbone. Opal is the AI layer. Visual Builder is the editorial surface. CMS 13 is the moment PaaS customers get to join that world properly.

What the Architecture Has Become

Optimizely Graph Is Now Central, Not Optional

This is probably the most important thing to understand about CMS 13, and honestly, the thing I'm most excited about. Graph has shifted from an optional add-on to the foundation several core platform capabilities are built on.

Content Manager (the new editorial experience) relies on Graph for content discoverability. External Content, which lets you pull product data, DAM assets, and CRM content directly into CMS blocks, depends on Graph's indexing. RAG for Opal, which is how AI agents access your content intelligently, flows through Graph. Even GEO (Generative Engine Optimization), the built-in tooling for making your content visible to AI crawlers and LLMs, is Graph-backed.

Preview 3 made Graph opt-in by default rather than auto-enabled, likely in response to developer feedback about not wanting forced dependencies. But opt-in doesn't mean optional if you want the platform to actually deliver on its promise. Think of it less as "you can skip Graph" and more as "you technically don't have to enable it, but you probably should." the GA release made the position definitive: Graph and Opti ID are now mandatory components included in your CMS 13 license. The "opt-in vs mandatory" ambiguity from the preview period is resolved. Graph is the platform.

If your clients haven't started thinking about Optimizely Graph adoption, CMS 13 is the forcing function. We've been building all new PaaS and SaaS sites at WOW with Graph for over a year now, so for us this isn't a leap into the unknown. But I know that's not the case for every partner. If you haven't worked with Graph yet, don't wait until a CMS 13 upgrade forces your hand. Start with a new build or a smaller project so your team has the muscle memory before it's on the critical path.

Post-GA update: The Graph learning curve just got significantly less steep. Optimizely shipped a C# fluent SDK (Optimizely.Graph.Cms.Query) that mirrors Search & Navigation's query patterns. I've written a separate post on what this means for migration scoping.

Visual Builder: Marketers Building Without Dev Tickets

Visual Builder has been the flagship feature of Optimizely's SaaS CMS story, and it's now fully part of the PaaS picture. The pitch is real: marketers can build and publish experiences without raising a ticket, without waiting for a developer, without touching page templates.

Post-GA update: What I didn't cover originally is that CMS 13 ships with ASP.NET MVC tag helpers for Visual Builder (epi-outline, epi-component, epi-grid, epi-row, epi-column) that let you render content server-side without depending on Graph for delivery. For PaaS teams worried about being forced into a fully headless delivery model, that's meaningful reassurance. You can adopt Visual Builder's editorial experience without rearchitecting your frontend.

For agencies, this is a double-edged thing. It's genuinely valuable for clients. Faster campaign cycles, more editorial independence. But it changes how you scope build work and ongoing support. Blocks and content types still need to be designed and governed well at the developer level for Visual Builder to be effective. The "no dev tickets" promise only works downstream of solid foundational work.

Optimizely External Content: Unified Integration Without the Glue Code

I think External Content is going to be quietly important in ways the marketing copy doesn't fully capture. It's Optimizely's approach to pulling live data from external systems (PIMs, ERPs, DAMs, CRMs) directly into CMS blocks, without custom integrations or brittle sync jobs.

Rather than building one-off integrations per client, you have a standardized model for connecting external data sources. The content appears native in the editorial interface, updates automatically, and doesn't require a developer to keep it in sync. I've been on enough projects where a good chunk of the budget went into building and maintaining those integration layers to know how much this could change the scoping conversation, especially for clients managing product data, pricing, or frequently-updated assets.

Opal AI Integration in CMS 13

CMS 13 ships with Opal agent integration across the editorial workflow: content auditing, SEO metadata optimization, GEO recommendations, alt text generation for images. These aren't bolt-ons; they're part of the standard editing experience.

The GEO angle is particularly worth paying attention to. As AI-powered search and answer engines become a real traffic source, the ability to optimize content for LLM discoverability, not just traditional SEO, is becoming a real concern for clients. CMS 13 gives you built-in tooling for that conversation.

CMS 13 Prerequisites: Opti ID and Optimizely Graph Migration

Here's where partner experience matters. Before a client can upgrade to CMS 13, two things need to be true, and neither is always a quick fix.

Opti ID is mandatory. Authentication must go through Optimizely's single sign-on service. If a client is still running their own identity stack, or hasn't migrated to Opti ID, that's a pre-migration workstream in its own right. Start that conversation early. It's not technically complicated, but it has organizational implications, especially for clients with custom role structures or enterprise SSO configurations. I'll be honest: this is going to rub some people the wrong way. Teams that have invested in their own identity setup don't love being told they have to move to a vendor-managed SSO, and I've already had a couple of those conversations. The key is framing it early enough that it doesn't feel like a surprise at migration time.

Post-GA update: The licensing change helps here. Opti ID is now included in the CMS 13 license, not an additional adoption decision. That shifts the conversation from "you need to buy into a new identity platform" to "this is part of what you're already paying for." The migration work is still real, but the commercial objection is gone.

Search & Navigation is deprecated. This one's a bit bittersweet. If you've been in the Optimizely ecosystem long enough, you probably still call it "Find" half the time. It's been the default search solution for as long as most of us have been building on the platform, and for a lot of projects it just worked. You dropped it in, configured your facets, maybe wrote a few custom projections, and moved on. But it's time to let go. If a client's site relies on Search & Navigation for search functionality, they need to migrate to Optimizely Graph before or alongside the CMS 13 upgrade. This isn't a small item. Depending on how deeply S&N is embedded (customized search pages, faceting, boosting rules) the Graph migration can be a meaningful piece of work. Graph is genuinely better for where the platform is heading, and having used it extensively at WOW I can say the developer experience is good once you're past the initial learning curve. But don't underestimate how much institutional knowledge some teams have built up around Find's query API. That migration isn't just technical; it's asking developers to leave behind patterns they've used for years.

Post-GA update: This paragraph aged the worst. The week before GA, Optimizely published the Graph SDK, a C# fluent API that intentionally mirrors Search & Navigation's patterns. Where() replaces Filter(), SearchFor() replaces For(), Limit() replaces Take(). The "leaving behind patterns" framing was based on the old Graph .NET Client, which required a genuine rethinking. The SDK makes the query translation far more mechanical than I described here. I've written a full post on what this means for migration scoping.

Both of these are things you can identify and scope now, before the upgrade conversation even starts. In discovery, they're deal-defining items.

CMS 13 Migration: What the Upgrade Actually Looks Like

The good news: the API changes in CMS 13 are manageable. The compiler will flag most of them directly: deprecated members, obsolete types, changed interfaces. Treat the warnings as your migration checklist.

CMS 13 targets .NET 8 (with .NET 9 support expected to follow). CMS 13 targets .NET 10. If a client is still on .NET 6 an earlier runtime, that upgrade needs to happen first or concurrently. It's straightforward in most cases, but worth surfacing early, especially for teams with CI/CD pipelines or hosting configurations tied to a specific runtime version.

Post-GA update: The jump to .NET 10 is larger than I originally anticipated. Clients on .NET 6 have a two-generation runtime gap to bridge, not one. Factor that into your timeline.

A few code-level specifics worth calling out:

PageReference and PageData.PageLink are now obsolete. The replacements follow the newer content reference patterns introduced progressively through CMS 12, so if a codebase has been staying reasonably current, many of these will already be addressed.

ContentArea.FilteredItems is obsolete, replaced by a new filtering interface (IEnumerable<IContentAreaItemsRenderingFilter>). This one's catching teams out in the preview forums because it's less obvious than the others.

Identity management is decoupled. There's a new EPiServer.CMS.UI.AspNetIdentity package that needs to be added explicitly. It's not automatic.

ContentType replaces PageType in certain repository and filter contexts. Simple in isolation, but worth a targeted search across the codebase.

Post-GA update: Two additional migration items I missed originally. SiteDefinition has been replaced by a new Applications model for managing in-process and headless websites. If you have multi-site configurations or custom code touching SiteDefinition, add that to the checklist. And the DAM integration has been rearchitected with a new EPiServer.Cms.DamIntegration.UI package, with a migration package promised for converting CMS 12-style DAM asset references.

None of these are architectural emergencies, but they add up on a real-world site versus an Alloy template. The add-on and third-party package story is also not fully settled yet. Any client with custom add-ons or community packages should audit those for CMS 13 compatibility before committing to an upgrade timeline.

The honest take: this is a good migration to be planning and scoping now. The preview is stable enough to validate your approach. Waiting until GA drops to start thinking about it is going to compress your runway. GA is here. If you haven't started, you're already behind the partners who tested against the previews.

CMS 13 as the Opal Foundation

CMS 13 is less about what's new in the CMS editor and more about establishing the infrastructure for Opal to operate effectively within a PaaS context.

RAG (Retrieval-Augmented Generation) for Opal depends on Graph indexing your content. The Opal agents that audit and optimize content depend on the modern API surface CMS 13 is building on. The GEO tooling depends on Graph making content discoverable to AI systems.

Opal is the intelligence layer. CMS 13 is the connective tissue that makes that intelligence actionable within the PaaS CMS. It's not just "here are some new features." It's the PaaS platform getting the foundation it needs to participate in Optimizely's AI-first roadmap.

For clients who are asking about AI capabilities, CMS 13 is part of the honest answer. I've started getting questions in discovery calls that would have seemed strange two years ago: "Can the CMS help us write better content?" "How do we show up in ChatGPT results?" CMS 13 with Opal is the first time I've had a concrete answer to those questions that isn't "well, you could bolt on a third-party tool." And for those clients who aren't asking yet? They will be.

What Partners Should Be Doing Right Now

You don't need to wait for GA any longer to get ahead of this.

Audit your active client base. Who's on CMS 11 or 12? What's their current Search & Navigation posture? Have they adopted Opti ID? These three questions will tell you who needs a conversation soon versus who has runway.

Start the Opti ID conversation. For any client not already on it, this is the kind of change that needs IT, security, and sometimes legal involvement. Lead time matters.

Get hands-on with the CMS 13 preview. Start your first real upgrade. Preview 3 is reasonably stable. If you have an internal or client-adjacent project you can test the upgrade path against, do it now. The lessons you pick up before GA are the ones that let you quote upgrade engagements with confidence rather than guesswork. GA is out. Pick an internal or lower-risk client project and run the upgrade. The lessons you pick up on your first migration are the ones that let you quote subsequent engagements with confidence.

Frame it as modernization, not maintenance. The upgrade conversation is much easier when it's positioned around what the client gains (marketer independence, AI-ready content infrastructure, reduced integration overhead) rather than "you need to stay on a supported version."

I'm planning to running through the upgrade on one of our internal builds in the next few weeks. Genuinely looking forward to it, which is not something I'd normally say about a CMS migration. If anything surprising comes out of that, I'll write it up.