Migrating from Optimizely to Payload: a 2026 guide to unbundling the DXP

Optimizely CMS 11, the version that shipped under the old Episerver name, went out of support on April 10, 2026. Nothing switches off, because Optimizely lets customers keep running older versions, but CMS 11 sites no longer receive routine bug fixes or security patches. Optimizely still maintains CMS 12 and the newer CMS 13, so teams on those have runway, and the pressure falls on anyone still on CMS 11 or earlier. For them the forced step is the upgrade to CMS 12, which brings the move from .NET Framework to .NET Core, a substantial piece of work before you touch any of your own code. That upgrade is often the moment to stop and ask a bigger question than which version to run next.

The bigger question is about the bill. Optimizely is an enterprise platform, and the renewal that lands each year reflects that. Before signing it again, it is worth separating two things that usually get bundled together: how much of the platform you use day to day, and how much of the price is buying capability you have switched on.

This guide works through that. It covers what Optimizely is, what a move of the content layer to Payload involves, what changes on cost, and the cases where Optimizely is worth keeping. We are an official Payload partner and we build composable stacks, so our leaning is clear, and the piece is just as direct about the parts of Optimizely that Payload does not replace.

Optimizely is a DXP, not a CMS

Optimizely is a digital experience platform (DXP): a single suite that bundles content management together with experimentation, personalization, and commerce. That puts it in a different category from a content management system like Kentico or Umbraco. Compare it to a standalone CMS and you miss what the price buys.

The history explains the shape of it. The company was Episerver, a well-regarded .NET CMS, until it acquired the experimentation company Optimizely in 2020 and took that name in early 2021. The rebrand marked a deliberate move away from being a CMS vendor toward selling optimization as a service. Today the platform is sold in modules: Content Cloud is the CMS, Commerce Cloud handles e-commerce, and Intelligence Cloud covers experimentation and personalization, with the Opal AI features layered on top.

Most customers buy a combination rather than the whole thing, and that is where the money goes. The CMS at the centre is capable and mature. The premium sits in the optimization and commerce modules around it, and in the integrated suite that ties them together under one vendor and one contract.

What you are actually paying for

Optimizely does not publish prices. Every deal is a custom quote shaped by traffic, the modules you take, and the size of your organization, so the figures below come from third-party analyses rather than a rate card, and your own number may differ.

With that caveat, the public estimates for 2026 give a useful sense of scale. Smaller deployments tend to start around $40,000 to $60,000 a year. Mid-market installations commonly land between $65,000 and $120,000. Enterprise contracts that combine several modules regularly reach $120,000 to $200,000, and the largest run well past that. Those numbers cover platform licensing alone. Implementation, integration, and ongoing optimization frequently add another 100 to 200 percent in the first year, and heavy use of the Opal AI features, which run on a consumption-based credit model, can add 20 to 40 percent more.

Those figures put a sharp edge on one question. If your team logs into Optimizely mainly to publish and manage content while the experimentation and commerce modules sit largely idle, a large part of the spend is buying capability you never switch on. That is where unbundling the suite starts to pay off.

What Payload is, and what it is not

Payload is an open-source CMS and application framework built on Next.js and TypeScript. It is worth being equally clear about what it is not: Payload is a content and application platform, not a DXP. It does not ship experimentation or personalization engines in the box. A move from Optimizely to Payload is a move from one bundled suite to a composable setup, where the CMS is one part and anything else you need is a deliberate, separate choice.

For the content layer itself, Payload brings a few things Optimizely teams tend to notice quickly. The content model is written in TypeScript, in your repository, under version control, so it goes through pull requests and ships in your normal deploy pipeline rather than living in platform configuration. Since version 3.0, released in November 2024, Payload installs directly into a Next.js application, which puts your CMS and your front end in one project and one deploy. A Local API lets server code read from the database without an HTTP round trip. The licensing is MIT and free to self-host, so the six-figure platform line disappears and you pay for the infrastructure you run.

On the question of backing, which matters when you leave a large vendor, Payload was acquired by Figma in June 2025 and continues as an actively developed open-source project with a substantial company behind it.

The composable part is the rest of the picture. Where you do use Optimizely’s optimization and commerce, you replace those with dedicated tools: an experimentation platform such as GrowthBook or a similar service, a commerce engine such as Medusa, and a personalization approach that fits your data. You assemble the capabilities you use instead of renting all of them as a suite. That assembly is real work, and it is the main tradeoff to weigh.

Optimizely DXP versus a Payload composable stack

	Optimizely (DXP suite)	Payload composable stack
What it is	Bundled DXP: CMS, commerce, experimentation	CMS and app framework, plus chosen tools
Licensing	Quote-only; commonly $65K to $200K+/yr	Payload free (MIT); pay per chosen tool
Core stack	.NET	Next.js, TypeScript
Content model	Configured in the platform	Defined in code, version-controlled
Experimentation	Intelligence Cloud (included)	Separate tool (e.g. GrowthBook)
Commerce	Commerce Cloud (included)	Separate engine (e.g. Medusa)
Front end	Razor / headless	Next.js (React)
Lock-in	Single vendor, single contract	You own each piece
Support status	CMS 13 and 12 maintained; 11 out of support	Active

Suite on one side, assembly on the other. The decisive line is what comes bundled: capabilities that ship inside Optimizely turn into things you choose and integrate yourself on Payload. For a team that needs only part of the suite, that means lower cost and more control. For a team that uses most of it, it means more integration to own.

There is also a middle path that the all-or-nothing framing tends to hide. Optimizely’s experimentation product is sold on its own and runs on any front end, so you can move the content layer to Payload and keep that one module as a standalone tool. You can also run Optimizely headless behind a Next.js front end without leaving the platform at all. Neither is a full move to Payload, and both are legitimate; sometimes the right answer is a partial step rather than a clean break.

The migration in practice

A content-layer migration from Optimizely to Payload follows a recognizable path. The early decisions about scope matter more than the mechanics, because they determine how much of the surrounding suite you are replacing.

Decide what you are replacing

Before any content moves, take stock of which Optimizely clouds you use and how deeply. Inventory the CMS content types, blocks, and templates, the .NET version you are on, and every integration the platform currently handles. Then mark which capabilities are in active use: live experiments, personalization rules, commerce catalogues, and so on. A site that is Content Cloud and little else is a straightforward content migration. A site running active experimentation and a commerce catalogue is a larger composable project, and being clear about that at the start keeps the estimate real.

Model content types as Payload collections

Optimizely structures content as content types and blocks, configured in the platform. Payload structures it as collections, each one a TypeScript config that declares its fields, relationships, and access rules in a single file.

A typical Optimizely article content type maps across like this:

import type { CollectionConfig } from 'payload'

export const Articles: CollectionConfig = {
  slug: 'articles',
  admin: { useAsTitle: 'name' },
  fields: [
    { name: 'name', type: 'text', required: true },
    { name: 'urlSegment', type: 'text', required: true, unique: true },
    { name: 'teaser', type: 'textarea' },
    { name: 'mainImage', type: 'upload', relationTo: 'media' },
    { name: 'contentArea', type: 'blocks', blocks: [/* your block types */] },
  ],
}

Optimizely’s content areas and blocks map naturally onto Payload’s blocks field, which is the closest structural match and usually where the modeling effort concentrates. Personalized or experiment-driven content variations are not a Payload concern; those move to whichever experimentation tool you adopt, and Payload serves the base content the tool then varies.

Move the content and media

With collections in place, a migration script reads from Optimizely and writes through Payload’s Local API. Optimizely exposes content through its Content Delivery API, which you read, reshape, and create in Payload:

import payload from 'payload'

for (const item of optimizelyContent) {
  await payload.create({
    collection: 'articles',
    data: {
      name: item.name,
      urlSegment: item.routeSegment,
      teaser: item.teaserText,
      contentArea: toBlocks(item.mainContentArea),
    },
  })
}

Media files transfer to whatever storage backend you pick, and the script updates their references along the way. Routing the import through Payload’s API instead of writing to the database directly means each record is validated and run through hooks, surfacing broken legacy data while the migration runs rather than after go-live.

Reconnect the capabilities you kept

This stage is what makes an Optimizely migration different from a plain CMS move. For each suite capability you decided to keep, you wire in its replacement: an experimentation service in front of the Next.js front end, a commerce engine such as Medusa behind a shared content contract, a personalization layer fed by your own data. One point to be clear about: experiments and their history do not transfer. You stand up the new experimentation tool and rebuild the programme from your current hypotheses, rather than porting past results across. A team that ran little beyond the CMS skips most of this. For one that leaned on the suite, it becomes the bulk of the project, which is why the scoping decision up front carries so much weight.

Rebuild the front end, then protect SEO

Because Payload sits inside a Next.js app, the front end is a React build that consumes content from the Local API, and Optimizely’s Razor or head-specific templates are reimplemented as React components. Once content and front end are in place, every old Optimizely URL needs a 301 redirect to its new path, and metadata, canonical tags, sitemaps, and structured data all carry across. Then the new site is checked against the old one page by page, covering content parity, redirects, integrations, and Core Web Vitals, so the search visibility you have built survives the move.

Timelines and cost

How long this takes depends on how much of the suite you are replacing, far more than on the CMS itself. A content-led migration where Optimizely was used mainly as a CMS tends to run three to six months. A migration that also rebuilds experimentation and commerce as composable services runs longer, into the six-to-twelve-month range and sometimes beyond for a large catalogue. Read those as rough brackets. An experienced team tends to come in lower, as the Ingersoll Rand build below shows.

On cost, the change is stark. You remove a quote-only six-figure suite license and replace it with Payload, which is free, plus the specific tools you chose to keep and the infrastructure you run. For a team that used Optimizely mostly as a CMS, the recurring spend can drop by a large margin. For a team replacing the full suite, the saving is smaller, because composable is lighter than a DXP license but not free: an experimentation service, hosting for a commerce engine like Medusa, and the infrastructure to run it all carry their own recurring cost, alongside the one-time integration work. The comparison only becomes concrete once you know which capabilities you are keeping and what their replacements cost.

One practical point on timing. Optimizely contracts are annual or multi-year, with no monthly option, and they auto-renew unless you give notice, commonly around three months before the renewal date. That makes the move easiest to time to a renewal. Starting mid-term means paying for the existing license and the new build at the same time, and missing the cancellation window can lock you in for another year.

We have delivered enterprise migrations under exactly this kind of deadline pressure. Ingersoll Rand’s China sites were running on Oracle Content Manager when Oracle moved to discontinue it, with a fixed switch-off date and no slack in the schedule. We delivered a new Payload platform in five months, carrying thousands of pages and tens of thousands of media assets and redirects across more than 20 brand tenants, and kept the live platform running throughout. The Ingersoll Rand case study sets out the full picture.

When Optimizely is worth keeping

Optimizely is a real DXP, and unbundling it is not always the right call. A few situations make staying the better decision.

The strongest is heavy use of experimentation and personalization. If your teams run a steady programme of experiments, act on personalization rules daily, and treat optimization as a core function rather than an occasional project, Intelligence Cloud is doing work Payload does not, and pulling it into separate tools is a meaningful undertaking with its own running costs.

Deep reliance on Commerce Cloud points the same way. A large, tightly integrated commerce catalogue sitting on the same platform as your content is real value, and replacing it with a composable commerce engine is a project in its own right rather than a by-product of the CMS move.

A single-vendor requirement is the third. Regulated enterprises and large procurement functions often value one accountable supplier with a contractual SLA over a stack of assembled tools, and that preference is legitimate. A composable setup trades it for control and lower licensing, in exchange for owning the integration and several vendor relationships.

The decision comes down to usage and appetite. If you run the full suite and value the single-vendor model, Optimizely is doing what you pay it for. If you mostly run the CMS, or you want your content model in code and your front end on Next.js, and you are willing to assemble the few other pieces you need, a composable Payload stack is lighter and far cheaper, and it is the kind of build we do.

How WAYF can help

WAYF is an official Payload partner and Top Contributor, building Payload and Next.js platforms for Fortune 500 companies, public institutions, and fast-growing teams. We also build composable stacks, pairing Payload with Next.js or Astro on the front end and Medusa for commerce, which is precisely the shape an Optimizely unbundling tends to take. Much of our work is migration, including moves off Oracle Content Manager, WordPress VIP, and Wagtail.

If you are weighing another Optimizely renewal against unbundling the suite, we will look at which modules you use and tell you whether a composable Payload stack fits, including the cases where staying on Optimizely is the better call.

Book a call and we will give you a straight answer on whether moving off Optimizely makes sense for you.

FAQ

1. Is Optimizely the same as Episerver?

   Yes. The company was Episerver until it acquired the experimentation firm Optimizely in 2020 and rebranded to Optimizely in January 2021. The CMS many teams still call Episerver is now Optimizely Content Cloud, part of the wider Optimizely DXP.

2. When did Optimizely CMS 11 go out of support?

   Optimizely CMS 11 went out of support on April 10, 2026. Optimizely maintains the current major version and one prior, which are CMS 13 (generally available since March 31, 2026) and CMS 12. Optimizely does not force upgrades, so CMS 11 sites keep running, but without routine bug fixes or security patches.

3. How much does Optimizely cost?

   Optimizely is quote-only, so there is no public rate card. Third-party 2026 estimates put mid-market deployments around $65,000 to $120,000 a year and enterprise multi-module contracts at $120,000 to $200,000 and beyond, before implementation, which often adds 100 to 200 percent in the first year.

4. Is Payload a DXP or a CMS?

   Payload is a CMS and application framework, not a full DXP. It manages content and powers applications, but it does not bundle experimentation, personalization, or commerce. Those come from separate, best-of-breed tools in a composable setup.

5. Can you migrate from Optimizely (Episerver) to Payload?

   Yes. You map Optimizely content types and blocks to Payload collections defined in TypeScript, move content and media through Payload's API, rebuild the front end in Next.js, and add any experimentation or commerce tools you need as separate services. Old URLs get 301 redirects to preserve SEO.

6. What replaces Optimizely's experimentation and personalization if you move to Payload?

   Dedicated tools. Experimentation moves to a service such as GrowthBook, commerce to an engine such as Medusa, and personalization to a layer driven by your own data. You adopt the specific capabilities you use rather than a full suite.

7. How long does an Optimizely to Payload migration take?

   A content-led migration usually runs three to six months. One that also rebuilds experimentation and commerce as composable services runs six to twelve months or more.

Sources

• Optimizely supported versions
• Optimizely CMS 11 release notes
• Umage: Optimizely CMS 11 is out of support
• Episerver reintroduces itself as Optimizely
• Optimizely plans and pricing
• Vendr: Optimizely pricing
• CheckThat.ai: Optimizely pricing 2026
• Payload GitHub
• Payload
• Figma: Welcoming Payload