Sitecore to Optimizely Migration: A Composite Case Study

This is an illustrative composite scenario. It does not describe any single real organization; it generalizes patterns we see repeatedly across mid-market and enterprise replatforming projects. Numbers are presented as typical ranges, not one client's exact figures.

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

1. 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.
2. 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.
3. 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.
4. 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.
5. Phase the cutover. Move low-risk sections first to validate your pipeline before high-traffic, high-revenue URLs are exposed.
6. 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.

Much of this discovery can be front-loaded before a vendor or budget is locked in. That pre-migration content intelligence — the URL universe, the schema inventory, the taxonomy audit — is exactly what Replatform Radar's Sitecore-to-Optimizely guidance is built to surface, so the surprises show up in a planning document instead of a post-launch traffic chart. For other platform pairs, start at the migration hub.