---
title: "Kentico to Strapi Migration | ClonePartner"
description: "Kentico to Strapi: Widget configurations stored as deeply nested JSON blobs in DocumentPageBuilderWidgets must be parsed through a multi-level structure…"
source: Kentico
target: Strapi
canonical: "https://clonepartner.com/migrate/kentico-to-strapi"
---

# Kentico → Strapi migration

Seamless Kentico to Strapi migration — all content, media, and taxonomies moved with accuracy.

## Why teams migrate from Kentico to Strapi

Migrating from Kentico Xperience 13 to Strapi v5 has no automated or native migration path — Kentico's official migration tooling only targets Xperience by Kentico as a destination and cannot produce output consumable by Strapi. The fundamental data model mismatch is significant: Kentico stores content across a three-table join per page type (CMS_Tree, CMS_Document, and coupled data tables) within a hierarchical page-tree structure, while Strapi uses flat, schema-defined Collection Types backed by a single database table per content type. Page Builder widget configurations serialized as JSON blobs in Kentico's DocumentPageBuilderWidgets column must be parsed, mapped, and reconstructed as Strapi Dynamic Zone component entries. Every migration requires custom SQL extraction, manual schema design, transformation scripting, and API-driven or direct-database import into Strapi.

## Key migration challenges

- **Page Tree Hierarchy Flattening** — Kentico's hierarchical <code>CMS_Tree</code>-based routing must be fully flattened into individual Strapi Collection Type entries, with <code>NodeAliasPath</code> values mapped to custom slug or URL path fields to preserve legacy URL resolution in the decoupled frontend.
- **Page Builder Widget Extraction** — Widget configurations stored as deeply nested JSON blobs in <code>DocumentPageBuilderWidgets</code> must be parsed through a multi-level structure (editableAreas → sections → zones → widgets → variants → properties) and reconstructed as typed Strapi Dynamic Zone component entries.
- **Multi-Table SQL Join Complexity** — Each Kentico page type requires a custom SQL extraction query joining <code>CMS_Tree</code>, <code>CMS_Document</code>, and its unique coupled data table via <code>DocumentForeignKeyValue</code>, meaning transformation logic must be written and validated per page type.
- **Rich Text and Media URL Rewriting** — Kentico rich text fields contain internal link macros and <code>/getmedia/</code> URL patterns referencing assets by GUID that must be resolved and rewritten to point to Strapi's Upload plugin asset URLs before import.
- **Multilingual Content Restructuring** — Kentico stores language variants as separate <code>CMS_Document</code> rows sharing a single <code>CMS_Tree</code> node, while Strapi's built-in i18n stores locale variants as sub-documents of a single entry, requiring grouping and re-association during transformation.
- **Media Asset Migration and Resolution** — Kentico media assets may exist across three distinct storage locations — the filesystem, Azure Blob Storage, or the <code>CMS_Attachment</code> binary table — each requiring a different extraction strategy before files can be uploaded to Strapi's Upload plugin.

## Entity mappings

- **Pages (Tree Nodes)** (Kentico) → **Collection Type Entries** (Strapi)
- **Media Library Files** (Kentico) → **Media / Assets** (Strapi)
- **Content Items (Headless)** (Kentico) → **Collection Type Entries** (Strapi)
- **Users** (Kentico) → **Users (End Users)** (Strapi)
- **Roles** (Kentico) → **Roles (End User Roles)** (Strapi)
- **Languages** (Kentico) → **i18n Locales** (Strapi)
- **Categories (Taxonomy)** (Kentico) → **Collection Type Entries** (Strapi)
- **Workflows** (Kentico) → **Review Workflows** (Strapi)
- **Page Attachments** (Kentico) → **Media / Assets** (Strapi)

## What breaks during migration

- **Page Content (Articles, News, etc.)** [Workaround] — Content fields map cleanly to Strapi Collection Type attributes, but each page type requires a custom SQL extraction query joining three tables, and field-by-field mapping must be manually authored per type.
- **Page Builder Widget Configurations** [Breaks] — Widget data is serialized as deeply nested JSON inside <code>DocumentPageBuilderWidgets</code> with no schema guarantee, requiring custom parsing logic and a hand-crafted mapping to Strapi Dynamic Zone component structures for every widget type in use.
- **URL Structure and Routing** [Workaround] — Kentico's tree-based routing is implicit in <code>NodeAliasPath</code>, while Strapi has no routing concept; slugs must be explicitly extracted and stored as fields, and frontend routing logic must be rebuilt to reconstruct equivalent URL resolution.
- **Media Files and Attachments** [Breaks] — Assets may be distributed across filesystem directories, Azure Blob Storage, and the binary <code>CMS_Attachment</code> table, each requiring a different retrieval method, and all must be re-uploaded to Strapi's Upload plugin before rich text references can be rewritten.
- **Rich Text Body Content** [Workaround] — Internal Kentico link macros and <code>/getmedia/</code> GUID-based image URLs embedded in rich text fields will break after migration unless a rewrite pass resolves each reference against migrated Strapi asset URLs prior to import.
- **Multilingual Content** [Workaround] — Language variants stored as discrete <code>CMS_Document</code> rows must be grouped by their shared <code>NodeID</code> and re-associated as Strapi i18n locale variants on a single entry, requiring careful ordering during import to avoid orphaned locale records.
- **Categories and Taxonomy** [Direct] — Kentico categories from <code>CMS_Category</code> have a well-structured tree with clear parent-child relationships that can be extracted via SQL and modeled in Strapi as a self-referencing Collection Type with manageable transformation complexity.
- **Container and Navigation Pages** [Direct] — Kentico container pages that carry no custom field data and serve only as structural tree nodes typically do not require a Strapi equivalent, but must be audited to confirm they contain no content-bearing widget configurations.
- **Workflow and Publishing State** [Workaround] — Kentico's workflow states are stored in <code>CMS_Document</code> alongside publish dates, but Strapi's draft-and-publish system uses a binary draft/published state, requiring a mapping decision for any Kentico content in intermediate workflow steps.
- **Content Versioning History** [Direct] — Historical versions stored in <code>CMS_VersionHistory</code> are typically not migrated and can be excluded from scope, but teams requiring audit trails must account for significant additional extraction and storage complexity.

## 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 Strapi Migration: A Technical Guide](https://clonepartner.com/blog/kentico-to-strapi-migration-a-technical-guide/).

## Frequently asked questions

### Do Kentico categories and page attachments migrate into Strapi automatically?

Neither maps cleanly. Categories require a custom collection type to be created in Strapi before migration runs, because Strapi has no native taxonomy system — they land as regular entries rather than as a built-in taxonomy structure. Page attachments migrate as media assets but lose their association to the originating page, so any page-attachment relationships must be re-established manually in Strapi after the data lands.

### Which Kentico version do I need before starting the migration?

The answer depends on which path you are taking. If you are using Kentico's own Migration Toolkit as part of a broader replatform to Xperience by Kentico, your source must be on 13.0.64 (Refresh 5) or newer — that is Kentico's requirement, not ours. For ClonePartner's data migration, availability of the Kentico Management API is the key prerequisite; Xperience by Kentico has the most complete REST surface, while Kentico Xperience 13 and earlier rely heavily on the .NET DataEngine for bulk operations, which affects how we extract content. Portal Engine projects must be on MVC before extraction is feasible via API.

### What has to be set up in Strapi before any content can be imported?

Several things must exist on the Strapi instance before import begins or the migration will fail silently or error out: collection type schemas for all mapped Kentico page types and content items (these cannot be created via REST and must be built in the Content-Type Builder or on the filesystem), a custom collection type schema for Kentico categories, all target i18n locales (required before localized entries can be created), and any component or dynamic zone schemas referenced by entries. Strapi also has no bulk-create endpoint, so imports loop individual POST requests, and relational IDs assigned during import differ from source IDs — all relation fields must be remapped after both sides of a relationship have been imported.

### Will user passwords come across from Kentico to Strapi?

No. Kentico does not expose hashed passwords through its API, and Strapi stores passwords as bcrypt hashes that cannot be imported in plain text regardless. All migrated user accounts will exist in Strapi with no usable password, and every user must complete a password reset before they can log in. Plan for a reset email campaign timed to your go-live.

### What Kentico content is silently dropped and never reaches Strapi?

Several categories of data have no migration path and will not appear in Strapi: web part and widget configurations (tightly coupled to .NET code and not portable), scheduled task logic (code-based, requires .NET assemblies), form submission data (no standard API import path — requires direct database access), workflow history and audit logs (not available via the public API), and API tokens and secrets (not exportable in decrypted form and must be regenerated on the Strapi instance). If any of these matter to your project, flag them during scoping.

### Does it matter that Kentico Xperience 13 support ends in 2026?

It affects planning sequencing, not our migration process itself. Kentico's technical support for Xperience 13 ends 31 December 2026, with 2026 already limited to security hotfixes only; from 1 January 2027, all support, maintenance, and security repairs cease. The data migration ClonePartner performs typically completes within 1–5 business days depending on data volume, complexity, and API rate limits, so the migration itself is not the long-lead item — your team's broader replatforming and Strapi implementation work is what needs to be sequenced against that deadline.

## 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 → Strapi migration.