A Sitecore-to-Optimizely migration rarely fails on the big, obvious things — the content model gets mapped, the templates get rebuilt, the pages render. It fails on the quiet mismatches: Sitecore's item-tree URLs that don't survive Optimizely's page-hierarchy routing, personalization rules that have no equivalent, media that lived in the Sitecore Media Library with GUID-based paths, and rendering parameters that silently drop presentation logic. Most of these are invisible in a staging demo and only surface as traffic loss or broken pages after go-live. This audit lists what actually breaks and how to catch each item before you cut over.
Why these two platforms diverge in ways that matter
Sitecore and Optimizely (formerly Episerver) both model content as structured items, so teams assume the migration is mostly a field-mapping exercise. The structural mismatch is what bites. Sitecore stores everything as items in a content tree with display names, item names, and configurable URL rules; presentation is layered on via layouts, renderings, placeholders, and rendering parameters. Optimizely uses strongly typed content types, blocks, and a page hierarchy where the URL segment is a property of the page. The two systems disagree about where URL logic lives, how reusable components are composed, and how personalization is expressed. Every one of those disagreements is a place breakage hides.
The seven things that break most often
- URL structure and casing. Sitecore URLs derive from item names and any configured aliases or URL rewrites; Optimizely builds them from URL segments per page. Trailing slashes, casing, and encoded characters frequently differ, producing near-duplicate URLs that 404 or split ranking signals.
- Sitecore aliases and 301 chains. Aliases and existing redirect modules don't transfer. If they aren't inventoried, you lose vanity URLs and inherit redirect chains that Google treats as soft errors.
- Media Library paths. Sitecore serves media from
/-/media/or/~/media/with GUID-based references. Optimizely's asset handling and CDN paths differ, so hard-coded image and PDF links in rich text break even when the files themselves migrate. - Personalization and A/B rules. Sitecore's rules engine, profiles, and pattern cards have no one-to-one Optimizely equivalent. Migrating the "default" variant silently drops every personalized experience.
- Rendering parameters and placeholder logic. Presentation details set per-item in Sitecore (a component variant, a column width, a data source) often get flattened when components become Optimizely blocks.
- Multisite and language fallback. Sitecore's language fallback and site-definition-based routing differ from Optimizely's site and culture settings. Fallback content that rendered in Sitecore can go blank.
- Datasource references and shared content. Sitecore renderings point at datasource items reused across pages. If those relationships aren't preserved as Optimizely blocks or content references, you get orphaned or duplicated content.
A comparison of where the logic lives
| Concern | Sitecore | Optimizely | Migration risk |
|---|---|---|---|
| URL derivation | Item name + URL rules/aliases | Per-page URL segment | Casing, slashes, lost aliases |
| Reusable components | Renderings + datasources | Blocks + content areas | Broken references, duplication |
| Presentation config | Rendering parameters | Block properties/templates | Silent loss of variants |
| Media | Media Library GUID paths | Assets/CDN paths | Broken embedded links |
| Personalization | Rules engine, profiles | Visitor groups | No 1:1 mapping |
How to catch each one before go-live
- Build a full URL inventory from production, not the CMS. Crawl the live Sitecore site and pull server logs. This captures aliases, rewrites, and real inbound URLs the content tree won't show you. Map every live URL to its Optimizely destination and confirm the redirect resolves in one hop.
- Diff old vs. new URL casing and slashes programmatically. Generate the Optimizely URL for each migrated page and compare it byte-for-byte against the Sitecore URL. Flag anything that differs so you can add a redirect rather than discover the 404 in Search Console weeks later.
- Scan rich text for hard-coded media and internal links. Search migrated body content for
/-/media/,/~/media/, and absolute internal links pointing at the old host. Each is a broken link waiting to render. - Inventory personalization explicitly. List every rule, pattern card, and A/B test with its business owner. Decide per item whether it maps to an Optimizely visitor group, gets rebuilt later, or is retired — and document that decision so nobody assumes it "came across."
- Validate datasource-to-block mapping with counts. Compare the number of shared datasource items in Sitecore against the blocks created in Optimizely. A large drop usually means references collapsed into duplicated inline content.
- Test language fallback with real multilingual pages. Pick pages that relied on fallback and confirm they render the fallback language in Optimizely rather than empty regions.
Do the diff before you migrate, not after
The common thread is that every breakage is detectable from a pre-migration inventory that treats the live site — its URLs, media references, and personalization surface — as the source of truth rather than the CMS export. A crawl-based content-intelligence pass can score each page for redirect risk, duplicate-URL risk, orphaned media, and lost presentation logic, turning "we think it's fine" into a per-URL migrate/rewrite/kill decision. That is the core of what Replatform Radar's Sitecore-to-Optimizely guide is built around, and the same approach applies to any replatform.
Go-live day is the worst possible time to learn which URLs 404 and which personalized experiences vanished. Run the diff while you still have both systems standing, and every surprise becomes a ticket instead of a traffic drop.