Sitecore to Optimizely: A Pre-Go-Live Breakage Audit

"It's basically a field-mapping exercise." I have heard that sentence in more Sitecore-to-Optimizely kickoffs than I can count, usually from someone very smart, and usually right before the part where it stops being true. Both platforms model content as tidy structured items, so of course you assume the job is lining fields up and pouring one into the other. Then you meet the parts that have no matching cup on the far side: Sitecore's item-tree URLs that Optimizely's per-page routing won't reproduce, personalization rules with nowhere to land, media hiding behind GUID paths like /-/media/, rendering parameters that quietly shed their presentation logic. None of it shows up in a staging demo. It surfaces two days after go-live, as lost traffic and pages that just won't load. This audit is the list of what actually breaks, and how to catch each one 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

So here is what I actually think: every one of these breakages is catchable before it happens, and the reason teams miss them is that they trust the CMS export instead of the live site. The export tells you what the content model believes about itself. The live site, its real URLs, its embedded media references, its personalization surface, tells you what visitors and Google actually hit. Treat that second thing as the source of truth. A crawl-based content-intelligence pass can score each page for redirect risk, duplicate-URL risk, orphaned media, and lost presentation logic, which turns "we think it's fine" into a per-URL migrate, rewrite, or 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.

And if you take only one thing from me, take this: run the diff while both systems are still standing side by side. That field-mapping exercise everyone promised you really is simple, right up until you go reaching for the cup on the other side that was never poured. Find the missing ones now, on a quiet Tuesday, when each is a ticket you close, instead of on go-live day, when each is a traffic drop you have to explain in a meeting.