---
title: "Sitecore to Xperience by Kentico Migration | ClonePartner"
description: "Sitecore to Xperience by Kentico: Item → Pages (Web Pages): Items may be pages or content; requires classification. Engineer-led, zero downtime."
source: Sitecore
target: Xperience by Kentico
canonical: "https://clonepartner.com/migrate/sitecore-to-xperience-by-kentico"
---

# Sitecore → Xperience by Kentico migration

Sitecore to Xperience by Kentico migration — pages, media, and taxonomies moved with content fidelity.

## Entity mappings

- **Item** (Sitecore) → **Pages (Web Pages)** (Xperience by Kentico)
- **Template** (Sitecore) → **Content Types (Page Types)** (Xperience by Kentico)
- **Template Field** (Sitecore) → **Content Types (Page Types)** (Xperience by Kentico)
- **Media Item** (Sitecore) → **Media Library Files** (Xperience by Kentico)
- **Language Version** (Sitecore) → **Content Item Language Variants** (Xperience by Kentico)
- **Workflow** (Sitecore) → **Workflows** (Xperience by Kentico)
- **User** (Sitecore) → **Custom Module Data (Object Instances)** (Xperience by Kentico)
- **Role** (Sitecore) → **Roles** (Xperience by Kentico)
- **Site Definition** (Sitecore) → **Channels (Websites)** (Xperience by Kentico)
- **Layout** (Sitecore) → **Page Templates / Page Builder Templates** (Xperience by Kentico)
- **Rendering** (Sitecore) → **PageTemplate / Widget / Section (Xperience by Kentico Page Builder)** (Xperience by Kentico)
- **Dictionary Entry** (Sitecore) → **Content Items** (Xperience by Kentico)
- **Publishing Target** (Sitecore) → **Custom Module Class or Content Item Taxonomy/Tag** (Xperience by Kentico)
- **Index Configuration** (Sitecore) → **Custom Module / Search Index Configuration (Custom Table or Custom Module Class)** (Xperience by Kentico)

## Frequently asked questions

### Which Sitecore objects migrate cleanly and which ones need workarounds?

Templates, Media Items, Language Versions, Workflows, Roles, and Site Definitions all have direct equivalents in Xperience by Kentico. Items (pages and content), Template Fields, Users, Layouts, Renderings, Dictionary Entries, Publishing Targets, and Index Configurations all require workarounds — either classification steps, custom module data, or code-first rebuilds — because Xperience by Kentico has no native 1:1 destination for them. Before migration begins, your team should classify which Sitecore Items are pages versus reusable content, since that determines whether they land in Web Pages or as standalone Content Items. Planning these mappings in advance prevents data from arriving in the wrong structure.

### What happens to Sitecore Layouts and Renderings — can they be imported into Xperience by Kentico?

No import path exists for Layouts or Renderings as data objects. Xperience by Kentico's Page Builder uses code-first Page Templates (C# classes implementing IPageTemplate) and Widgets registered via assembly attributes, none of which can be bulk-imported from Sitecore's XML-based layout field. The per-page rendering configuration — which renderings appear in which placeholders with which datasource items — can be reconstructed by parsing Sitecore's layout XML and writing valid PageBuilderData JSON via the Xperience by Kentico Management API, but only after your developers have pre-built the corresponding Page Templates and Widgets in code. ClonePartner handles the data extraction and JSON reconstruction; your development team must build the target Page Templates and Widgets before that data can land correctly.

### What data will silently disappear if we don't plan for it before the migration starts?

Several Sitecore objects have no default destination and are dropped unless explicit mappings are defined: Publishing Targets (Xperience by Kentico has no equivalent concept and the official Migration Toolkit omits them entirely), item-level security permissions (access rights are stored separately from items and are routinely missed), workflow history and audit logs (not exportable via standard Sitecore APIs), computed fields and index data (must be rebuilt post-migration), and Sitecore Aliases and redirects (may conflict with the target URL structure). User passwords also cannot be migrated; all users must reset passwords after import. Raise each of these in your scoping call so a handling decision is made before migration runs.

### Does it matter whether our Sitecore instance is XM Cloud or an on-premise/managed-cloud version?

Yes — XM Cloud exposes content through a GraphQL-based Edge API that diverges significantly from the traditional Sitecore SSC REST API used on older instances, so the extraction tooling differs between the two. On-premise and managed-cloud instances can also have Sitecore Item Serialization, Unicorn, or TDS formats with differing compatibility, and cloud instances enforce API rate limits that affect extraction throughput. Identify your Sitecore version and serialization tooling during scoping so the correct extraction method is used from the start.

### How are Sitecore Item GUIDs handled when content references need to survive into Xperience by Kentico?

Sitecore uses Item GUIDs as internal references throughout — in layout XML, datasource fields, and link fields — and Xperience by Kentico uses its own content item identifiers. During migration, a GUID remapping table is built to translate every Sitecore GUID to its corresponding Xperience by Kentico content item identifier, and linked content references are re-resolved before import. If any Sitecore Renderings reference datasource items, those datasource GUIDs are mapped to the new content item GUIDs and written into the PageBuilderData JSON. Missing a reference in the remapping table results in a broken link rather than a visible error, which is why referential integrity checks are run as a validation stage after import.

### Do imported content items go live automatically, and what about media files?

No — all content items imported into Xperience by Kentico arrive in Draft state by default and must be explicitly published before they appear on the live site. Your team needs to account for a publish step as part of cutover, or ClonePartner can trigger publishing via the Management API as part of the migration pipeline if that is agreed during scoping. Media files must be uploaded individually because Xperience by Kentico has no bulk binary import endpoint; large Sitecore media libraries slow extraction on the source side as well, since media binary files must be exported separately from their metadata. Both factors are assessed during scoping to set realistic timing expectations for data volume.

## Get a fixed-price quote

[Talk to an engineer](https://clonepartner.com/talk-to-us?duration=30&utm_source=xtoy&utm_medium=button&utm_campaign=demo_bookings&utm_content=cta_click&utm_term=demo_button_click) about your Sitecore → Xperience by Kentico migration.