Migrate from Optimizely CMS before the next upgrade
Optimizely CMS 11 is out of support now that CMS 13 has shipped, and CMS 13 requires .NET 10. For most Episerver-era sites that upgrade is a rebuild in all but name. If you are rebuilding anyway, rebuild in Astro or Next.js, with your content in Sanity or Payload and every URL kept.
Yegparian PLLC (opens in a new tab)Signs it is time to leave Optimizely
Optimizely, and Episerver before it, has run many organisations’ .NET sites for years. These are the moments IT and marketing teams tell us it stopped fitting.
Your site still runs on CMS 11
Since April 2026 Optimizely maintains only CMS 13 and 12. CMS 11 and earlier get no bug fixes or patch releases, apart from severe security issues.
You are on CMS 12 and .NET 8
.NET 8 support ends on 10 November 2026, and CMS 12 will not officially support .NET 10. Staying on a supported runtime means moving to CMS 13.
The upgrade is a rebuild anyway
CMS 11 runs on .NET Framework and IIS. Newer versions run on ASP.NET Core, so templates, start-up code, authentication and add-ons all need rework.
Your search and APIs change in CMS 13
Search & Navigation is not supported in CMS 13, and the Content Delivery API was not available at launch. Search and headless front ends move to Optimizely Graph.
Only an Optimizely partner can change it
Page types, blocks and .NET customisations live in a system few developers know well. Small changes queue up behind a specialist partner and its sprint plan.
What happens to your Optimizely features
Pick what your site relies on today. Each feature becomes part of the site itself, a focused tool, or turns out not to be needed.
- Page types and propertiesSanity schemas or Payload collectionsEvery page type and its properties move into a schema in code, with content read from Optimizely and moved by script.
- Blocks and content areasPage-builder blocksEach block type becomes a block editors compose pages from, built once in code so every page stays on brand.
- Media and assetsAssets in the CMSImages and files are re-uploaded with their folders and alt text, served resized from a CDN. An existing DAM can be connected instead.
- On-page editingLive preview while editingEditors see the real page as they type. In Sanity they can click any text on the preview to edit it.
- Optimizely FormsA form built into the siteValidated on the server, filtered for spam and sent to your inbox, CRM or marketing automation platform.
- Visitor groupsPersonalisation where it paysThe audit lists the groups in use today. Those worth keeping move to edge logic or a dedicated personalisation tool, with consent.
- Search & NavigationHosted searchSite search runs on a hosted index such as Algolia, or on your own database with Payload, instead of moving to Graph.
- Language branchesBuilt-in localisationTranslations live per field or per document in Sanity or Payload, with their own URLs and hreflang.
- Approval sequencesDrafts, roles and reviewDrafts, version history and roles come built in. Multi-step approval is set up around how your team signs off today.
- Optimizely CommerceCommerce, scoped separatelyCatalogues and checkout move to Shopify or another commerce platform behind the same front end. The audit says what moves where.
What changes when you leave Optimizely
Astro and Next.js decide how pages are built. Sanity and Payload are where your team edits. Optimizely still wins some rows, and the audit weighs them.
| Feature | Astro + Sanity | Next.js + Payload | Optimizely |
|---|---|---|---|
| Security and licensing | |||
| No .NET server or IIS to patch | Node.js app for /admin | ||
| Security updates for your version | Severe issues only on CMS 11 | ||
| No CMS licence fee | Plan-based | ||
| Self-hosted, open-source CMS | Hosted by Sanity | ||
| Content and editing | |||
| Structured, reusable content | |||
| Live preview while editing | |||
| In-context page editing | Click-to-edit preview | Live preview | |
| Multi-step approval workflow | Set up per project | Set up per project | |
| Multilingual content | |||
| Performance and upkeep | |||
| Pages served pre-built from a CDN | With output caching or a CDN | ||
| Built-in personalisation | Via a dedicated tool | Via a dedicated tool | |
| Major upgrades without a rebuild | New .NET runtime in 12 and 13 | ||
Sites we've already moved
Different stacks for different jobs: a law firm on Next.js and Payload, a residential launch and our own studio on Astro and Sanity.
Yegparian PLLC
WordPressNext.js + Payload
An Austin trial litigation firm. Practice areas, matters and insights are Payload collections, and every page is pre-rendered and served from the edge.
yegparianpllc.com (opens in a new tab)25 Cuba
WordPressAstro + Sanity
A new residential address in Canary Wharf. Apartments, amenities and galleries are edited in Sanity, and the site ships as static Astro pages.
25cuba.com (opens in a new tab)Celerart
WebflowAstro + Sanity
Our own studio site. Every one of the 164 old URLs was carried over or redirected, and all content is now edited in Sanity.
celerart.com (opens in a new tab)
How we move an Optimizely site
Your Optimizely site stays live until the new one is ready. The switch is a DNS change, not a weekend of downtime.
Audit
Audit
We crawl every URL, list every page type, block, form, visitor group, add-on and integration, and export your rankings. You also see which licensed features are actually in use.
Content model
Content model
Page types, blocks and content areas become a clean schema in Sanity or Payload, shaped around how your editors actually work.
Content import
Content import
Content, media and language branches move by script, from the database, an export package or the Content Delivery API where it is installed. Rich text is converted and internal links rewritten.
Front end
Front end
We rebuild the design in Astro or Next.js: the same look, or a refresh if one is due. Every template is checked against the old one.
Redirects and launch
Redirects and launch
Every old URL, simple address and existing redirect gets a permanent redirect to its new address. Metadata, sitemaps and structured data are compared before the DNS switch.
Handover
Handover
Your IT and marketing teams get a walkthrough of the new editor and hosting. Then the Optimizely environments can be switched off before the next renewal.
Questions about leaving Optimizely
It is a fair option, and the audit will compare both. A direct upgrade from CMS 11 is technically supported, but it means moving from .NET Framework to .NET 10, reworking templates and add-ons, and moving search to Optimizely Graph. Moving to Astro or Next.js costs a similar effort and ends the licence and the major-version cycle.
Each swaps one platform you upgrade for another. Sitecore and Umbraco bring their own major-version jumps, and WordPress brings a server and a plugin stack to patch. A headless setup keeps the structured content your page types already have and serves pages pre-built from a CDN.
Not if the move is planned. Every URL keeps its address or gets a permanent 301 redirect, built from your page URLs, simple addresses and existing redirects. Titles, descriptions, structured data and sitemaps are carried over and checked before launch, and we watch Search Console for the weeks after the switch.
By script: from the database, an export package, or the Content Delivery API if your site has it. Pages, blocks, content areas, media and language branches become structured content in Sanity or Payload, and internal links are rewritten to the new URLs.
We scope them one by one. Forms are rebuilt into the site, visitor groups worth keeping move to edge logic or a personalisation tool, and a shop moves to Shopify or a similar platform behind the new front end. The audit tells you what moves where.
It depends on the number of page types, blocks, sites, languages and integrations. After the audit you get a fixed scope and timeline, and the Optimizely site stays live until launch day.
Keep it protected until launch: apply the last updates available for your version, keep Windows, IIS and .NET patched, restrict access to the editing interface and put a web application firewall in front of the site. The migration removes the risk; it does not cover the months before launch.
