---
title: "Adobe Experience Manager to Xperience by Kentico Migration | ClonePartner"
description: "Adobe Experience Manager to Xperience by Kentico: Users migrate to roles; user accounts managed outside CMS. Engineer-led, zero downtime."
source: Adobe Experience Manager
target: Xperience by Kentico
canonical: "https://clonepartner.com/migrate/adobe-experience-manager-to-xperience-by-kentico"
---

# Adobe Experience Manager → Xperience by Kentico migration

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

## Entity mappings

- **Pages** (Adobe Experience Manager) → **Pages (Web Pages)** (Xperience by Kentico)
- **Assets (DAM)** (Adobe Experience Manager) → **Media Library Files** (Xperience by Kentico)
- **Content Fragments** (Adobe Experience Manager) → **Content Items** (Xperience by Kentico)
- **Templates** (Adobe Experience Manager) → **Content Types (Page Types)** (Xperience by Kentico)
- **Tags** (Adobe Experience Manager) → **Taxonomy Tags** (Xperience by Kentico)
- **Users** (Adobe Experience Manager) → **Roles** (Xperience by Kentico)
- **Groups** (Adobe Experience Manager) → **Roles** (Xperience by Kentico)
- **Workflows** (Adobe Experience Manager) → **Workflows** (Xperience by Kentico)
- **Folder Structures** (Adobe Experience Manager) → **Media Libraries** (Xperience by Kentico)
- **Translations** (Adobe Experience Manager) → **Content Item Language Variants** (Xperience by Kentico)
- **MSM Live Copies** (Adobe Experience Manager) → **Custom Module / Content Item Variants or Linked Content** (Xperience by Kentico)
- **Launches** (Adobe Experience Manager) → **Custom Module / Workflow Staging or Content Versioning** (Xperience by Kentico)
- **Experience Fragments** (Adobe Experience Manager) → **Content Items** (Xperience by Kentico)
- **Content Policies** (Adobe Experience Manager) → **Custom Module / Content Type Definitions + Page Type Field Validation** (Xperience by Kentico)
- **Metadata Schemas** (Adobe Experience Manager) → **Custom Modules / Module Classes** (Xperience by Kentico)

## Frequently asked questions

### What happens to AEM MSM Live Copies when migrating to Xperience by Kentico?

Xperience by Kentico has no native equivalent to AEM's Multi-Site Manager, so Live Copy inheritance relationships cannot be replicated directly. The standard approach is to flatten each Live Copy into an independent content item, migrating the resolved content as a standalone page or content item with inheritance metadata discarded or stored in a custom Xperience module for traceability. If your Live Copies served localization or regional variation purposes, Xperience by Kentico's multi-site content sharing or language variants are the closest functional analog, but they require a content architecture redesign that falls outside the scope of data migration.

### Do AEM Launches migrate to Xperience by Kentico, and will my scheduled go-live dates carry over?

AEM Launches have no native equivalent in Xperience by Kentico, and in-flight Launches rarely survive a platform migration intact. The most practical path is to export staged content from the Launch and import it as a Draft workflow page with a scheduled publish date in Xperience by Kentico via the Content Management API, which preserves the time-based go-live intent. If the Launch was already promoted or abandoned, the content is either folded into the published pages being migrated or discarded — your team should audit and classify all active Launches before migration begins to avoid silent data loss.

### Are there API or tooling differences between AEM 6.x on-premise and AEM as a Cloud Service that affect how the migration is done?

Yes — AEM 6.x on-premise allows direct JCR/CRX access and Content Package Manager exports, while AEM as a Cloud Service restricts both; Cloud Service migrations require the Cloud Acceleration Manager or Content Transfer Tool instead. These are different extraction paths with different payload formats, so ClonePartner's pre-migration scoping confirms which AEM version is the source before any extraction work begins. Additionally, AEM has no single unified REST API, meaning Sites, Assets, and configuration data are each accessed through separate endpoints regardless of version.

### What AEM content types need manual reconfiguration in Xperience by Kentico after the data lands?

Several entities require post-migration work that falls outside data movement: AEM Templates map only loosely to Xperience by Kentico Page Types, whose structure must be defined or verified before content is imported; Content Policies have no direct equivalent and must be re-expressed as Page Type field validation and Widget Zone restrictions; and User and Group permission models differ enough that user accounts must be managed outside the CMS with roles reconfigured by hand. AEM passwords and cloud configuration secrets also cannot be exported at all and must be set up fresh in the destination environment. Importantly, all content items land in Xperience by Kentico in Draft state and must be explicitly published after the migration completes.

### Will AEM Content Fragment Models need to exist in Xperience by Kentico before Content Fragments are migrated?

Yes — AEM Content Fragments depend on their Fragment Models for structure, and this dependency carries over to the destination: the corresponding Xperience by Kentico Content Types must be in place before Content Items are imported, or the import will fail. ClonePartner migrates Content Types ahead of Content Items as part of the standard sequencing for this pair. If your Content Fragment Models include custom metadata schemas, those map to Xperience by Kentico Custom Module Classes via a workaround, and their structure should be reviewed during scoping to confirm all fields are accounted for.

### How are AEM DAM folder hierarchies handled when migrating to Xperience by Kentico's Media Library?

AEM DAM folder structures map to Xperience by Kentico Media Libraries, but Xperience by Kentico's library model does not replicate deep nested folder hierarchies natively, so the hierarchy may be flattened during migration. Asset renditions are also not importable via API — Xperience by Kentico regenerates them automatically when the original binary is ingested, so only source files are transferred. Large binary assets require bulk ingest tooling rather than the standard Assets HTTP API due to AEM's payload size restrictions, which is a factor ClonePartner accounts for when scoping data volume and timeline.

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