Optimizely CMS 11 Is Out of Support — and the Hard Part of the Upgrade Isn't the CMS

I’ve worked on a lot of Optimizely upgrades over the years — back through the EPiServer days, the version 7 transition, into the CMS 11 era, and now well into 12 and 13. Most of them go fine. None of them go fast.

So when a client asks “how hard can a CMS 11 to 13 upgrade really be — it’s still Optimizely, right?”, I have a slightly weary answer ready.

The CMS itself isn’t where the hours go. It’s everything you built around the CMS that takes the time.

What changed in April 2026

Optimizely supports the two most recent major versions of CMS. CMS 13 reached general availability on 31 March 2026, and on 10 April 2026 Optimizely formally announced that CMS 11 was out of support. It isn’t a discretionary call — it’s the policy doing what it always does when a new major lands: CMS 12 stays in the window, CMS 11 falls out.

End of support means no more bug fixes, no more security patches, no more compatibility updates as the rest of the .NET ecosystem moves on. Your site keeps running, but nobody is keeping the foundations in good repair.

There’s no enforced sunset date. Optimizely isn’t going to switch your installation off. But every month after April pushes more of the stack out of vendor coverage: hosting, dependencies, integrations. By next year you’re maintaining a system the vendor no longer maintains.

CMS 13 reaching GA and CMS 11 leaving support aren’t separate decisions — the new major arriving is what dropped the older one out of the window, and the 10 April announcement was the formal record of that. Optimizely has put real platform improvements behind it, which is how this kind of policy is supposed to work. But it does mean the runway you have is whatever runway the new major’s release schedule gave you.

The CMS upgrade is documented. Your customisations aren’t.

The CMS upgrade follows a documented path. Optimizely ships migration tooling, breaking changes are listed, and the platform’s content schema mostly survives the journey. The 12-to-13 leg is largely a Graph schema update and a set of well-documented breaking changes — manageable on its own. The 11-to-12 leg is the heavier one: that’s where the .NET Framework to .NET Core jump lives, and the platform-side work is real even before you touch your own code.

Either way, the platform side is the part with documentation.

The hard part of an Optimizely CMS 11 upgrade isn’t Optimizely CMS.

The hard part is the decade of stuff layered around it: custom property types, scheduled jobs, content-import plumbing, integration endpoints to ERPs and PIMs and CRMs, custom admin tools, EPiServer.Find queries scattered across half the codebase, third-party add-ons of varying levels of liveness, and a content model that has accumulated three product launches’ worth of edits.

That’s where the engineering hours go. And that’s the part nobody quotes against when they pitch an upgrade as “just a version bump.”

The runtime jump is the largest single bucket — and it sits in the 11-to-12 leg

This is the bit that catches teams out the most.

CMS 11 runs on .NET Framework. CMS 12 moved to .NET Core; the supported flavour is now .NET 8. CMS 13 moves again to .NET 10, but that’s a much smaller leap than the original Framework-to-Core jump. The bulk of runtime work in a CMS 11 → 13 engagement happens in the 11-to-12 leg.

That has consequences everywhere. Every NuGet package you depend on either has a modern .NET build, or it doesn’t. If it doesn’t, you’re either replacing it, forking it, or rewriting that part of the system. Anything sitting on System.Web is going. Authentication moves from OWIN to the modern hosting model. Configuration shifts from web.config to the appsettings/options pattern. Dependency injection becomes the default. Serializers, helpers, custom HttpModules — much of it needs touching.

In a typical CMS 11 → 13 engagement, the runtime work is the largest single bucket of CMS-side effort, and almost all of it sits in the 11-to-12 leg. Bigger than the content migration. Bigger than the visual rebuild. It’s mostly invisible from the outside, which is why it gets under-budgeted.

Find is gone. Search and navigation are now Graph problems.

Optimizely Find is not part of CMS 13. Anything you built on EPiServer.Find — search results pages, autocomplete, faceted listings, navigation menus driven by content queries, related-content widgets — has to be re-implemented on Optimizely Graph.

The good news: Graph is a properly modern, GraphQL-based content layer, and the Optimizely.Graph.Cms.Query SDK exposes a fluent C# API that mirrors Find’s shape closely. Filter becomes Where, For becomes SearchFor, Take becomes Limit. The mental model survives.

The less-good news: you still have to do every rewrite by hand, and Graph wants you to think about your indexing model differently. Editors used to Find’s near-instant indexing will need a brief on Graph’s different sync behaviour. Anything that did clever scoring tricks in Find needs the equivalent worked out in Graph.

If your site’s search is core to its UX, this part deserves its own scoping conversation, not a footnote in the migration plan.

Visual Builder rewards a structural rethink

CMS 13’s Visual Builder is the new default editing experience, and it’s genuinely good. Experiences and sections separate layout from content in a way that puts the editor back in control of the page.

But you don’t get the value of Visual Builder by porting your old content types over verbatim. The win comes from rethinking the content model — splitting monolithic page types into composable sections, lifting layout decisions out of the page schema, giving editors actual building blocks instead of a long form with thirty fields.

If you’re already going to disturb the content model, do it properly. The alternative is shipping CMS 13 with a CMS 11 mindset: the new editor on top of the old structure, all of the cost and none of the upside.

Custom plugins almost always need a rewrite

The admin UIs and edit-mode plugins you built five years ago are going to need work. CMS 12 already moved the editor off its Dojo-based legacy, and CMS 13 changes admin-page integration further — new Tag Helpers, a different shell navigation model. Custom property editors and dashboards built for CMS 11 won’t survive the trip without re-implementation.

That’s annoying, but it’s also an audit opportunity. A surprising number of in-house plugins exist because someone needed something on a Tuesday in 2020 and they’re still there because nobody removed them. The upgrade is a natural moment to ask: which of these are actually earning their keep? Reimplement the ones that are. Retire the rest.

The most generally useful editor and admin tools — the ones almost every Optimizely site reinvents at some point — we’ve already open-sourced as Editor Power Tools, dual-targeting CMS 12 and 13. So the worst of that wheel doesn’t need reinventing on each upgrade.

How we’re approaching these upgrades now

I’ve been on several CMS 11 → 13 upgrades, and a few of them have been agent-driven end to end. A few things have come out of that:

• Agents trained on the specific upgrade path. The gotchas and landmines of CMS 11 → 13 are a finite, well-defined set. Once you’ve hit them a few times, they’re agent-friendly — and we now have agents that recognise the patterns: old IContentRepository usage that should become async, EPiServer.Find calls that need translating to Graph, configuration sections without a clean 1:1 in the new world.
• An automatic data-migration system. Content schemas shift between versions, and most upgrades involve some reshaping anyway. We have a system that runs the migrations as part of the deploy pipeline, with validation and rollback, so editors don’t notice anything during cutover.
• The same engagement can take you off on-prem. If you’re hosting CMS 11 on your own infrastructure, the upgrade is the right time to move onto Optimizely DXP with Graph support — rather than rebuilding the on-prem stack on .NET 10 only to migrate again later.

That’s all on the Optimizely Upgrading offering page if you want the formal version.

If you’re on CMS 11, here’s how I’d plan it

The cliff was April. The cost of inaction compounds. “Support ended” doesn’t mean “site stopped working” — your installation still runs. But every month past April, your dependency graph drifts further out of supported, and the planning runway you needed gets a little shorter.

Audit before you scope. The realistic upgrade cost is a function of what’s around the CMS, not the CMS. A two-day audit — add-ons, custom code, search, integrations, plugins — gets you a budget you can actually trust.

Spike the runtime move and Graph in isolation. Before committing to a full plan, prove out the two riskiest pieces on a slice of the codebase. The numbers from those spikes tell you whether to go straight to 13 or stage via 12.

Treat the content model as part of the upgrade. The structural changes Visual Builder rewards are easier to do under upgrade scope than as a follow-up project nobody finds budget for.

Plan now and ship. Even an aggressive timeline benefits from runway. The teams who started planning a quarter ago will land softly. The teams who start in the autumn will not.

If you’d rather not do the upgrade alone, that’s what our Optimizely Upgrading offering is for — the same engagement described above, end to end: assessment, runtime move, content migration, Find-to-Graph rewrite, cutover, and post-launch care.

The CMS will move when you tell it to. The decade of stuff around it is the part that takes the planning.