XM Cloud & Headless

Sitecore XP to XM Cloud Migration: Search, xConnect, and Assist Features

Team meeting in a modern office
Photo: Lucas / Unsplash · Royalty-free

XP to XM Is Not a Version Upgrade

Platform teams often treat XP to XM as a license swap and a Solr reindex. It is a product boundary change. xConnect personalization pipelines, Coveo indexes, custom aggregation processors, and Sidekick driven authoring do not map one to one onto XM Cloud or XM 10.x headless topologies. If you skip the inventory phase, you will discover incompatible assumptions during cutover week when marketing still expects XP style rules and developers already committed to JSS routes.

This post is a question set and worksheet structure we used when moving regulated brands and retail catalogs off XP 9.x toward XM with AI assisted authoring. It is not a sales checklist. Each section ends with decisions your architect must record before anyone runs a parallel publish test.

Developer reviewing code on multiple monitors
Migration planning is mostly discovery: what custom code actually runs in production pipelines.
Photo by Christina @ wocintechchat.com on Unsplash

Solr Cores and Search Topology

XP deployments typically run Solr cores tied to index strategies per database and language. XM Cloud and containerized XM shift toward SearchStax or managed Solr with different core naming, rebuild APIs, and sometimes separate preview vs live indexes.

Questions for platform teams

  • How many Solr cores exist today, and which content types feed each core?
  • Do you use custom IIndexable providers or computed index fields that reference xConnect facets?
  • Are language fallback rules implemented in indexing or at query time in Coveo?
  • What is the full rebuild time on production data volume, and is that within your cutover window?
  • Does XM target the same Solr major version, or do field type definitions need migration?

Document every custom Solr field in source control. We found teams with a dozen undocumented dynamic fields added by an agency three years ago. Those fields break headless serializers that expect typed JSON.

Parallel index validation: run dual write or batch export from XP CM, import into XM staging Solr, compare document counts and spot check 50 high traffic URLs for field parity.

xConnect and Personalization Data

XP personalization often depends on xConnect contact facets, goals, and campaigns stored outside the content databases. XM Cloud may not host xConnect the same way, or you may replace rules with CDP or a third party.

Questions

  • Which personalization conditions read xConnect data vs pure content tree rules?
  • Are there batch aggregation jobs writing back into SQL or Mongo from xConnect?
  • What is the retention policy for contact data, and does it conflict with GDPR deletion workflows?
  • Will you reimplement personas as content driven segments, CDP audiences, or drop them?
  • Do any renderings switch variants based on contact facet that has no XM equivalent?

If the answer to the last item is yes, you need a rendering by rendering decision before component mapping. Do not assume a generic personalization host will appear later.

Custom Pipeline Processors

XP mvc.requestBegin, mvc.renderRendering, and publish pipelines accumulate custom processors. XM headless may bypass MVC pipelines entirely on delivery.

Inventory tasks

  1. Export processor list from show config for publish, getLayoutService, and item saved pipelines.
  2. Mark each processor as CM only, CD only, or both.
  3. Classify: still needed, replace with middleware, delete, unknown.
  4. For unknown, trace git history and production logs for invocation.

Pay attention to processors that mutate item fields on save. They fight Sidekick suggestions and Connect sync if carried over without field scope guards.

Coveo and Third Party Search

Many XP sites index to Coveo with custom metadata mapping from Sitecore templates. XM may change item API paths, publishing events, and security trimming hooks.

Questions

  • Is indexing push, polling, or event driven from publish:end?
  • Which fields are mapped for AI snippets vs plain search results?
  • Does Coveo security provider still resolve Sitecore roles on XM CD?
  • Are there Coveo ML models trained on URL patterns that will change in headless routes?

Plan a reindex from XM staging before cutover. Compare result counts and top 100 queries from production analytics.

Sidekick in XM

Sidekick attaches to XM authoring surfaces: Content Editor field helpers, Experience Editor overlays, and sometimes custom gutter apps. XP teams new to Sidekick often assume it replaces workflow. It does not. It suggests field values within governance you define.

Platform questions

  • Which templates and fields are in scope for Sidekick on day one?
  • Are prompt definitions stored in git with version tags per environment?
  • How do Sidekick writes interact with Connect owned fields on shared templates?
  • Will authors use Sidekick in XP parity mode during parallel run, or only after cutover?
  • What audit trail captures prompt ID, model version, and approver for regulated content?

Sidekick in XM requires the same field ownership matrix as Connect. Platform owns the wiring; editorial owns the prompts with legal sign off.

Inventory Worksheet

Use a single spreadsheet or Azure DevOps wiki table. One row per integration or custom code surface.

ID Area Description XP implementation XM target Risk Owner Status
INV-001 Solr Product core en-US Custom index field BrandFacet SearchStax field map High Platform Open
INV-002 xConnect Industry facet rule Contact facet processor CDP audience TBD Critical Architect Blocked
INV-003 Pipeline Auto SEO title on save item:saved processor Sidekick + workflow Medium Dev In progress

Every row needs a test case ID linked to your parallel publish suite. Empty XM target column means cutover blocker.

Parallel Publish Test

Run XP CM and XM CM against cloned content for at least two weeks before cutover. Same item IDs where possible via serialization or content sync tool.

Test protocol

  1. Select 200 items stratified by template: hero, product, article, landing, form, navigation.
  2. Publish same version label on both stacks to paired databases.
  3. Fetch Layout Service or GraphQL JSON from XM and compare HTML output hash from XP CD for each URL.
  4. Log diffs: missing renderings, field nulls, personalization gaps, media URL host changes.
  5. Repeat after Sidekick prompt promotion and after Connect schema change.

Automate JSON diff in CI where feasible. Manual EE comparison misses headless only fields.

Data comparison charts on screen
Parallel publish diffs should be trended over time, not reviewed once.
Photo by Luke Chesser on Unsplash

Rendering to Headless Component Map

XP MVC renderings become JSS components, Next.js routes, or Horizon compatible equivalents. Maintain an explicit map.

XP rendering name Controller / view path XM component Data source fields Personalization Notes
HeroBanner Features/Hero/HeroBanner.cshtml HeroBanner.tsx Title, Subtitle, CTA, Image None CTA link field type change
ProductCarousel Commerce/Carousel ProductCarousel SKU list, commerce API Segment based Replace xConnect rule

Questions per row: Does the datasource template change? Are Experience Editor placeholders preserved? Does Sidekick suggest fields the component still reads?

Workflow Migration

XP workflow states do not auto migrate with content packages. AI governance adds approver steps for machine suggested copy.

Questions

  • Map each XP workflow state to XM workflow state; identify new states for AI review.
  • Which states allow Sidekick apply vs suggest only?
  • Are email notification actions reimplemented in XM?
  • Do legal hold items use a branch or workflow lock incompatible with bulk publish?

Run workflow unit tests: create item, submit, reject at legal gate, verify field history shows Sidekick prompt version.

Decision Log Template

Record irreversible choices. Future you will not remember why Coveo stayed on push indexing.

Decision ID: DEC-2026-014
Title: Drop xConnect industry facet personalization on XM v1
Date: 2026-06-12
Status: Accepted
Context: XP uses xConnect facet IndustryCode on 12 renderings.
Options: (A) CDP audience rebuild, (B) content tree segment items, (C) defer personalization v1
Decision: Option B for launch; Option A in Q4
Consequences: Marketing must maintain segment items; no real time facet updates
Review date: 2026-09-01
Owner: Lead architect

Link each decision to inventory rows and test case IDs.

Cutover Risks

Technical

  • Solr full rebuild exceeds maintenance window
  • Layout Service contract breaks mobile app
  • Connect webhook still points at XP CM URL
  • Custom processor missing on XM causes silent field null
  • Media URL domain change without CDN redirect

Organizational

  • Authors trained on XP EE only; XM headless preview unfamiliar
  • Legal has not approved Sidekick prompts for product claims
  • Commerce team expects real time inventory on XP CD cache TTL

Mitigation patterns

  • Blue green CD with rollback DNS
  • Read only XP site for 48 hours post cutover
  • Feature flag for Sidekick apply vs suggest only
  • War room checklist with mapping table reconciliation script

Content Serialization and Item ID Strategy

XP to XM migrations stumble when teams assume item GUIDs survive every path. Content sync tools may generate new IDs on import unless you explicitly preserve them. Personalization rules, internal links, and Connect mapping tables all reference GUIDs. Decide early: greenfield IDs with redirect map, or forced ID preservation with serialized packages per subtree.

For AI programs, Sidekick fixture branches and prompt test items should use preserved IDs in QA so automated tests reference stable paths across refreshes. Document ID preservation in the inventory worksheet as its own row with Critical risk if Connect external map depends on it.

Environment Parity for AI Features

Sidekick model endpoints differ per environment. A prompt tuned on GPT 4.1 mini in dev may run GPT 4.1 in prod with different token limits. Platform teams should ask: Are enrichment profiles identical across QA and prod? Is temperature locked in prompt JSON or overridable in CM? Do staging Sidekick calls log to the same SIEM as prod for audit rehearsal?

Run one parallel publish test cycle with Sidekick apply enabled in QA XM only, comparing output to XP without AI. Marketing may accept wording drift; legal may not. Capture diff in decision log before enabling Sidekick in prod parallel run.

Media and DAM Migration Questions

  • Are XP media items referenced by item ID in rich text or as media links that survive export?
  • Does Hub become system of record post migration, making XP media library read only archive?
  • Will Sidekick suggest alt text on images whose binary still lives on XP CDN hostname?
  • Is there a bulk job to rewrite media URLs in rich text fields before cutover?

Schedule URL rewrite test in parallel publish diff script. A null hero image crashes headless components that lack Scriban guards even when Sidekick headline is perfect.

Performance and Cache Invalidation

XP CD cache keys often embed database name and item version. XM headless may use edge CDN with tag based purge. Platform questions:

  • Does publish on XM invalidate the same URL set XP did for top templates?
  • Are Layout Service responses cached with keys that ignore commerce field updates from Connect?
  • What is max TTL on product pages with hourly price sync?

Commerce plus AI copy on same page means two invalidation sources. Document which field changes trigger purge. Authors expect Sidekick headline live in minutes; commerce expects price live in seconds. Misaligned expectations become cutover war room noise.

Training and Author Readiness

Inventory technical debt is not enough. Ask whether authors know Sidekick suggests vs applies, which workflow state is required, and how EE preview differs from Next.js preview host. Run tabletop exercise: author accepts bad suggestion, approver publishes, legal flags claim. Trace audit fields. If audit trail gap appears, that is a cutover blocker equal to Solr rebuild risk.

Post Cutover Validation Window

Define 72 hour hypercare with explicit checks: Connect webhook error rate, Sidekick apply count per template, parallel diff sample of 20 URLs, Coveo query zero result rate, xConnect replacement feature flags off or on per decision log. Platform lead signs daily attestation checklist until steady state.

Stakeholder Sign Off Matrix

Each inventory row with Critical risk needs named sign off before cutover window opens. Platform owns technical readiness; marketing owns author training; legal owns Sidekick prompt registry; commerce owns Connect field map. Use a simple RACI exported from the inventory worksheet weekly during migration phase. Unsigned Critical rows block go no go meeting agenda item.

Recording a Loom walkthrough of XM headless preview for authors is not training completion. Track completion in LMS or signed attendance sheet. XP veterans who skip training file the first Sidekick related Sev 2 because EE no longer matches their mental model.

Closing Checklist

  • Solr core inventory complete with rebuild time measured on production volume
  • xConnect dependency list with explicit replace or defer decision per feature
  • Custom pipeline processor export classified and signed off
  • Coveo mapping documented; staging reindex compared to XP baseline
  • Sidekick scope, prompt git repo, and audit requirements defined for XM
  • Inventory worksheet rows all have XM target and owner
  • Parallel publish test running on 200 item stratified sample with automated diff
  • Rendering to headless component map reviewed by frontend and platform leads
  • Workflow states mapped including AI legal review gates
  • Decision log started; every Critical risk row has linked DEC entry
  • Cutover rollback plan tested in sandbox including Connect webhook failover