Sitecore to Optimizely Migration: A Composite Case Study

Before we start: nobody in here is a real person. This is a composite, stitched together from the same patterns we watch play out over and over on mid-market and enterprise replatforming projects (the kind where everyone swears their situation is unique, and then it isn't). No single organization is being described. The numbers are typical ranges, not one client's actual figures.

Somewhere in this company's Sitecore install lives a personalization layer that exactly two people ever fully understood, and both of them took new jobs about a year ago. That's not a joke, it's the actual starting condition for a migration a lot of teams are staring down right now: a decade of content, tens of thousands of URLs, and the institutional memory walking out the door while the licensing bill keeps climbing. So the move to Optimizely gets pitched as the calm, sensible option, two mature .NET platforms, basically a lateral step. And I'll be honest, I used to nod along to that framing too.

Then I watched what actually happens when you trust that framing, and the reason this case study exists is one assumption that keeps wrecking otherwise careful teams: that the export you get out of the old CMS contains all your URLs. It never does. So let me walk you through a composite of the companies I've seen make this exact jump, what quietly fell through the floor, and the handful of things that saved them. Grab a coffee. This one's more fun than it sounds.

Context

Picture a mid-market B2B software company: roughly 40,000 to 60,000 URLs, a marketing team of about a dozen, and a decade of accumulated content on Sitecore XP. The site had grown organically: multiple site definitions, a sprawling template inheritance chain, and a personalization layer that only two people fully understood. Licensing and hosting costs were climbing, the in-house Sitecore expertise had largely left, and leadership wanted a cleaner path to composable, cloud-first delivery.

The decision to move to Optimizely (formerly Episerver) was driven less by feature envy and more by operational reality: simpler content authoring, a more approachable developer model, and a roadmap the team believed they could actually staff. On paper this is a lateral move between two mature .NET CMS platforms. In practice, the mental models differ enough that a naive lift-and-shift breaks in predictable, expensive ways.

What broke

The failures clustered into four areas. None were exotic; all were avoidable with earlier discovery.

Redirects and URL structure

Sitecore's item tree and Optimizely's page-tree produce different default URL shapes, and the old site relied heavily on Sitecore aliases plus a third-party URL-rewrite module. When the team exported the content tree, a meaningful slice of URLs, commonly 15% to 30% in projects like this, did not map one-to-one. Aliases weren't in the item export at all, so they were silently dropped. The first crawl after launch surfaced thousands of soft 404s and redirect chains three and four hops deep. Rankings for long-tail pages dipped for several weeks before the redirect map was rebuilt from server logs and an old crawl snapshot.

The single most damaging assumption was that "the CMS export contains all our URLs." It never does. Aliases, vanity URLs, and rewrite rules live outside the content tree.

Content model mismatches

Sitecore templates with deep inheritance and shared base fields don't translate cleanly to Optimizely's block-and-content-type model. Fields that were single rich-text blobs in Sitecore needed to become structured blocks in Optimizely to be reusable, but the migration script treated them as opaque HTML. The result: pages rendered, but authors couldn't edit components independently, and the promised authoring improvements evaporated. Datasource-driven renderings mapped awkwardly onto blocks, and several multi-value fields collapsed into comma-delimited strings that then had to be re-parsed by hand.

Lost SEO and AEO signals

Structured data was the quiet casualty. The old site emitted JSON-LD for articles, FAQs, and breadcrumbs through Sitecore renderings that weren't part of the content export. Post-migration, those schema blocks simply weren't emitted, which degraded rich-result eligibility and answer-engine visibility precisely when the site was already destabilized by redirects. Canonical tags defaulted to Optimizely's generated URLs rather than the historical canonical set, briefly creating duplicate-content ambiguity. Hreflang annotations for the two non-English markets were regenerated from a different locale map and pointed at pages that hadn't launched yet.

Taxonomy gaps

Sitecore taxonomy lived in a combination of the tree, a taxonomy module, and some free-text fields. Optimizely's categorization model is flatter and more explicit. Terms that authors had treated as interchangeable turned out to be three separate vocabularies, and about a fifth of tagged content lost its facet associations, breaking on-site filtering and several dynamic listing pages.

What worked

The recovery, and the parts that went right from the start, offer the real lessons.

Log-based URL inventory. Once the team stopped trusting the CMS export and instead assembled a URL universe from 12 months of server logs, the analytics property, and an independent crawl, the redirect map became reliable. Every source URL got an explicit destination or an intentional 410.

Content-type workshop before mapping. A two-day session where authors and developers agreed on the target Optimizely content types, and which Sitecore fields became blocks versus properties, prevented a second round of remodeling.

Schema as a first-class deliverable. Rebuilding JSON-LD as reusable Optimizely blocks, validated in a staging crawl, restored rich-result eligibility within the first maintenance sprint.

Phased cutover by section. Migrating the blog and resource center ahead of the core product pages contained blast radius and gave the team a rehearsal before touching high-value URLs.

Lessons

The content export is not your URL inventory. Aliases, vanity URLs, rewrite rules, and personalized variants live outside the tree. Reconstruct the full URL universe from logs and crawls before you write a single redirect.

Map content models by behavior, not by field name. A rich-text field in Sitecore may need to become several structured blocks in Optimizely. Decide this with authors in the room, or you'll ship a worse editing experience than you started with.

Treat structured data and canonicals as migratable assets. They rarely ride along in the export. Inventory every schema type, canonical rule, and hreflang pair, then rebuild and validate them explicitly.

Audit taxonomy for hidden vocabularies. Free-text tags and tree position often encode multiple overlapping systems. Normalize them before migration, not after listing pages break.

Phase the cutover. Move low-risk sections first to validate your pipeline before high-traffic, high-revenue URLs are exposed.

Baseline before you touch anything. Capture rankings, crawl stats, structured-data coverage, and Core Web Vitals pre-launch, so you can distinguish a real regression from noise.

Before you make this move

A short pre-flight checklist that would have prevented most of the pain above:

Assemble a complete URL inventory from server logs, analytics, XML sitemaps, and an independent crawl, not just the CMS export.

Enumerate all Sitecore aliases, vanity URLs, and rewrite rules and decide each one's fate.

Run a content-type mapping workshop and document field-to-block decisions before development starts.

Catalogue every JSON-LD type, canonical pattern, and hreflang pair, and assign an owner to rebuild each in Optimizely.

Normalize taxonomy into explicit vocabularies and map facets to Optimizely categories.

Capture a pre-migration baseline of rankings, indexation, structured-data coverage, and performance.

Plan a phased, section-by-section cutover with a rollback path.

Schedule a post-launch crawl within 24 hours and a redirect-chain audit within the first week.

So here's what I actually think, no hedging: this move is worth making, and almost none of the damage is inherent to the platforms. It's inherent to when you go looking. Every wound in this story, the dropped aliases, the rich-text blobs that couldn't be edited, the JSON-LD that stopped emitting, the tags that turned out to be three vocabularies wearing one coat, was findable weeks before anyone touched production. If I were running this, I'd spend the first fortnight rebuilding the full URL universe from logs and refusing to write a single redirect until it reconciled. That one habit prevents most of the rest.

Front-load the ugly discovery and the migration turns boring, which is the highest compliment I can pay it. That's exactly what Replatform Radar's Sitecore-to-Optimizely guidance is built to force out into daylight. You want the surprises showing up in a planning doc, not three weeks after launch when the traffic chart dips and everyone quietly stops returning your calls. And remember those two people who understood the personalization layer and then left? The whole point is to write it all down before the next two do. Migrating a different pair of platforms? Start at the migration hub.