Every decade or so, a platform asks its customers to rebuild the foundation rather than add another room. Optimizely CMS 13 is one of those moments. Our job is to make sure it doesn't feel like one.
A Bigger Release Than the Version Number Suggests
In thirty years of building platforms, I've watched a lot of "major upgrades" turn out to be quiet package bumps with a new marketing deck taped to the front. Optimizely CMS 13 is not that kind of release.
It moves the runtime to .NET 10. It makes Optimizely Graph and Opti ID mandatory components of the license. It deprecates Optimizely Search and Navigation, the engine that has powered search on Episerver and Optimizely sites for roughly two decades. It disables on-page edit by default and replaces it with Visual Builder. It renames core concepts that editors and developers have been saying in meetings since the Episerver days. Site definitions become Applications. Blocks become Shared Blocks. The EPiServer namespace quietly gives way to the Optimizely one.
Read the release notes end to end and the shape of the thing becomes clear. This is not a version bump. It is a platform realignment. Optimizely has decided what the next ten years of its product will look like, and CMS 13 is the architecture it plans to build on.
For customers, that is both good news and a logistics problem. Good news, because the direction is coherent. Headless delivery, Graph at the center, Visual Builder for editors, Opal for AI, a REST API that finally feels like a first-class citizen. Logistics problem, because moving an existing CMS 12 estate onto that foundation is not a weekend of NuGet updates.
Why This Upgrade Is Different From the Ones Before It
The last few Optimizely upgrades were comparatively gentle. CMS 11 to CMS 12 was a real effort, mostly because of the .NET 5/6 transition, but the mental model of the platform was unchanged. You still had site definitions. You still had on-page edit. You still had Find.
CMS 13 removes some of those reference points.
The Search and Navigation deprecation is the one I would pay closest attention to. Find has been the default search engine on Optimizely sites for so long that it is wired into custom facet logic, editor-facing search widgets, boosting rules, synonym lists, and occasionally into scheduled jobs that nobody has opened in four years. CMS 13 does not ship a compatibility shim. The path forward is Optimizely Graph, with a new C# SDK that is genuinely pleasant to work with but which does not behave identically to the Find client. For teams already on Graph, there is one more detail worth knowing: the CMS 12 and CMS 13 output formats differ, so even existing Graph integrations need verification.
Visual Builder is the other source of real work. It is not an alternative editing mode bolted onto the side of on-page edit. It is the default, and on-page edit must be explicitly re-enabled through configuration. Templates, blocks, and layouts that were modeled around the old content areas will work, but they will not take full advantage of the new Experiences and Sections model. To get the benefit the release is actually selling, you need to revisit content modeling.
Then there are the quieter items. Applications replacing site definitions, which triggers an automatic migration but also changes how multi-site and headless applications are configured. Headless preview routing that now requires deliberate token setup. A DAM integration that now lives in its own package and requires Opti ID, an active Graph service, and CMP credentials. File extension whitelisting on uploads, which will catch any workflow that assumed legacy behavior.
None of these are blockers. Taken together, though, they are the reason a CMS 13 upgrade is not the same kind of project as a CMS 12 minor version bump.
How We Approach Upgrades at HT Blue
Our view on enterprise platform upgrades has not changed in years, even as the tools around them have. A good upgrade is a project with three phases: understand what you have, understand what the new platform wants, and move deliberately between the two. The mistake I see most often is teams collapsing those phases, starting the migration before they have finished the audit. That is how projects slip by months.
We structure our upgrade engagements around four principles.
Audit before you touch anything. Before we open a branch, we inventory every custom content type, every scheduled job, every Find query, every integration, every page template, every editor workflow that depends on the current platform. For CMS 13 specifically, we pay attention to Find usage, custom property types registered through the Plugin Manager (which is removed), any reliance on on-page edit behaviors, and anything that reaches into the EPiServer namespace directly.
Let AI do the cataloging, not the migrating. This is worth saying clearly, because the industry is muddled about it. AI is excellent at reading a large codebase and telling you where every Find query lives, which content types use which properties, and which templates reference deprecated APIs. AI is not good at performing a deterministic content migration that must preserve identity, references, versions, and publishing state across millions of items. We use AI to accelerate the parts of the work where fuzzy pattern matching is the point, and we use deterministic code for the parts where exactness is the point. Confusing the two is how you lose content.
Migrate the content model, not just the content. The temptation with any major upgrade is to lift the existing content model onto the new platform and deal with modernization later. With CMS 13, that is a false economy. Visual Builder, Experiences and Sections, and content variations reward a content model designed for composition. If you bring a CMS 12 model forward unchanged, you will ship, but you will not get the editor productivity improvements the release is selling, and you will end up doing the content modeling work anyway in a second project six months later.
Treat search as its own migration. Because it is. Moving from Search and Navigation to Graph is not a find-and-replace operation. Query patterns differ. Boosting and relevance tuning work differently. Facets, synonyms, and personalization rules need to be rebuilt against Graph's model. We plan this as a parallel workstream from day one, not as a late-stage cleanup task.
Where Automation Actually Helps
We have spent a lot of time at HT Blue figuring out which parts of a CMS upgrade respond well to automation and which parts do not. For CMS 13, the list is reasonably stable.
Automation helps with codebase auditing. We run custom tooling that reads an entire Optimizely CMS 12 solution and produces a report: every Find client call, every reference to removed APIs, every content type that will need attention under the new Applications model, every template that would benefit from being restructured for Visual Builder. This used to take a senior engineer a week. It now takes an afternoon.
Automation helps with migration script generation. Once we know what needs to change, an LLM with the right context can draft the repetitive code changes. Namespace updates. DI container adjustments. Find-to-Graph query translations for common patterns. A human engineer reviews everything, but the first pass is no longer handwritten.
Automation helps with regression test coverage. Generating test cases for content rendering, editor workflows, and API contracts is exactly the kind of work where a machine's patience outperforms a human's.
Automation does not help with the actual content transfer. That remains deterministic, scripted, and verified. It does not help with editor training, which still requires real humans sitting with real editors. And it does not help with the decisions, which is most of the work that matters.
This is what we mean at HT Blue when we talk about human-at-the-helm automation. The machines extend what a small senior team can cover. They do not replace the judgment that keeps the project from going sideways.
What This Means If You Are on CMS 12 Today
A few things to think about this quarter, whether or not we are the team that ends up helping you.
Start with an honest audit. Not a vendor-led discovery call. A real inventory of Find usage, custom extensions, on-page edit dependencies, and content model debt. If you do not know what you have, you cannot scope what it will cost to move it.
Do not assume Opal and Visual Builder are free. They are powerful, and they are part of where the platform is going. But getting value from them requires content modeling work that may not be in your current backlog.
Watch the timeline carefully. Optimizely has signaled that .NET 8 reaches end of support in November 2026, and that a .NET 10 compatible version of CMS 12 is under consideration but not committed. The runway for staying on CMS 12 is real, but it is not indefinite.
Treat the upgrade as a modernization opportunity, not a compliance exercise. The teams that get the most out of CMS 13 will be the ones who use the move as a reason to revisit content models, retire custom code that should have been retired three years ago, and take a second look at the editor experience their team actually has today.
The Foundation Matters
Platforms are long-lived things. The one you move to in 2026 will still be the one your editors are using in 2031, and probably still the one your developers are debugging in 2033. That is why we spend so much time on the audit and the content model before we spend any time on the migration.
Done well, an upgrade like CMS 13 is a chance to pay down a decade of accumulated technical debt while setting up for the next one. Done quickly, it is an invoice you pay again in three years when the next platform realignment comes around.
We prefer the first version. We have a few opinions about how to get there.
Practical Takeaways
- CMS 13 is a platform realignment, not an incremental release. Scope it accordingly.
- Find is gone. Plan the search migration to Graph as a parallel workstream, not a last-minute task.
- Visual Builder rewards content model redesign. Bringing a CMS 12 model forward unchanged leaves value on the table.
- Use AI to accelerate auditing and code generation. Keep content transfer deterministic.
- The runway on CMS 12 is real but finite. Start the audit conversation now, even if the migration is a 2027 project.
