Optimizely vs Payload

Optimizely sells its CMS as part of a suite. The CMS comes in two forms, a .NET product (CMS 12 or CMS 13) that runs on Optimizely’s DXP cloud or your own hosting, and a headless SaaS service, and it sits beside separate products for experimentation, personalization, customer data, commerce and AI. Payload is an open-source TypeScript application that installs into a Next.js project and manages content. So this page compares the CMS layers directly, and treats experimentation and commerce as separate decisions, because some of them can stay when the CMS changes.

It covers Optimizely CMS 12, CMS 13 and CMS (SaaS), and Payload 3, as checked on 29 September 2026. For the upgrade routes from CMS 11 and the mechanics of a move, see our Optimizely migration guide; this page is about choosing.

The short decision

Stay with Optimizely when several of its products work together: Commerce Connect on the same platform as content, Visual Builder with content variations feeding experiments, and one contract for the lot. CMS 12 remains maintained, and CMS 13 is the current version.

Choose Payload when Optimizely is used mainly as a CMS, the site is headless or moving to Next.js, and the team wants the content model and access rules in the same TypeScript codebase. Web Experimentation can keep running on the new site. Payload can be hosted by your team, deployed from Vercel or Cloudflare templates, or hosted by Payload under an enterprise agreement.

Which Optimizely you are comparing

Optimizely’s release notes by product list the pieces separately, and three of them are content management systems.

• CMS 12 is the previous .NET version and remains maintained. It edits pages with On-Page Editing and delivers content through server-side rendering or the Content Delivery API.
• CMS 13 became generally available on 31 March 2026. It needs .NET 10, makes Optimizely Graph and Opti ID mandatory parts of the licence, and uses Visual Builder as the default editor. On-Page Editing is disabled by default but can be re-enabled by a developer. It also adds content variations and an embedded DAM.
• CMS (SaaS) is, in Optimizely’s overview, “a headless service managed by Optimizely”. Content is read through Optimizely Graph, configured through a REST API, and updated through four rollout rings, with no versions to upgrade.

Around them sit Web Experimentation, Feature Experimentation, Personalization, the Optimizely Data Platform, the Content Marketing Platform, Commerce Connect, Configured Commerce and Opal, Optimizely’s agent orchestration platform. Each is its own product.

Where the versions stand

Optimizely’s CMS 12 release notes carry its version policy, dated April 2026: “The currently maintained versions are CMS 13 and CMS 12.” CMS 11 and earlier get no ongoing fixes except for severe security vulnerabilities, and Optimizely “does NOT enforce end-of-life through forced upgrades, disabled environments, or removal of access”. No end-of-support date for CMS 12 had been announced on 29 September 2026. CMS 13 reached 13.2.0 on 21 September.

For a CMS 12 estate, then, the choice has no vendor deadline attached. The framework has its own timetable, and our migration guide covers the .NET and upgrade details.

Editing and visual composition

On CMS 12, editors work in On-Page Editing, editing content on a preview of the page. CMS 13 and CMS (SaaS) use Visual Builder, where a page is an experience made of sections and elements, and blueprints save reusable layouts. On CMS 13, Visual Builder content can also render server-side through ASP.NET MVC without Optimizely Graph.

Publishing control is in core on both. Approval sequences route content through reviewers before it goes live, and on PaaS, projects group changes to many items and publish them together, by hand or on a schedule. Optimizely Forms runs on PaaS for MVC-based sites only; on SaaS, the SDK provides forms as a rendering API.

Payload gives editors blocks, drafts and versions, autosave, scheduled publishing and Live Preview of the draft in your own frontend. Payload’s enterprise page lists a Visual Editor as coming soon. An access rule can limit who publishes, and named approval stages are Payload’s enterprise Publishing Workflows or custom work. Grouped releases like Optimizely projects have no core equivalent in Payload; per-document scheduling covers simpler launches.

Content APIs and delivery

Optimizely Graph is the GraphQL delivery layer for CMS 13 and CMS (SaaS). Its default limit is 1,500 requests per 10-second window, or 150 queries per second, with cache hits not counted. On PaaS, the REST Content Delivery API continues, and its version 13 removes the Content Definitions and Content Management APIs. CMS (SaaS) added a CMS REST API v1, generally available from May 2026, and webhooks in August 2026. Optimizely publishes an official JavaScript SDK for headless frontends.

Payload runs inside the Next.js application. Server components read content through the Local API without an HTTP request, REST and GraphQL are generated for other clients, and capacity depends on your hosting.

Languages and roles

On PaaS, Optimizely supports fallback and replacement languages: content can fall back to another language when a translation is missing, or always show in a replacement language. On SaaS, fallback languages are recursive. Access rights grant read, create, change, delete, publish and administer per role, which on SaaS is an Opti ID role, and a change log records edits.

Payload localizes at the field level with fallback, and one document holds every language; independent publishing per locale is an experimental beta. Access control is a set of TypeScript functions per collection, document, field and operation, so rules that depend on the document’s data are code the team reviews.

Hosting

CMS 12 and 13 run on Optimizely’s DXP cloud, built on Azure, where Optimizely manages availability, networking and logging, and teams deploy to Integration, Preproduction and Production environments. Both can also be self-hosted, with the customer or a partner running the infrastructure. Some CMS 13 features need DXP: the embedded DAM is not supported on premises, and Opal Chat for CMS 13 requires DXP hosting. CMS (SaaS) is run by Optimizely.

What can stay when the CMS changes

The suite products connect to the CMS in different ways, and that decides which of them survive a move.

Experimentation and personalization can stay. Web Experimentation and Personalization run from a snippet added to the site’s head, and Feature Experimentation runs through SDKs in the application. None of them requires Optimizely CMS, so a Payload site can keep using them. Content variations are a CMS 13 and CMS (SaaS) feature, and experiments built on them move to the snippet or the SDKs.

Commerce Connect stays with the CMS. Commerce Connect 15 is “a composable ecommerce add-on to Optimizely CMS 13” and requires CMS 13, so replacing the CMS means replacing the commerce platform too. Configured Commerce, Optimizely’s B2B product, has its own built-in Spire CMS and can optionally be paired with CMS 12.

Payload’s own options are an official ecommerce plugin, marked beta in its documentation, a commerce engine connected by integration, and static A/B testing as an enterprise feature.

Decision matrix

Situation	Optimizely route	Payload fit
Server-rendered .NET site with Optimizely Forms	Stay on CMS 12, or move to CMS 13	Weak: Razor views need a new frontend or Payload’s API, and forms are rebuilt
Commerce Connect storefront	CMS 13 with Commerce Connect 15	Weak: commerce is replaced too
B2B on Configured Commerce	Configured Commerce with Spire CMS, or paired with CMS 12	Out of scope: storefront content sits with the commerce product
Headless site on CMS 12 with a Next.js frontend	CMS (SaaS), or CMS 13 with Graph	Strong: the frontend can be adapted
Web Experimentation programme on the site	Keep it with either CMS	Keep it: the snippet runs on a Payload site
Experiments built on content variations	CMS 13 or CMS (SaaS)	Partial: rebuild them on the snippet, SDKs or static A/B testing
Many languages with replacement-language rules	CMS 12 or 13	Partial: field-level fallback; replacement rules are custom work
Content model reviewed in pull requests	CMS 13 content types in C#	Strong: collections in TypeScript

Cost inputs

Optimizely publishes no prices: its plans page says “Every Optimizely plan is individually packaged.” Its usage metrics define what a contract can count, including content items, page views, API calls per year, DXP environments, Opal credits and named users. Its standard online terms bill overage on agreed usage volumes at twice the unit price; the Order Form takes precedence if it differs. CMS (SaaS) includes three instances in its base package, with more at extra cost. Opal features use credits.

Payload’s open-source core is MIT-licensed, with no core licence fee; enterprise features, support and Payload hosting are separate commercial agreements. The budget goes to hosting, the database and storage, building and maintaining the application, and the tools that replace the Optimizely products in use. Price both over the same period, with the same traffic, editors, languages and environments.

Exit

CMS 12 and 13 export content as Episerver Data (.episerverdata) packages, and Graph or the Content Delivery API can pull content for a scripted move. On CMS (SaaS), package export runs from the UI only, content types export as a JSON manifest, and some PaaS content, including personalized content and visitor groups, cannot be imported into SaaS. Leaving Payload, the content is already in a database you control and the schema is in your repository.

What a move to Payload rebuilds

Plan for content types as collections; blocks and Visual Builder elements and blueprints as Payload blocks; Razor views as frontend components if the frontend moves to Next.js, or adapted queries if a headless frontend stays; Optimizely Forms; approval sequences and projects as access rules, Publishing Workflows or custom work; audiences and content variations; Graph or Search & Navigation queries; and redirects for every URL that changes. The migration guide covers the content model, the import and the cutover, and WAYF’s CMS replatforming service covers the move.

Two decision scenarios

Both scenarios are illustrative. They are not client projects.

A retailer on Commerce Connect. A consumer brand runs its storefront on CMS 12 with Commerce Connect, server-rendered in Razor, with Optimizely Forms for customer service and four languages. Editors plan seasonal launches as projects. The recommendation is to stay with Optimizely: keep CMS 12 while it is maintained, or move to CMS 13 with Commerce Connect 15. On Payload, the commerce platform and the forms would be replaced, and the Razor views would need a new frontend or a new data source.

A headless marketing site with an experimentation team. A software company runs its marketing site and docs on CMS 12, delivered through the Content Delivery API to a Next.js frontend. It publishes in English and German with one approval step, and its growth team runs Web Experimentation tests every week. Its developers write TypeScript. Payload fits: collections and access rules live in the Next.js repository, the frontend’s queries are adapted to Payload’s Local API, and the Web Experimentation snippet stays in the site’s head. Price it against CMS (SaaS), which keeps the content with Optimizely and moves delivery to Graph.

A short evaluation checklist

Run these with your own estate before choosing:

• Products. List every Optimizely product on the contract, and mark which the website uses.
• Version and hosting. Record the CMS version, whether it runs on DXP or self-hosted, and the .NET version.
• Editing. Note whether editors use On-Page Editing, Visual Builder, projects and approval sequences.
• Delivery. Record whether pages render server-side or through the Content Delivery API or Graph.
• Experiments. Check whether tests run through the Web Experimentation snippet, Feature Experimentation SDKs or content variations.
• Commerce. Note whether Commerce Connect or Configured Commerce sits on the same platform.
• Cost. Pull the usage metrics and volumes from your order, and price Optimizely and Payload with its replacement tools over the same period.

A note on our position

WAYF is an official Payload partner and top contributor, so we have an interest in this comparison. We recommend staying with Optimizely when commerce, Visual Builder and several suite products work together, and the matrix above is how we would decide.

If you choose Payload, WAYF’s Payload development service covers the build. For a move from Optimizely, start with our Optimizely migration guide and plan the replatforming around the products in active use.