Sitecore to WordPress: What Happens to All That Personalization

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

Sitecore is one of the genuinely capable platforms, and I want to say that clearly before I say anything else. It owned the .NET enterprise world for years and it led the market on personalization — recognising a visitor by location and history and reshaping the page for them in real time. That was real engineering, and it was ahead of a lot of what came after.

But Sitecore inherited what I think of as the ECM disease, in a newer and better-marketed wrapper. The licences are enormous. The implementations take a year. You need certified specialists for routine work. And I have watched, more than once, a client buy a personalization engine and then never build more than three audience segments. They are paying for capability they will not use, and paying again in the specialists required to operate it.

That gap — between what Sitecore can do and what a given organisation actually does with it — is usually what starts the conversation about WordPress. Here is how I think about it, plain terms first.

Why teams leave Sitecore for WordPress

• The cost-to-usage gap. Sitecore’s price is justified by personalization, experimentation, and omnichannel orchestration. If you are using a fraction of that, you are buying a machine to solve a problem you do not have. That is the single most common reason I see.
• Specialist dependency. Routine content and layout changes require certified Sitecore developers. Editors cannot self-serve. WordPress with ACF and blocks returns most of that autonomy.
• Implementation weight. A Sitecore build is a year-long program. A WordPress content site is a fraction of that in time and cost.
• The hiring reality. Sitecore talent is scarce and expensive. WordPress talent is everywhere.

The personalization point, from experience

I built a smart mirror for a retail brand years ago that was genuinely ahead of its time — personalization in a physical space, reshaping what it showed based on who was in front of it. So I am not dismissive of personalization; I have chased it myself and I know when it earns its cost. It earns its cost when you are orchestrating many touchpoints and the personalization drives real revenue. It does not earn its cost when it is three segments on a brochure site that a marketing manager set up once and never revisited.

Before you migrate off Sitecore, do the honest audit: how many personalization rules are actually live, how many segments are actually in use, how much of the experimentation platform is actually running experiments? If the answer is “almost none,” then the thing you are afraid of losing in the migration is a thing you were not really using. That reframes the whole project — you are not giving up a capability, you are stopping paying for one you had already abandoned.

How I plan a Sitecore migration

1. Inventory the model — every template, every field, the item tree, layouts and renderings, media library, languages, and — critically — the personalization and experimentation configuration.
2. Prune the templates and fields that accumulated over the years.
3. Map to WordPress — templates to custom post types, fields to ACF, the item tree to page hierarchy or flattened collections, media to the media library.
4. Build the empty target and validate it 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 a Sitecore Migration Actually Breaks

The specifics. This is the section for whoever does the work.

Items, templates, and the tree

Everything in Sitecore is an item in a hierarchical tree, and its structure is defined by a template (Sitecore’s version of a content type, with fields and inheritance). Templates map to custom post types; fields map to ACF; the item tree maps to WordPress page hierarchy or, for flat collections, to posts with taxonomy. Template inheritance is a subtlety worth flagging — Sitecore templates inherit fields from base templates, so a full field list for an item means resolving its inheritance chain. Do that resolution during your model inventory, not during the transform.

Three databases, and which one is truth

Sitecore stores content across master, web, and core databases. The web database is the published version; master holds the full editing state including unpublished changes. Decide which is your source of truth — usually web for a clean published snapshot — and be deliberate about it, or you will migrate half-finished editorial work as if it were live. Field values live in an EAV-style structure (shared, versioned, and unversioned field tables), so reconstructing a full item means joining those together.

Extraction: don’t reach for the wrong tool

The .episerverdata-equivalent for Sitecore is item serialization (the Sitecore CLI, Unicorn, or TDS), and the built-in packaging is designed for Sitecore-to-Sitecore transfer — not for WordPress. Better routes are Sitecore PowerShell Extensions to serialize items to a structured format, or the Item Service / Sitecore Services Client REST API, or a direct read against a database snapshot. Whatever you choose, freeze a snapshot and transform against it repeatedly.

Layouts and renderings do not migrate

This is the one that surprises everyone. A Sitecore page’s appearance comes from its presentation details — the layout, the renderings placed into placeholders, and their datasources. This is not content; it is configuration and code. None of it migrates into WordPress. Every rendering has to be rebuilt as a WordPress block, pattern, or template, and the datasource wiring (which content item feeds which rendering) has to be re-expressed as WordPress queries or block content. Budget for rebuilding the presentation layer entirely — the content moves, the way it is assembled does not.

xDB, personalization, and experimentation are gone

Sitecore’s personalization rules, the xConnect/xDB behavioural data, and the experimentation configuration do not migrate. There is no WordPress equivalent for the xDB profile store. If personalization is genuinely load-bearing for the business, plan to rebuild it with a dedicated WordPress personalization or A/B tool, or keep a separate experimentation layer — and scope that as its own project, not a footnote. If it is not load-bearing (see the audit above), let it go and document that decision so nobody comes looking for it later.

Multi-language versions

Sitecore stores language versions per item. Choose the WordPress target — multisite, Polylang, or WPML — before migrating, and handle items that have versions in some languages but not others so you do not create orphaned translations. As always: decide the multilingual architecture first; it is an architecture problem, not a translation problem.

Media library and embedded references

Sitecore’s media library holds files as items with their own fields. Download and re-import them into the WordPress media library, and rewrite every reference — both in image/media fields and inside rich-text fields, where Sitecore embeds media by item ID or dynamic media URL. Miss the in-content references and your migrated pages quietly load images from a Sitecore instance you are about to switch off.

Users, roles, and security

Sitecore’s security model — roles, domains, item-level access — is richer than WordPress’s and does not map one-to-one. Password hashes are not portable. Plan for password resets and a hand-built role mapping, and accept that item-level security granularity will collapse into WordPress’s coarser role model.

My honest closing position

Sitecore is not a mistake to have chosen, and leaving it is not an admission of failure. For many organisations it is simply an honest reckoning: the platform was bought for personalization and orchestration the business never fully used, and the site underneath is a content website that WordPress can run for a fraction of the cost and effort.

The hard parts are real — the presentation layer rebuilds from scratch, and the personalization does not come with you. But if you do the honest audit and find that the capabilities you are “losing” were already sitting idle, then the migration is not a downgrade at all. It is the moment you stop paying for a machine you had quietly stopped using — and you move the content somewhere ordinary people can keep it accurate and alive, which, after thirty years of watching platforms come and go, is the only part of this that has never changed.

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

Here is the question I get the moment someone commits to leaving: if we drop Sitecore, do we lose the decoupled front-end and the personalization we built the whole platform around? Mostly, no — and the “mostly” is the honest part.

WordPress is not new to any of this. The REST API has shipped in core since late 2016, and WPGraphQL — now backed by Automattic and on its way to canonical status as WordPress’s GraphQL layer — gives you a query API every bit as serious as the one you are leaving. Headless WordPress with Faust.js or WPGraphQL rivals Sitecore JSS directly: the same decoupled architecture, the same React front-end on Vercel, a different engine underneath. It did not lose the enterprise argument. It grew into it.

So you have two honest paths off Sitecore:

• Traditional WordPress — the rest of this article. Give editors their autonomy back and let them publish without a certified specialist in the loop.
• Headless WordPress — keep the JSS-style decoupling; swap the backend for WordPress plus WPGraphQL, with Faust.js on top.

And the personalization? Take it back to the audit. WordPress with a personalization or A/B-testing plugin covers the personalization most organisations actually run — the three segments from that honest count. I will be straight with you: it will not replicate xDB’s full behavioural depth. But almost nobody uses that depth, and you already know whether you are the exception.

Here is what the trade adds to your toolbox:

• A real commerce engine. WooCommerce, not a bolt-on.
• A plugin economy and editorial power for humans, not just certified developers.
• No per-seat pricing, no usage meter, no enormous licence renewing every year.
• Ownership. Nobody can buy WordPress out from under you.

What you drop is the year-long implementation and the certified-specialist requirement. Sitecore is genuinely good at what it does; I said so at the top and I meant it. But “we want a decoupled site with some personalization” is not a reason to keep paying enterprise rent — it is a reason to run WordPress headless, with a much bigger toolbox behind it.