---
title: "Kentico to Xperience by Kentico Migration | ClonePartner"
description: "Kentico to Xperience by Kentico: KX13's tree-based CMS_Document and CMS_Tree records cannot be copied directly…"
source: Kentico
target: Xperience by Kentico
canonical: "https://clonepartner.com/migrate/kentico-to-xperience-by-kentico"
---

# Kentico → Xperience by Kentico migration

Kentico Xperience 13 to Xperience by Kentico — content, media, forms and contacts moved ahead of the 31 December 2026 end of support.

## Why teams migrate from Kentico to Xperience by Kentico

Migrating from Kentico Xperience 13 (KX13) to Xperience by Kentico (XbyK) is a full replatform, not an in-place upgrade — the database schema, runtime, and content model have all been rebuilt from the ground up on .NET 8+. The central architectural challenge is that KX13's hierarchical, tree-based CMS_Document/CMS_Tree model must be decomposed into separate routing nodes and independent Content Hub items, requiring a structural transformation of every content record. Kentico provides an open-source Migration Tool (KMT) that automates transfer of structured content, contacts, media, and forms, but it explicitly does not migrate application code, custom admin UI, email templates, marketing automation configurations, or page type inheritance structures. The full replatform scope extends well beyond data migration to include template redesign, custom code rewrites, integration rebuilds, and authentication layer changes — each representing a distinct workstream measured in months alongside the data migration itself.

## Key migration challenges

- **Content Model Restructuring** — KX13's tree-based CMS_Document and CMS_Tree records cannot be copied directly — they must be split into page routing nodes and independent Content Hub items, requiring explicit architectural decisions about which page types become reusable content types versus page content types.
- **Page Type Inheritance Removal** — XbyK does not support KX13-style page type inheritance, so any inherited page type hierarchies must be manually refactored using XbyK's reusable field schemas before or during migration.
- **Authentication Layer Replacement** — XbyK replaces legacy ASP.NET membership providers with ASP.NET Core Identity, which uses a different password hashing algorithm, meaning migrated users must either reset passwords or custom middleware must be built to re-hash legacy credentials on first login.
- **Custom Table Data Transformation** — KX13 custom tables have no direct XbyK equivalent and must be migrated to either custom module classes or reusable content items, with all associated UI, listings, and filters rebuilt from scratch in the new platform.
- **CI/CD Serialization Synchronization** — XbyK's repository-based CI/CD pipeline serializes content type definitions to XML files in source control, so content types created by the KMT must also be serialized and committed after each migration pass or subsequent deployments will overwrite them.
- **Foreign Key Relationship Remapping** — Relational fields such as author foreign keys and category references do not migrate automatically and require manual field mapping configuration in the KMT to produce valid content item references and taxonomy tag references in XbyK.

## Entity mappings

- **Pages (Tree Nodes)** (Kentico) → **Pages (Web Pages)** (Xperience by Kentico)
- **Custom Page Types (Document Types)** (Kentico) → **Content Types (Page Types)** (Xperience by Kentico)
- **Media Library Files** (Kentico) → **Media Library Files** (Xperience by Kentico)
- **Content Items (Headless)** (Kentico) → **Content Items** (Xperience by Kentico)
- **Content Types (Headless)** (Kentico) → **Content Types (Page Types)** (Xperience by Kentico)
- **Users** (Kentico) → **Member (ContactInfo + MemberInfo)** (Xperience by Kentico)
- **Roles** (Kentico) → **Roles** (Xperience by Kentico)
- **Contact Groups** (Kentico) → **Contact Segments (partial equivalent) or Custom Module / Custom Object** (Xperience by Kentico)
- **Forms (BizForms)** (Kentico) → **Form Definitions** (Xperience by Kentico)
- **Categories (Taxonomy)** (Kentico) → **Taxonomies (Tag Groups)** (Xperience by Kentico)
- **Tags** (Kentico) → **Taxonomy Tags** (Xperience by Kentico)
- **URL Redirects / Aliases** (Kentico) → **Custom Module / Redirect Middleware / IIS/Nginx Rules** (Xperience by Kentico)
- **Languages** (Kentico) → **Languages** (Xperience by Kentico)
- **Workflows** (Kentico) → **Workflows** (Xperience by Kentico)

## What breaks during migration

- **Pages and Page Content** [Workaround] — Pages migrate via the KMT but require structural transformation from the tree model into routing nodes plus Content Hub items, and URLs may require regex transformation rules to resolve correctly in the target.
- **Page Types / Content Types** [Workaround] — Basic scalar field mappings are handled automatically, but macro-based field defaults require C# reimplementation and page type inheritance must be refactored into reusable field schemas before migration can complete cleanly.
- **Media Libraries** [Direct] — Media libraries migrate with filesystem and Azure Blob source support, and page attachments are automatically moved to Content Hub as content item assets with stable references.
- **Contacts and Activities** [Workaround] — Contact records and activity data transfer via the KMT, but contact groups are explicitly not migrated and must be recreated manually in XbyK after migration.
- **Forms and Submissions** [Workaround] — Form schemas and submissions both migrate, but the form schema definition must exist in the target database before submission records can be inserted, requiring a sequenced two-pass migration approach.
- **Users and Roles** [Breaks] — User records transfer but password hashes are algorithmically incompatible with XbyK's ASP.NET Core Identity layer, making forced password resets or custom re-hashing middleware a mandatory go-live decision.
- **Custom Tables** [Breaks] — Custom tables have no native XbyK equivalent, so while the KMT can recreate table schemas as custom module classes, all associated administrative UI, listings, and filtering logic must be rebuilt entirely from scratch.
- **Categories and Taxonomies** [Workaround] — KX13 document-bound categories migrate to XbyK's independent taxonomy objects, but the categorization model is fundamentally different and editorial workflows around tagging must be re-evaluated and retrained.
- **Page Builder Widget Content** [Breaks] — Widget data properties transfer via the KMT, but all widget rendering code must be rewritten for XbyK's Page Builder — migrated widget data will not render until matching widget implementations exist in the new codebase.
- **Sites and Channel Configuration** [Direct] — KX13 sites migrate to XbyK website channels with basic properties and settings transferred, though teams must manually configure any email channels or headless channels that have no KX13 equivalent.

## Complete technical guide

For a deep-dive into the technical process, data mapping, and step-by-step migration workflow, read our full guide: [Kentico to Xperience by Kentico Migration: Technical Guide](https://clonepartner.com/blog/kentico-to-xperience-by-kentico-migration-technical-guide/).

## Frequently asked questions

### What happens to my Kentico user accounts and passwords during migration?

Front-end site members (CMS_User) are migrated to Xperience by Kentico's MemberInfo table, preserving email addresses, usernames, and password hashes where the hashing algorithm is bcrypt-compatible. If your Kentico instance used SHA2 password hashing, those hashes cannot be reused and a forced password-reset email flow is required post-migration. Back-end administrator accounts have no supported bulk import path in Xperience by Kentico and must be recreated manually through the Administration UI. Contact and profile data is migrated separately to ContactInfo in the Digital Marketing module and linked to the corresponding Member record.

### Do my Kentico Contact Groups migrate to Xperience by Kentico?

There is no direct equivalent to Kentico's Contact Groups in Xperience by Kentico. Dynamic contact groups can be partially replaced by recreating their conditions as Contact Segments in the Segmentation UI, but the historical group membership itself is not migrated — it is recalculated at runtime against the new rules. Static (manually assigned) contact groups have no native home; the standard workaround is to create a custom module object to store group definitions and encode membership as a custom contact field, which requires custom development in your Xperience by Kentico project after the data lands. If you rely on contact groups for email campaigns or personalization, you should plan this workaround before cutover.

### How do URL aliases and redirects from Kentico transfer to Xperience by Kentico?

Xperience by Kentico has no native URL Aliases or Redirects object, so there is no direct mapping from Kentico's CMS_PageAlias and CMS_UrlAlias tables. ClonePartner extracts all source alias data and normalizes it to source path, destination URL, and HTTP status code; it then loads it into your chosen target mechanism — typically IIS URL Rewrite rules in web.config, an ASP.NET Core middleware redirect map, or a custom Redirect module object in Xperience by Kentico. Whichever approach your development team chooses must be configured and deployed in your Xperience by Kentico project before the migration data is applied, or redirects will be silently absent at cutover. Missing this step is one of the most common causes of SEO rank loss after a Kentico-to-XbyK replatform.

### What source version of Kentico do I need before ClonePartner can migrate my data?

For migrations targeting the Kentico Migration Toolkit pipeline, Kentico requires the source to be on version 13.0.64 (Refresh 5) or newer; earlier 13.x patch levels are not compatible. Kentico 12.x, 11.x, and earlier versions are already out of support and are not supported by the official toolkit, though ClonePartner can extract data directly via the database and Kentico's .NET DataEngine for those versions. Portal Engine projects on any version must be moved to the MVC model before content can be migrated to Xperience by Kentico, as Portal Engine page templates and web part configurations are not portable and have no equivalent in XbyK. Kentico Xperience 13 itself reaches end of support on 31 December 2026, so projects still on 13 have a firm deadline for completing this transition.

### Will my Kentico categories and tags come across into Xperience by Kentico automatically?

Both require workarounds rather than direct object-to-object mapping. Kentico's flat category tree maps loosely to Xperience by Kentico's hierarchical Taxonomy Tag Groups, and existing page-category relationships must be re-established after both sides are migrated, because the link records reference IDs that change during migration. Kentico tags are restructured under Xperience by Kentico's unified taxonomy system, which means tag data is importable but the taxonomy group structure must be created first as a prerequisite before tag records can be loaded. If category or tag data is migrated out of sequence — content before taxonomy structure — the relationship records will have nothing to point to and the associations will be silently lost.

### What structural objects in Xperience by Kentico have to be set up before content records can be loaded?

Xperience by Kentico has no single bulk import API; structural definitions must exist before their associated content records arrive. This means custom Content Types (migrated from Kentico's Document Types / Page Types), Taxonomy Tag Groups, Languages, and any custom module class definitions must all be deployed — typically via Xperience by Kentico's CI/CD file-based serialization — before ClonePartner begins loading pages, content items, or form definitions. Additionally, content items imported via the Management API arrive in Draft state and must be explicitly published; any items not published will not appear on the live site after cutover. Form submission records have no REST endpoint in Xperience by Kentico, so those require direct database access or a custom C# endpoint and cannot be loaded through the standard Management API pipeline.

## 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 Kentico → Xperience by Kentico migration.