Optimizely CMS 13 (PaaS) became generally available in March 2026 - two years after the launch of the SaaS platform. PaaS is not the 'legacy platform' it's another platform.
Since the launch, the question rarely asked is whether to be on Optimizely. The question is which Optimizely. And that is the right question. The answer is certainly not always "the newer one".
Two products, not two generations
It is tempting, and given some of the rhetoric, to read SaaS as the future and PaaS as the legacy. That reading is wrong, and it can - if not addressed up front - lead to expensive corrections.
Optimizely maintains two active CMS lines. CMS 13 is the PaaS release. It runs on .NET 10, it is your application, and Optimizely’s own description is clear:
PaaS "allows full control of the application, custom code in the process, and deployment flexibility."
It supports MVC, headless, hybrid and mixed front-end architectures, and it can run on Optimizely’s DXP cloud or, if you need, on infrastructure you control.
CMS SaaS is the fully managed line. It is versionless, so Optimizely applies upgrades and there is no upgrade project and window to budget for.
It is built for headless delivery: the front end uses your framework of choice, hosted independently on Vercel or Netlify, or hosted by Optimizely. The trade is that custom code cannot run in-process, and customisations PaaS teams take for granted, such as custom properties and custom scheduled jobs, are not available.
Both lines carry Visual Builder and Optimizely Graph, and the embedded DAM is available to CMS 13 DXP customers. Opal is far more at home in CMS 13. In CMS 13, Graph and Opti ID are mandatory components of the licence, Search & Navigation is no longer supported, and Visual Builder is the default editing surface, with on-page editing switched off by default though still available by configuration.
So "SaaS is the one with the new editing experience" is no longer a reason to choose it.
The dividing line
One question separates the two: how much of your business logic do you have to run inside the CMS?
If the platform’s job is to publish content, and everything else (CRM, quoting engine, member database, billing) is reached through APIs at the edge or in the front end, SaaS is the better fit and the cheaper, easier life.
If code has to execute inside the platform, whether that is an overnight job reconciling a product catalogue, a custom property your editors depend on, or an integration that cannot sensibly move to the front end, then you need PaaS. No amount of enthusiasm for managed services will change that.
Where SaaS is categorically the right answer
Take a global manufacturing brand one with high global traffic. Say over 250,000 visitors a year. You need event booking and integrated news. Nothing in that estate needs code running inside the CMS. Content velocity, performance, marketer autonomy and no upgrade cycle to carry: that is the SaaS case made.
The same logic applies to a utility company’s brand estate, or a manufacturer running twenty market sites with a small development team. If your constraint is editorial throughput and your integrations are shallow, PaaS gives you control you will pay for and never use.
Where PaaS is categorically the right answer
Now consider an organisation like a membership body with a transactional core and a broad worldwide membership. The build requires integrated Commerce alongside membership sign-up and renewal flows. That estate is not a content site with a shop attached. The transactional logic is the product, and it needs a platform where code runs in-process.
Three other reliable tells for PaaS:
Commerce. Commerce 14 is not compatible with CMS 13, Commerce 15 is required alongside it. If Optimizely Commerce is in your stack, your CMS decision is aligned to your Optimizely Commerce version.
Hosting control. Organisations that need a specific hosting footprint, or a self-hosted deployment, only get that on PaaS. Note the trade-off: Opti ID is only available on DXP, not on-premise or self-hosted Azure, which puts Opal and the embedded DAM out of reach.
Deep in-process integration. Pension providers are the clearest case. An authenticated member area sitting on policy administration and scheme data is a PaaS problem.
Do not buy one architecture for two problems
Most of the organisations we work with have both. Pension providers have secure member portals and a public campaign estate. Utilities have an account area and a brand site. Those are different problems, and forcing them into one platform decision is how you end up with a heavyweight PaaS build publishing a landing page, or a SaaS instance bent into something it was never designed to do.
Get it right first time
This decision is not easily undone. Moving an existing PaaS implementation to SaaS is not a migration. Optimizely is direct about it: customisations do not carry over, and it is "more of a re-implementation exercise".
Choosing well now costs you a workshop. Choosing badly costs you a rebuild.
Four questions to answer before you commit:
1. What genuinely has to run inside the CMS, and could it run somewhere else?
2. Who owns upgrades in three years’ time, and will they have the time and capacity to execute?
3. Is there transactional or authenticated functionality in scope now, or on the roadmap?
4. Are we making one decision here, or two?
There is a strong case for both products. There is no case for choosing without answering those questions first.
How we help
We are a Optimizely Platinum Partner. If you are planning a CMS 13 upgrade, or evaluating CMS SaaS for the first time, we fix the architecture decision in a short assessment before anyone writes a line of code. If you are weighing it up now, get in touch.
