Optimizely to WordPress: A Migration That Proves My Whole Argument

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

I have spent this whole series saying the same thing in different ways: platforms do not usually die of technical failure. They die of ownership. Someone buys the company, and your content strategy becomes a line item in an integration plan you were never consulted about. I watched it happen to every serious ECM platform of the 2000s — Vignette, Interwoven, FatWire, Stellent — all acquired, absorbed, renamed, retired.

Optimizely is the cleanest living proof of that argument, and it is worth understanding before you migrate, because it tells you something about what you are standing on.

The CMS most people mean when they say “Optimizely CMS” is Episerver. Episerver was a well-regarded .NET DXP for years. Then Episerver acquired the experimentation company Optimizely — and took its name. The CMS you are running was renamed after the company that bought into it. That is not a criticism of the software, which is capable. It is a live illustration of the exact pattern I keep warning about: the thing on your invoice can change its name, its owner, and its priorities without asking you. When I choose a platform for a client, I ask who can buy this company and what happens to my content the day after. Optimizely CMS is a platform where that already happened.

So let me lay out the move. Plainly first, then technical near the end.

Why teams leave Optimizely CMS for WordPress

• Licensing and total cost. Optimizely CMS is a licensed .NET DXP — licence fees, .NET developers, and heavier hosting. For a content website, WordPress collapses that cost dramatically.
• The cost-to-usage gap. Like every DXP, Optimizely is priced for personalization, experimentation, and orchestration. Many organisations use a sliver of that and pay for all of it. That gap is usually what starts the conversation.
• Specialist dependency. Content types, blocks, and templates are developer work. Editors cannot self-serve the way they can on WordPress with ACF and the block editor.
• Ownership and direction. As above — a platform that has already been through an acquisition and rename is a platform whose future you do not control. WordPress cannot be acquired.

The personalization audit — do it before you fear the loss

Optimizely’s real value-add is experimentation and personalization. Before you migrate, run the honest audit I recommend for every DXP: how many experiments are actually running, how many personalization rules are actually live, how many audience segments actually exist? I have watched clients buy sophisticated personalization engines and then never build more than three segments — paying for capability they never used, and paying again for the specialists to operate it. If your audit comes back nearly empty, the thing you are afraid of losing in the migration is a thing you already abandoned. That reframes everything: you are not giving up a capability, you are stopping paying for one that has been sitting idle.

And if experimentation is load-bearing — genuinely driving revenue through active tests — then either keep Optimizely’s experimentation product as a separate layer on top of WordPress (it started life as a standalone A/B tool and still works that way), or adopt a dedicated WordPress experimentation tool. Scope that as its own project, not a footnote to the content migration.

How I plan an Optimizely migration

1. Inventory the model — page types, block types, the content tree, properties, media, languages, and the experimentation/personalization configuration.
2. Prune the accumulated page types and properties.
3. Map to WordPress — page types to custom post types, block types to Gutenberg blocks or ACF flexible content, the content tree to page hierarchy or flattened collections, properties to ACF, media to the media library.
4. Build the empty target and validate with editors.
5. Transform against a snapshot, dry-run on staging, repeat.
6. Redirects before cutover.
7. Cut over, then watch.

The Technical Part: Where an Optimizely Migration Actually Breaks

The specifics that decide the outcome.

Page types, block types, and the content tree

Optimizely content is a tree of content items, shaped by strongly-typed page types and block types defined in .NET code. Page types map to custom post types and their properties to ACF. Block types — Optimizely’s reusable content components, placed into content areas — are the equivalent of every other system’s components/dynamic zones, and they carry the same warning: no clean 1:1 in WordPress. Decide, per block type, whether it becomes a Gutenberg block/pattern or an ACF flexible-content layout, and handle each by hand. Content areas (the regions where blocks are arranged, sometimes with display options) have to be rebuilt as WordPress block content or flexible-content fields. This is where the hours hide; inventory every block type and content-area usage first.

Shared blocks — blocks stored in the tree and reused across many pages — need special handling: import each shared block once, then reference it from every page that used it via your two-pass ID map, rather than duplicating its content everywhere.

The content tree and URLs

The tree drives Optimizely’s URL structure. Preserve each item’s path — it is your redirect map, and these are the pages carrying your SEO equity. Map genuinely hierarchical content to WordPress page hierarchy and flat collections to posts-plus-taxonomy; do not force everything into a tree just because Optimizely stored it that way.

Extraction: don’t reach for the export package

Optimizely’s built-in export produces an .episerverdata package designed for Optimizely-to-Optimizely transfer — useless for WordPress, the same way Strapi’s and Sitecore’s native packages are. Use the Content Delivery API (REST) or Content Graph (GraphQL) to pull content as JSON, or read a database snapshot directly. Property values and block references have to be reassembled from those sources. Freeze a snapshot, respect pagination, reconcile totals, and transform against the frozen copy.

Experimentation and personalization do not migrate

Optimizely’s experiments, feature flags, and personalization rules are not content and do not come with the migration. There is no WordPress equivalent for the experimentation engine or the visitor-profile store. Per the audit above: if they are idle, let them go and document the decision; if they are active, plan a separate experimentation layer (Optimizely’s own product kept as a standalone tool, or a WordPress A/B solution) as its own project. Do not let this hold the content migration hostage.

Templates and rendering do not migrate

Optimizely templates are .NET/Razor (or a headless front-end via Content Graph). Presentation is code, not content — it does not migrate. The front-end must be rebuilt as a WordPress theme or blocks. If a headless front-end consumes Content Graph today, it will need to switch to the WordPress REST API or WPGraphQL, with a completely different response shape — budget for that data-layer rebuild.

Multi-language content

Optimizely handles languages as language branches on content items. Choose the WordPress target — multisite, Polylang, or WPML — before transforming, and handle items translated in some languages but not others so you do not create orphans. Decide the multilingual architecture first; it is an architecture problem, not a translation problem.

Media and assets

Optimizely’s assets (media in the tree, and the DDS/blob storage behind them) need downloading and re-importing into the WordPress media library, with every reference rewritten — property references and, critically, the media embedded inside rich-text and content-area blocks. The in-content references are the ones that quietly keep pointing at the old system.

Users and roles

Optimizely’s roles and its access-rights model do not map one-to-one to WordPress, and password hashes are not portable. Plan for password resets and a hand-built role mapping, and accept that fine-grained item-level access collapses into WordPress’s coarser role model.

My honest closing position

I did not choose Optimizely to end this series by accident. It is the platform that most cleanly demonstrates the argument underneath all of these guides: the software was fine, and the thing that changed was ownership — a rename, a new owner, a new direction, arriving without your say. That is the risk you carry on any single-vendor platform, and it is the risk WordPress structurally cannot pose, because there is no company to buy.

Do the audit before you fear losing the personalization — most of it is usually idle. Map the block types by hand, preserve the tree for redirects, rebuild the presentation, decide the multilingual model first. And remember why the destination is WordPress: not because it does more, but because nobody can buy it out from under you, and code you write on it today will still run in ten years.

That is the whole argument of this series, stated one last time through the one migration that proves it. The format keeps changing — CD-ROM, Flash, ECM, DXP, headless. The job never does: get the content to the right place, keep it accurate, keep it alive. Put it somewhere no acquisition can quietly retire, and you have done the only part of this that has ever really mattered.

One More Thing: But Can’t WordPress Just Do What Optimizely Does?

Here is the question I get the moment someone decides to move: if we leave Optimizely, are we handing WordPress a job it can’t do? No. And the people who still picture WordPress as “just a blog” are about to be surprised — because the three things you think only a DXP can do, WordPress does too.

It models structured content like a DXP. Optimizely’s page types and block types are strongly-typed content components. WordPress models the same shapes with custom post types, ACF, and native blocks — page types become CPTs, block types become Gutenberg blocks or ACF flexible content — and editors touch all of it without a .NET developer in the loop.

It runs headless too. Optimizely’s Content Graph is its GraphQL delivery layer; WordPress has had the REST API in core since late 2016 — nearly a decade of production hardening — plus WPGraphQL, now backed by Automattic and heading for canonical status. Point your existing headless front-end at WPGraphQL instead of Content Graph and it barely notices the CMS changed underneath it.

It handles experimentation — honestly. If A/B testing is genuinely load-bearing, keep a dedicated experimentation tool on top; that is a real answer, not a dodge. But the CMS underneath does not have to be a DXP to allow it. Run the audit first — most of the personalization you are afraid to lose is already idle.

And WordPress gains you things a licensed DXP never will:

• A real commerce engine. WooCommerce, not a bolt-on.
• Editorial power for humans — block editor, media library, revisions, roles, and a plugin economy for SEO, forms and memberships you never rebuild from scratch.
• No per-seat pricing, no usage meter. Add a hundred editors; the bill doesn’t move.
• Ownership. And here Optimizely makes my argument for me: it is the acquisition — Episerver’s own name got bought out from under it. WordPress can’t be. Nobody owns it, so nobody can rename it, reprice it, or retire it while you are standing on it.

That’s the surprise. Moving off Optimizely isn’t a downgrade — it’s stepping off a platform whose name and owner already changed without your say, onto one nobody can ever take.