An Optimizely upgrade can look straightforward on a roadmap. Just move to the latest version, update the underlying technology, test it, and deploy.
The reality though depends heavily on what you’re upgrading from, what your business does right now and needs to do in the future, and what’s accumulated around your Optimizely implementation since it was first built.
Custom code, integrations, authentication, third-party packages, content models, APIs, deployment processes, and years of incremental development, can all affect the scale of an Optimizely upgrade. And with Optimizely 13 now available, there are some fundamental architectural changes to consider too.
That doesn’t mean an upgrade needs to become a huge transformation programme. But it does mean you need to understand what you have before deciding how you’re going to move it forward, and whether you in fact need to.
Start with what you're running
Platform version number matters, of course, as it may affect ongoing support, but the number you currently have tells you surprisingly little about the likely complexity of an upgrade.
Two organisations running the same version of Optimizely CMS (Content Management System) can have very different jobs ahead of them when it comes to an upgrade.
One might have a relatively standard implementation with a small number of integrations and limited customisation. Another might have years of custom development, legacy packages, complex authentication, multiple websites, search and navigation, commerce integrations, external applications consuming CMS content, and business-critical connections into CRM, DAM, PIM, or other systems.
Before planning the upgrade, you need a proper picture of your estate. That means understanding:
- the version of CMS you're currently running
- Optimizely and third-party packages and their dependencies
- custom code and components
- integrations and APIs
- search implementation
- authentication and user management
- content models and editorial customisations
- front-end architecture
- deployment and hosting configuration
- areas of technical debt that could complicate the move
Optimizely CMS 13 changes the upgrade conversation
CMS 13 became available in March 2026. It runs on .NET 10 and introduces a more significant shift in the underlying Optimizely architecture, with deeper use of Optimizely Graph, a new content management experience, and closer integration across the wider Optimizely platform
All that means you should treat CMS 13 as more than a routine version update.
If you're moving from CMS 12, for example, the official upgrade process requires the application to target .NET 10. Optimizely also recommends auditing third-party NuGet packages for CMS 13 compatibility and identifying custom code that relies on APIs or functionality that has changed or been removed.
The move to .NET 10 is particularly relevant because .NET 8 reaches end of support in November 2026. Optimizely has confirmed that CMS 12 will not officially support .NET 10, making CMS 13 the upgrade path for organisations that want to move their Optimizely implementation onto Microsoft's current long-term support release.
Search needs particular attention
One of the most important changes to understand before a CMS 13 upgrade is search.
Optimizely Search & Navigation – still often referred to by its previous name, ‘Find’ – isn't supported in CMS 13. Organisations currently using it need to move their search implementation to Optimizely Graph or choose another search provider.
Optimizely Graph uses GraphQL and provides a different way of indexing, querying, and retrieving content. Optimizely's CMS 13 Graph SDK supports capabilities including full-text search, filtering, fuzzy matching, semantic sorting, autocomplete, facets, boosting, and pinned results, but it doesn't simply replicate every Search & Navigation capability or API.
If you're already using Optimizely Graph with CMS 12, there's one other consideration. CMS 13 introduces breaking changes to the Graph schema, which means CMS 12 and CMS 13 can't simply share the same Graph instance during an upgrade without dealing with that schema change. For DXP customers, Optimizely now supports provisioning a separate Graph instance as part of the CMS 13 upgrade process, allowing the CMS 12 production environment to continue using its existing Graph instance while CMS 13 is validated in a deployment slot. That provides a route to upgrading Graph without introducing Graph downtime.
Don't assume your integrations will just come with you
Optimizely rarely operates in isolation. It may be connected to your CRM, commerce, PIM, DAM, marketing automation, analytics, identity providers, internal systems, or bespoke applications.
Some of those connections may use standard supported connectors. Others may have been custom-built several years ago by people who are no longer involved with the platform.
A planned upgrade is a good point in time to establish what those integrations actually do, whether they're still needed, who owns them, and whether the packages and APIs behind them remain supported.
Optimizely CMS 13, for example, includes changes to the Content Delivery API. Version 13 moves from Newtonsoft.Json to System.Text.Json, introduces end-point changes, and removes the previous Content Definitions and Content Management APIs. If another application relies on those interfaces, that's something you need to know before you upgrade, rather than discover during testing.
Authentication deserves similar attention. CMS 13 uses Opti ID as an important part of the wider Optimizely platform experience, including access to capabilities such as Optimizely Agent Platform (previously called Opal, and now Mark – short for Marketing) and embedded DAM (Digital Asset Management). Existing authentication arrangements, user roles, SSO, and service-to-service authentication therefore need to form part of the assessment.
None of this means every integration needs rebuilding. It means each dependency needs an answer.
Decide what you're carrying forward
A mature Optimizely estate can contain years of decisions. Some will still make perfect sense. Some will exist because of limitations that no longer apply. Others may support processes nobody uses, duplicate capabilities now available elsewhere, or make the platform unnecessarily difficult to maintain.
Does everything in your existing implementation deserve to survive?
This is where an Optimizely upgrade assessment becomes useful. It gives you the opportunity to separate what genuinely needs migrating from what should be simplified, replaced, or retired.
That might mean removing an obsolete integration, replacing custom functionality with a supported platform capability, rationalising packages, simplifying a content model, or dealing with technical debt while you're already working in that part of the codebase.
But you need discipline. An upgrade shouldn't automatically become an excuse to redesign the website, replace every integration, restructure all your content, and solve every piece of technical debt you've accumulated. The objective is to make sensible decisions about what belongs in the upgrade and what doesn't.
Think about the people using the CMS
Technical compatibility is only one part of a successful upgrade. Optimizely CMS 13 introduces changes to the editorial experience, including Visual Builder as the default way of creating and editing experiences. Optimizely Graph also plays a much more central role in areas including content discovery and delivery.
That means testing shouldn't stop when developers establish that the application builds and the website renders correctly.
Editors need to be able to create, preview, edit, publish, and manage the content they rely on. Existing workflows, permissions, custom property editors, forms, media handling, and other everyday tasks need testing too.
If an upgrade changes the way people work, you need to allow for that in the plan. Training and communication may be relatively small pieces of the overall programme, but suddenly discovering after launch that a critical editorial process no longer works can be incredibly disruptive.
Testing needs to reflect the real platform
A platform upgrade touches enough of your underlying implementation that regression testing is a must.
The exact test plan will depend on your digital estate, but it should cover the things your organisation actually relies on rather than just a collection of generic page templates, including:
- core customer journeys
- site search
- forms and data capture
- authentication
- integrations and data flows
- personalisation
- experimentation
- redirects and routing
- APIs and headless delivery
- scheduled jobs
- editorial workflows
- accessibility
- performance
- analytics and tracking
For DXP implementations, the deployment path also gives you the opportunity to validate changes through Integration and Pre-production before Production. CMS 13's deployment-slot approach can support production-like validation and safer switching, but the technology only helps if you've decided what needs validating in the first place.
Plan the roll-back before you need it
A good upgrade plan doesn't assume everything will work perfectly at launch. Database back-ups, deployment slots, environment configuration, Graph migration, release sequencing, DNS or routing dependencies, and roll-back criteria should all be understood and in place before the production deployment begins.
You should know what will cause you to stop a deployment, what can be rolled back safely, what data or schema changes need particular care, and who makes the decision if something goes wrong.
The more commercially important the platform upgrade, the less you want those decisions being made for the first time during a release window.
Use the upgrade to improve your platform, not reinvent it
Treating an Optimizely upgrade as nothing more than technical maintenance can mean missing opportunities to remove problems that might have built up over time.
And turning it into a complete digital transformation can make the project unnecessarily expensive, risky, and slow.
The better approach is to understand your current estate, identify the changes the target version genuinely requires, and then make deliberate decisions about the additional improvements worth making.
With CMS 13, that assessment is particularly important. The move to .NET 10, the increased role of Graph, the end of Search & Navigation support, changes to authentication and APIs, and the evolution of the editorial experience all have the potential to affect your existing implementation differently.
DotCentric has worked with Optimizely for more than 15 years, across new implementations, complex integrations, ongoing platform development, and major upgrades. We can assess an existing Optimizely estate, identify the dependencies and risks that are likely to affect an upgrade, and help determine the most sensible route forward before development starts – in fact we’re doing all that with our valuable clients right now
If you're considering your next Optimizely upgrade, it’s worth talking to a safe pair of hands from people who have done hundreds of times. Because we stop to ask - “what will it actually take to get your platform there safely, is it worth it, and what should you improve while doing it?”
Want to talk to use about an Optimizely upgrade or an assessment? Just contact us and one of our Optimizely MVPs will be in touch.
