Personalization in XM Cloud: Why It Feels Different from XP

Why it feels like a downgrade from Sitecore XP (and how to build around it)

Sitecore XM Cloud is positioned as the future of Sitecore:

SaaS-first, composable, edge-ready, headless by default, and operationally simpler.

On paper, it looks like a clear evolution.

But for teams coming from Sitecore XP, one area consistently creates friction, confusion, and resistance after migration:

Personalization & Rules

What used to feel native, intuitive, and marketer-friendly in XP now feels fragmented, externalized, and far more technical in XM Cloud.

This article explains what actually changed, why it changed, what remains unresolved, and—most importantly—how to design personalization correctly in an XM Cloud world without trying to recreate XP.

The Core Problem: Why It Feels Like a Downgrade

Common symptoms teams report after migration

Organizations moving from XP to XM Cloud often experience the same pain points:

• ❌ XP-style rules are simply not there
• ❌ No condition-based personalization inside the CMS
• ❌ Marketers lose the ability to control personalization themselves
• ❌ Even small personalization changes require developers
• ❌ “Why can’t we personalize like before?” becomes a recurring conversation

This is not a missing feature

And it’s not an incomplete implementation.

It’s the result of a fundamental architectural change.

What Sitecore XP Had (and XM Cloud intentionally does not)

XP’s built-in personalization model

In Sitecore XP, personalization was deeply embedded into the platform itself:

• Rules Engine
  • Conditions such as geography, device, visit count, campaign, profile score
  • Actions like show/hide components, swap data sources, change renderings
• xDB
  • Session-based visitor tracking
  • Historical behavioural data stored per contact
• Profiles and Pattern Cards
  • Real-time scoring and classification
• On-page editor control
  • Marketers could configure personalization without developer involvement

Everything lived inside one tightly coupled system.

It wasn’t lightweight—but it was powerful and extremely marketer-friendly.

Why XM Cloud Removed It (the architectural reality)

XM Cloud is not “XP hosted in the cloud”

XM Cloud is not a lift-and-shift of XP.

It is a headless, multi-tenant SaaS CMS, deliberately designed without:

• ❌ xDB
• ❌ Session state
• ❌ Server-side visitor context
• ❌ Stateful rules evaluation

Architectural constraints that matter

The outcome:

Personalization can no longer live inside the CMS.

This is not a missing roadmap item—it’s a deliberate design decision.

What replaced XP personalization?

Instead of one monolithic platform, Sitecore moved to composable personalization.

The new reality

XM Cloud offloads personalization responsibilities to a broader ecosystem:

• Sitecore CDP
• Sitecore Personalize
• Custom frontend logic
• External analytics and decision engines

From a pure architecture perspective, this is cleaner and more scalable.

From an out-of-the-box experience, it absolutely feels like a downgrade.

Why marketers feel blocked

XP vs XM Cloud: an honest comparison

In XM Cloud:

• The CMS stores content
• The frontend decides what to render
• Personalization logic lives outside the CMS

This is not just a tooling gap—it’s a mindset shift.

The biggest unresolved issue: the roadmap gap

Despite demos, announcements, and messaging:

• There is no native rules engine in XM Cloud today
• There is no clear parity roadmap with XP-style personalization
• The solution heavily depends on external products

As a result, organizations are left asking:

How much personalization should we rebuild—and where should it live?

The wrong way to migrate (and why many teams struggle)

Common mistakes during XP → XM Cloud migrations:

• 🚫 Trying to migrate XP personalization as-is
• 🚫 Rebuilding every rule inside CDP or Personalize
• 🚫 Expecting marketers to self-serve immediately
• 🚫 Treating XM Cloud as “XP but SaaS”

This usually leads to:

• Cost overruns
• Delayed go-lives
• Frustrated business teams

The right way: redesign personalization before migration

Step 1: Define a real personalization strategy

Before implementing anything, ask:

• Which personalization actually impacts revenue or engagement?
• Which rules are truly valuable vs legacy clutter?
• What needs real-time decisioning vs delayed logic?
• Who owns personalization—marketing or engineering?

In practice, most XP implementations used less than 30% of their personalization rules effectively.

Step 2: Move personalization to the experience layer

XM Cloud works best when personalization is handled outside the CMS, closer to the frontend.

Practical patterns that work

1. Cookie-based personalization
   • Geography
   • New vs returning users
   • Consent-driven behavior
2. API-driven decisioning
   • Call CDP or Personalize APIs
   • Fetch decisions at runtime
   • Conditionally render components
3. Edge middleware (advanced setups)
   • Vercel or Netlify middleware
   • Request-time personalization
   • No CMS dependency
4. CMS as a content source
   • XM Cloud provides content variants
   • The frontend selects which one to render

This approach keeps:

• Performance high
• Architecture clean
• The CMS simple

Step 3: Use CDP and Personalize strategically—not automatically

CDP and Personalize are powerful platforms.

They are also complex and expensive.

They make sense when:

• You need cross-channel orchestration
• Identity stitching matters
• ML-driven decisioning is required
• You have scale to justify the investment

They don’t make sense when:

• Personalization needs are basic
• Rules are mostly static
• Cost outweighs business value

Composable means optional, not mandatory.

A new mental model for XM Cloud

The most important shift is conceptual.

Think of XM Cloud as:

A high-performance enterprise content engine—not a personalization engine

In the XM Cloud world, personalization is:

• Distributed
• API-driven
• Frontend-owned
• Strategy-first

This is uncomfortable for XP veterans—but it’s unavoidable.

Final thought: this isn’t a downgrade, it’s a reset

XM Cloud didn’t remove personalization accidentally.

It intentionally moved away from:

• Implicit rules
• Stateful sessions
• CMS-bound decisioning

In favor of:

• Explicit strategy
• Clear ownership
• Scalable, composable architecture

Teams that re-architect personalization succeed.

Teams that try to recreate XP struggle.

Key takeaway

If you migrate personalization without redesigning it, XM Cloud will feel like a downgrade.

If you redesign personalization for a composable architecture, XM Cloud becomes an accelerator.

Written by

Ketan Garala

CEO of Arroact