Moving from Optimizely CMS to SitecoreAI: a guide for CMS 11 and CMS 12 teams

If your site runs on Optimizely CMS 11 or 12, the next few months will force a decision. CMS 11 dropped off Optimizely’s maintained list in April. CMS 12 is still on it, but on 10 November 2026 Microsoft stops supporting .NET 8, the runtime in its system requirements. Standing still now has a cost.

We wrote this for digital and marketing leads in the Gulf and Egypt who are weighing SitecoreAI against an Optimizely upgrade. It sticks to the practical parts: the dates, the four realistic options, what actually moves when you change platform, and the Optimizely details that make these projects bigger than they first look.

The dates

This is what Optimizely and Microsoft have published, in order.

Nothing is switched off on any of these dates, and your site keeps serving pages. What changes is that when a vulnerability turns up in the runtime or in an old package, nobody is obliged to fix it. Optimizely’s official CMS 12 requirements still list .NET 8, while a May 2026 post on Optimizely World, the company’s developer community, says CMS 12 runs on .NET 10 with recent packages. Whichever you go by, a runtime change means retesting the whole site, add-ons included. For banks, government entities and airlines, an unsupported runtime tends to surface in the next security audit, and that usually sets the real deadline.

Four ways forward

Each of these is a project with code changes, testing and a release. They differ in how much changes, and in which vendor you are tied to afterwards.

We would not tell every Optimizely customer to switch. If Experimentation and Commerce sit at the centre of how you trade, CMS 13 keeps them in one stack, and that is worth something. The comparison only means anything when all four options are priced against your own site, which is what the decision memo described below is for.

What happens to each part of an Optimizely site

Almost everything in Optimizely has an equivalent in SitecoreAI. The effort goes into deciding what is worth carrying over.

Six details that make Optimizely migrations bigger than they look

A crawl of the live site sees pages. It cannot see how they are built, and that is where Optimizely estimates usually go wrong. Check these six before anyone quotes you a number.

Links inside rich text

When an editor links to another page in a rich text field, Optimizely stores a permanent link in the form ~/link/<GUID>.aspx and only turns it into a readable URL when the page renders. Export the raw field and every one of those links points nowhere. They all have to be resolved and rewritten during the migration, or the new site goes live with quiet 404s.

Media URLs

Shared files live under /globalassets/. Files attached to a single page or block live under /contentassets/, followed by an ID. Search engines have indexed many of those images, and other sites may link to your PDFs, so they need redirects or matching paths on the new site.

Blocks inside blocks

A page has a content area, the content area holds a block, and that block has a content area of its own. After a few years of editors building pages, two or three levels are common. Decide where to flatten them before you map a single item, because every extra level adds component work.

Display options

Editors often set block widths such as full, half and one third through the display options on a content area. Each of those choices needs a home in the new design, as a component setting or a layout rule.

Personalized blocks

A visitor group applied to one block inside a content area creates a variant that only some visitors see, and a crawler never does. List them from the CMS, check which ones still change results, and rebuild only those.

Fallback languages

Fallback and replacement settings can serve English content on Arabic URLs, so the Arabic site looks bigger than it is. Count the pages that have a real Arabic version before you budget for translation.

How we run the move

We use the same method and toolkit as ArcShift™, our SitecoreAI migration accelerator. There are five stages.

1. Scan the site and decide

We take the inventory from the CMS itself. That covers every page and block type with its page count, how deep the content areas nest, and every visitor group, form, add-on, integration and redirect. From that we write a decision memo that prices all four options, staying with Optimizely included. It also shows how many page types you could retire, which visitor groups still move a metric, and how far your Arabic content has drifted.

2. Extract and map the content

Content comes out through the Content Delivery API or Optimizely Graph where they are installed, or from an export. It is mapped to SitecoreAI templates and imported in batches, each Arabic page with its English pair, and permanent links are rewritten on the way. Sitecore’s own migration tool, SitecoreAI Pathway, has an “Any website” option that crawls up to 200 URLs of a public site and, since version 1.4, brings the images too. That suits a small campaign or country site. A full Optimizely estate needs scripted extraction so that blocks, metadata and language pairs come through intact.

3. Rebuild the front end

Razor views and controllers become Next.js components, built from a bilingual component library on an Arabic-first starter, so right-to-left layout, Arabic typography and hreflang work from the first sprint. Your design tokens come across as they are, so the site still looks like your brand.

4. Rebuild personalization, search and integrations

Visitor groups that still change results are rebuilt in SitecoreAI personalization, and the rest are retired. Search is rebuilt and tested in Arabic and English with real queries from your logs. We record an analytics baseline before launch, since your history stays in the old tool, then re-point CRM, commerce, DAM and anything that ran as a scheduled job.

5. Go live

Optimizely URLs carry language prefixes, URL segments, simple addresses and the two media paths. Each one gets a redirect, and a script checks the whole map before launch. Visual, accessibility and performance tests run in both languages. After launch we watch traffic, rankings and conversions daily until they settle.

Arabic

On many Optimizely sites, Arabic is the branch that fell behind. Pages went live in English first, fallback filled the gaps, and right-to-left fixes piled up in the CSS. A migration is the cheapest moment to put that right. In SitecoreAI, Arabic is a language version of the same item, components are built and tested in both directions once, and brand kits carry a glossary so translations keep your names and terms. Before launch, have a native editor read your most visited pages and try site search in Arabic. Our guide to Arabic-first Sitecore has the full checklist.

Comparing cost

Put the same four lines in your spreadsheet for each option, over three years: licences and subscriptions, hosting and operations, the migration itself, and the cost of running and improving the platform afterwards.

Then check that each option includes the same things. Optimizely now bundles Graph into the CMS 13 licence and its DAM into CMS 13 and the SaaS CMS, while Opal, its AI agent platform, is paid for in credits. On the Sitecore side, a Forrester Total Economic Impact™ study commissioned by Sitecore reports a 371% three-year return for a composite organization, with page creation time down 60% and developer time on integrations down 50%. Vendor studies are a useful sanity check. Your memo should run on your own numbers.

Questions we get asked

Can SitecoreAI Pathway migrate an Optimizely site?

For a small site, yes. Its “Any website” option crawls up to 200 URLs and, since version 1.4, imports the images. A full Optimizely estate needs scripted extraction through the Content Delivery API, Optimizely Graph or an export, otherwise blocks, metadata and language pairs get lost.

We are still on CMS 11. Should we upgrade first?

Only if you are staying with Optimizely, which supports a direct upgrade from CMS 11 to CMS 13. If you are leaving, extract from CMS 11 as it is. Upgrading a platform you are about to retire is money you will not get back.

How long does a move to SitecoreAI take?

It depends on the number of page and block types, languages, integrations and visitor groups, so the decision memo gives a dated plan for your site. As a reference point, Optimizely puts an upgrade from CMS 12 to CMS 13 at two to six months on average.

Can we keep Optimizely Web Experimentation?

Yes. It runs on any website through its snippet, so it can stay in place during and after the move. Two personalization engines running side by side get expensive, though, so it is worth choosing one.

Will we lose search rankings?

Not if every old URL redirects to its new home, media paths included, metadata and structured data come across, and Arabic and English keep their hreflang pairs. We check the redirect map by script before launch and watch Search Console closely afterwards.

What if we also run Optimizely Commerce?

Then commerce comes first in the plan. Commerce Connect runs inside the same application as the CMS, so the catalogue, cart and checkout need a decision before the content move is scheduled. The memo covers both.

Is SitecoreAI right for every Optimizely customer?

No. If you use Experimentation, Opal or Commerce heavily, CMS 13 may serve you better. The memo makes the case for each option, staying with Optimizely included.

Sources

• Optimizely: CMS 11 release notes and CMS major version policy
• Optimizely: CMS 13 general availability release notes
• Optimizely developer documentation: FAQs for CMS 13
• Optimizely developer documentation: System requirements for CMS 12
• Optimizely World: Optimizely CMS 12 now fully supports .NET 10
• Optimizely World: Optimizely CMS (SaaS)
• Microsoft .NET Blog: .NET 8 and .NET 9 end of support
• Sitecore documentation: Select a source for migration
• Sitecore changelog: SitecoreAI Pathway 1.4
• Sitecore: Forrester Total Economic Impact™ of SitecoreAI
• Sitecore changelog: Brand kit glossary for custom translation