Optimizely CMS 11 end of support: upgrade, or unbundle the DXP?

On April 10, 2026 Optimizely published a major version policy that put CMS 11 outside the versions it actively maintains. The policy is worth reading in its own words, because it switches nothing off. Optimizely says it “actively monitors, triages, and fixes severe bugs and security issues for the current major version and one prior major version”, which today means CMS 13 and CMS 12, and it says plainly that it “does NOT enforce end-of-life through forced upgrades, disabled environments, or removal of access to older versions.” A CMS 11 site keeps running. What it stops getting is routine bug fixes and patches, with severe security issues handled case by case.

That leaves four ways forward, and the CMS versions are a different question from the platform question. You can stay on CMS 11 without routine patches, with severe security issues handled case by case. You can upgrade to CMS 12 and target .NET 10, which lands you on a currently maintained version and a framework covered by Microsoft’s support lifecycle through November 2028; that framework date does not promise CMS 12 vendor maintenance through 2028. You can go to CMS 13, which Optimizely says is technically supported directly from CMS 11. Or you can treat the work as the moment to move the content layer off the suite.

This guide covers all four, because the version decision and the replatforming decision get bundled together in most conversations and they have different evidence behind them. Verified against Optimizely’s own documentation on 15 September 2026.

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.

The upgrade routes, and what separates them

A lot of Optimizely upgrade advice, including an earlier version of this guide, treats CMS 12 as a compulsory stepping stone to CMS 13. Optimizely’s own CMS 13 FAQ says otherwise: “A direct upgrade from CMS 11 to CMS 13 is technically supported. The level of effort is similar to upgrading 11 to 12, as the majority of work involves upgrading the .NET framework.” It adds one qualifier: “For highly customized solutions, breaking the upgrade into smaller steps may still be advisable.”

Set against that, the step-by-step documentation is written as Upgrade to CMS 13 from CMS 12, and its prerequisites list “Existing CMS 12 solution – Your application should already be running on Optimizely CMS 12.” So the vendor supports the direct route and documents the staged one. If you take the direct route you are following a runbook written for a different starting point, which is a project-management fact rather than a technical blocker.

CMS 12 is somewhere you can stop. This is the part that has changed since most Optimizely upgrade advice was written. In May 2026 Optimizely confirmed on its developer site that “CMS 12 is fully compatible with .NET 10”, recommending EPiServer.Cms.Core 12.24.0 or higher and EPiServer.Cms.UI 12.34.4 or higher. In August 2026 it closed the remaining gap: Commerce 14 supports .NET 10 from version 14.46.0, so “the full Optimizely stack, including both CMS 12 and Commerce 14, can now run on .NET 10.” Microsoft supports .NET 10 into November 2028. CMS 12 is also one of the two versions Optimizely actively maintains.

That matters because .NET 8 and .NET 9 reach end of support on November 10, 2026. A CMS 12 estate still targeting .NET 8 has a framework deadline this year regardless of which CMS version it eventually lands on, and that deadline is met by retargeting .NET 10 rather than by jumping to CMS 13.

Note one contradiction in the sources, because you will meet it. The CMS 13 FAQ states that “CMS 12 will not officially support .NET 10” and presents CMS 13 as “the required upgrade path” for teams wanting .NET 10. That FAQ carries its own warning that it is a snapshot as of the CMS 13 launch on March 31, 2026, and it has been overtaken by the two announcements above. Where a launch FAQ and a later product announcement disagree, the later one is the one to plan against.

What the CMS 13 route adds

Going to CMS 13 brings work that the CMS 12 route does not, and the search dependency is the item most likely to be missed in an estimate.

	CMS 11 → CMS 12	CMS 11 → CMS 13
Framework	.NET 10 supported, .NET 8 still runs	.NET 10 required; packages fail dotnet restore on earlier versions
Search & Navigation (EPiServer.Find)	Keeps working	Not supported. Migration to Optimizely Graph is mandatory
Optimizely Graph	Not required	”Strongly recommended and positioned as required from a sales perspective”
Maintained by Optimizely	Yes, one of two current versions	Yes, current version

Budget for the tooling to be thinner than you expect on the CMS 13 route. Optimizely’s upgrade guide says “Previous migration tools for Optimizely CMS have been deprecated” and points at GitHub Copilot for AI-assisted modernization, and the FAQ adds that “Migration tooling is being explored” with “no specific tool … announced for the initial launch.”

On search, Optimizely’s answer is unambiguous: “Search & Navigation is not supported in CMS 13. Switching to Optimizely Graph is mandatory.” There is no formal end-of-life for Search & Navigation, and Optimizely says customers migrating to CMS 13 “will typically have a 6-month overlap period, with extensions available on request.” If your site leans on Find for site search, faceting, synonyms or best bets, that migration is a project line of its own, and it is the clearest reason a highly customised estate might take CMS 12 first.

CMS 13 also brings API changes to plan for, including PageReference giving way to ContentReference and the removal of ContentArea.FilteredItems. Visual Studio 2026 or an equivalent IDE with .NET 10 support is listed as a prerequisite.

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 third-party estimates published for 2026, read again on 15 September 2026 and listed in the sources below, give a rough 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 are aggregator and reseller estimates rather than anything Optimizely publishes, so treat them as a bracket for planning and put your own renewal figure next to them. 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 actively maintained; CMS 11 severe issues considered case by case	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.

For a product-by-product comparison of Optimizely CMS 12, CMS 13 and CMS (SaaS) with Payload, including which Optimizely products can stay when the CMS changes, see Optimizely vs Payload.

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 shape of the change is clear even though the size of it is not. You remove a quote-only suite licence and take on Payload, which is free to licence, plus the specific tools you chose to keep and the infrastructure you run. How far that moves your total depends almost entirely on section 2 of the worksheet. A team that used Optimizely mostly as a CMS is replacing one licence with infrastructure. A team replacing experimentation, personalization and commerce as well is buying several services and paying for the integration that joins them, which narrows the gap and can close it.

To turn that into a number rather than a direction, you need three figures side by side: your actual renewal quote, the annual cost of each replacement tool at your usage, and the one-time build. Anyone quoting a saving before they have all three, this agency included, is estimating the first two from averages.

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.

The decision worksheet

None of the four routes can be priced from the outside. What decides it is a set of facts about your own estate, and they are facts your team already holds across a few systems rather than findings that need research. Writing them down in one place is what turns the argument from opinion into arithmetic.

Copy this and fill it in before you take a quote from anyone, us included.

OPTIMIZELY ROUTE WORKSHEET                      Date: ............  Owner: ............

1. WHERE YOU ARE
   CMS major + patch version ............................................
   .NET target today (Framework / 6 / 8 / 9 / 10) .......................
   PaaS (DXP) or on-premises ............................................
   Commerce Connect version, if any .....................................
   Renewal date .................  Notice-to-cancel deadline ............

2. MODULES IN USE               (last 90 days, measured from usage rather than the contract)
   Content Cloud (CMS) ........................... used / not used
   Experimentation ............................... live experiments in last 90 days: ....
   Personalization ............................... active visitor groups / rules: ....
   Commerce Cloud ................................ SKUs: ....  orders/month: ....
   Opal AI features .............................. used / not used
   Which of the above would you re-buy today? ...........................

3. CUSTOM EXTENSIONS
   Custom content types / blocks ......... count: ....
   Custom scheduled jobs ................. count: ....
   Custom admin or edit-mode UI (Dojo) ... count: ....
   Third-party add-ons in use ............ list: ....................................
   Anything depending on PageReference or ContentArea.FilteredItems? ....

4. SEARCH                                    (decides whether CMS 13 is cheap or costly)
   Using Search & Navigation / EPiServer.Find? ..........................
   If yes: site search / faceting / synonyms / best bets / autocomplete — which? ....
   Already on Optimizely Graph? .........................................
   Who owns the relevance tuning today? .................................

5. CONTENT AND MEDIA
   Content items (approx) ....  Media assets (approx) ....  Locales ....
   Largest content type by instance count ...............................
   Where media is stored today ..........................................
   Content model documented anywhere? ...................................

6. INTEGRATIONS AND THEIR OWNERS       (name a person per row, not a department)
   System .................. Direction .......... Owner .......... Still needed?
   ...................................................................
   ...................................................................

7. REDIRECTS AND SEO
   Existing redirect count ..............................................
   Who owns the redirect map ............................................
   Organic traffic as % of total ........................................
   Top 50 URLs by traffic — listed? .....................................

8. WHAT YOU CANNOT ANSWER YET
   ...................................................................
   (this box is the useful one; anything left here is a scoping risk, not a detail)

The same worksheet, filled in

The example below is illustrative. It is a composite written to show how the answers point at a route, not a client engagement, and the numbers in it are invented for that purpose.

Line	Answer	What it implies
CMS version	11.21.3, on-premises	Outside active maintenance since the April 2026 policy
.NET target	.NET Framework 4.8	Framework work is unavoidable on any upgrade route
Renewal	14 months out, 90-day notice	Time to decide properly; no forced decision this quarter
Experimentation	2 experiments in 90 days	Thin usage; a standalone tool would cover it
Personalization	4 visitor groups, reported none edited in a year	Verify usage in logs before calling it dormant
Commerce	Not licensed	Removes the largest unbundling risk
Custom blocks	38 content types, 12 blocks	The main modelling effort on any route
Dojo admin UI	3 custom property editors	Carries to CMS 13 unchanged, so not a differentiator between the routes
Search	Find, with synonyms and faceting	Mandatory Graph migration on the CMS 13 route
Content	~9,000 items, 22,000 assets, 3 locales	Migration is scripted, not manual, at this size
Integrations	CRM (owner named), ERP (owner left in March)	One unowned integration is the top scoping risk
Redirects	~4,000, owned by the agency, contract ending	Ownership has to move before anything else happens

Read that worksheet and the routes separate on their own. The Find line means the direct jump to CMS 13 adds mandatory Graph migration work alongside the framework upgrade, while synonyms and faceting have to be rebuilt rather than moved. Two lines that look expensive turn out not to be: the custom property editors carry across either way, and 9,000 items is a scripted migration. The same estate reaches a supported framework and a maintained CMS version by going to CMS 12 on .NET 10, which follows Microsoft’s framework lifecycle through 2028 without promising CMS 12 maintenance for that full period. The reported low experimentation and personalization usage makes the unbundling question worth asking at the next renewal, but the logs should confirm it before anyone scopes on that assumption.

Change two answers and the conclusion changes with them. An estate with a live experimentation programme and a large catalogue on Commerce Cloud has a strong case for staying on the suite, and the worksheet is what tells you which of those you are.

What evidence to insist on before anyone quotes

Three of the boxes above move an estimate by a factor rather than a percentage: your experimentation and personalization usage over the last 90 days, whether Find is doing anything a plain index could not, and who owns each integration today. Each one is easy to fill in from memory and expensive to get wrong, so pull them from logs, admin screens and a named person rather than from the contract or a previous agency’s documentation. An estimate built on the other five sections plus guesses in these three is a number that will move.

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 fourth is timing, and it is new. Until recently the argument for leaving included a version treadmill: CMS 11 out of maintenance, CMS 12 a stepping stone, CMS 13 the only destination. With CMS 12 running on .NET 10 and sitting inside Optimizely’s actively maintained set, an estate can upgrade to CMS 12, reach a framework covered by Microsoft’s lifecycle through November 2028, and decide about the platform at a renewal of its choosing rather than under a deadline. The framework lifecycle does not guarantee CMS 12 vendor maintenance for that full period. Deciding later, with the worksheet filled in, is a legitimate outcome of reading this page.

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, and you want your content model in code and your front end on Next.js, a composable Payload stack removes the suite licence and replaces it with infrastructure, the tools you choose to keep, and the integration work to join them. Whether that lands cheaper depends on how many of those tools you need, which is what section 2 of the worksheet tells you.

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. What changed for Optimizely CMS 11 on April 10, 2026?

   There is no switch-off date. On April 10, 2026 Optimizely published a major version policy under which it actively monitors, triages and fixes severe bugs and security issues for the current major version and one prior, which are CMS 13 (generally available since March 31, 2026) and CMS 12. CMS 11 sits outside that set, so it no longer receives routine bug fixes or patches. Optimizely states that it does not enforce end-of-life through forced upgrades, disabled environments or removal of access, so CMS 11 sites keep running.

3. Do you have to upgrade to CMS 12 before CMS 13?

   No. Optimizely's CMS 13 FAQ states that a direct upgrade from CMS 11 to CMS 13 is technically supported, and that the level of effort is similar to upgrading 11 to 12 because most of the work is the .NET framework upgrade. It adds that for highly customized solutions, breaking the upgrade into smaller steps may still be advisable. The step-by-step documentation is written for CMS 12 as the starting point, so the direct route follows a runbook aimed at a different origin.

4. Does Optimizely CMS 12 support .NET 10?

   Yes. Optimizely confirmed in May 2026 that CMS 12 is fully compatible with .NET 10, recommending EPiServer.Cms.Core 12.24.0 or higher and EPiServer.Cms.UI 12.34.4 or higher. In August 2026 it confirmed Commerce 14 support for .NET 10 from version 14.46.0, so the full CMS 12 and Commerce 14 stack can run on .NET 10. This matters because .NET 8 and .NET 9 reach end of support on November 10, 2026, while .NET 10 is supported into November 2028. That is Microsoft's framework lifecycle; it does not guarantee Optimizely CMS 12 maintenance through 2028. CMS 12 is currently one of Optimizely's two actively maintained major versions. The CMS 13 launch FAQ says CMS 12 will not officially support .NET 10; that FAQ is a snapshot from March 2026 and the later announcements supersede it.

5. What happens to Optimizely Search & Navigation (Find) in CMS 13?

   It is not supported. Optimizely states that Search & Navigation is not supported in CMS 13 and that switching to Optimizely Graph is mandatory. No formal end-of-life date has been announced for Search & Navigation, and Optimizely says customers migrating to CMS 13 typically have a six-month overlap period with extensions available on request. If your site relies on Find for site search, faceting, synonyms or best bets, that migration is a separate project line and it is the main cost the CMS 13 route adds over the CMS 12 route.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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

• FAQs for CMS v13.0.0 — direct CMS 11 to 13 upgrades, Graph, Search & Navigation, .NET. Carries its own note that it is a snapshot as of March 31, 2026. Read 15 September 2026
• Upgrade to CMS 13 from CMS 12 — prerequisites, breaking changes, deprecated tooling
• Optimizely CMS 12 Now Fully Supports .NET 10 — 25 May 2026
• Optimizely Commerce 14 Now Supports .NET 10 — August 2026
• Optimizely CMS 11 release notes — carries the CMS major version policy announcement dated April 10, 2026
• Optimizely CMS 12 release notes
• Episerver reintroduces itself as Optimizely
• Optimizely plans and pricing
• Vendr: Optimizely pricing
• CheckThat.ai: Optimizely pricing 2026
• Payload GitHub
• Payload
• Figma: Welcoming Payload