--- title: "Kentico to Xperience by Kentico Migration: Technical Guide" slug: kentico-to-xperience-by-kentico-migration-technical-guide date: 2026-10-12 author: Nachi Raman categories: [Migration Guide, Kentico, Xperience by Kentico] excerpt: "A technical guide to migrating from Kentico Xperience 13 to Xperience by Kentico — covering the Migration Tool, content model changes, common pitfalls, and timeline." tldr: "KX13 → XbyK is a replatform, not an upgrade. The Kentico Migration Tool moves structured data but not code. Audit early, migrate iteratively, and separate data migration from the app rebuild." canonical: https://clonepartner.com/blog/kentico-to-xperience-by-kentico-migration-technical-guide --- # Kentico to Xperience by Kentico Migration: Technical Guide # Kentico to Xperience by Kentico Migration: Technical Guide Migrating from Kentico Xperience 13 (KX13) to Xperience by Kentico (XbyK) is a replatform, not an in-place upgrade. The underlying architecture, content model, and runtime have all changed — XbyK is built on .NET 8+, introduces a fundamentally different content modeling paradigm centered on the Content Hub, and uses an entirely new database schema. Migrating requires extracting legacy data, transforming it to fit the new structure, and loading it via new APIs. Kentico provides an open-source Migration Tool that transfers structured content and data between the two databases, but [it does not move application code, custom admin UI, email templates, or marketing automation configurations](https://clonepartner.com/blog/blog/what-kenticos-migration-tool-doesnt-move-kx13-xbyk). The data migration is one workstream inside a broader project that also includes rebuilding templates, updating integrations, and retraining editors — each measured on a different clock. **Two clocks, two scopes.** The data migration (moving content, contacts, media, forms) is a discrete task measured in days. The full replatform project — redesigning page templates, rewriting custom code, rebuilding integrations — is a separate effort measured in months. This guide covers both, and labels which clock each section refers to. ## Why does the KX13 end-of-support deadline matter? Kentico Xperience 13 reaches **[end of technical support on December 31, 2026](https://clonepartner.com/blog/blog/kentico-xperience-13-end-of-support-2026-what-actually-changes)**. The deadline changes what Kentico will and won't do for your running instance: - **January 1 – December 31, 2026:** Security-only hotfixes. No bug fixes, no feature updates, no enhancements. - **January 1, 2027 onward:** All support ceases. No security patches, no bug fixes, no technical support of any kind. Your KX13 site won't stop running on January 1, 2027. But continued use after end of support is entirely at the customer's risk — including liability for security incidents, data breaches, and compliance violations. There's an additional runtime deadline to watch. If your KX13 live site runs on .NET 8 or .NET 9, those frameworks reach Microsoft's end of support on **November 10, 2026** — before Kentico's own deadline. Current KX13 releases do support .NET 10, so this is a runtime check rather than a universal cutoff, but it's one more variable in your planning. The window to migrate thoughtfully — with time for content audits, sample migrations, and validation — is narrowing. Starting scoping at least **3–4 months** before any internal deadline is necessary to leave time for iterative test runs and stakeholder validation. ## The architectural shift: why this is not an upgrade KX13 relies on a hierarchical, tree-based content model where pages dictate routing, layout, and content simultaneously. XbyK decouples these elements entirely. In XbyK, content is stored as reusable items in the **Content Hub**. Pages in the website channel tree are routing nodes that reference content items. Your legacy `CMS_Document` and `CMS_Tree` SQL records cannot simply be copied over — they must be split into structural page nodes and independent content items. This split is the central transformation challenge of the entire migration. ### Content model changes - **Sites → Website channels.** Each KX13 Site becomes a Website channel in XbyK. XbyK also introduces email channels and headless channels — concepts that didn't exist in KX13. - **Page types → Content types.** KX13 page types become page content types. XbyK also introduces **reusable content types** (stored in the Content Hub, not tied to any channel) and **headless content types**. Deciding which KX13 page types should become reusable content items vs. page content types is an architectural decision that affects your entire content strategy. See the decision framework below. - **Categories → Taxonomies.** KX13 categories were document-bound. XbyK taxonomies are independent objects — editors can translate tags into different languages, and taxonomy is no longer tied to the document tree. - **Custom tables → Gone.** XbyK has no direct analog. Data from custom tables migrates to custom module classes (default) or reusable content items (opt-in). Either way, your team must build the UI, listings, and filters from scratch. - **Page type inheritance → Not supported.** If your KX13 content model uses page type inheritance, you must refactor using XbyK's **reusable field schemas** — a different mechanism that requires explicit configuration in the Migration Tool. ### Content type classification: decision framework The most common architectural question in a KX13→XbyK project is whether a given page type should become a **reusable content type** (stored in Content Hub) or a **page content type** (tied to a URL in the site tree). Use this framework: ``` Does this content need its own URL on the site? ├── YES → Page content type │ Does it also appear embedded in other pages or channels? │ ├── YES → Page content type + Content Hub reference (or split) │ └── NO → Page content type only └── NO → Does it appear in multiple places or channels? ├── YES → Reusable content type (Content Hub) └── NO → Reusable content type or custom module class Is it editorial content or structured data? ├── Editorial → Reusable content type └── Structured data → Custom module class ``` Concrete examples: - **Blog post** with its own URL: page content type - **Author profile** referenced from multiple blog posts: reusable content type - **Product specification table** used across channels: reusable content type - **Order record** or **form submission**: custom module class - **Navigation menu item**: reusable content type or structured as a module class depending on editorial workflow ### Before/after schema example To make this concrete, here is what a KX13 page type definition produces after migration. **KX13 source — `CMS_Class` record (simplified):** ```sql ClassName: 'Custom.BlogPost' ClassDisplayName: 'Blog Post' ClassTableName: 'Custom_BlogPost' -- Fields stored in CMS_ClassField: -- BlogPostTitle nvarchar(200) -- BlogPostBody ntext -- BlogPostDate datetime -- BlogPostAuthor int (FK to CMS_User) -- BlogPostCategory int (FK to CMS_Category) ``` **XbyK target — Content type after migration:** ```csharp // Generated content type class [ContentType("Custom.BlogPost", "Blog Post", ContentTypeScope = ContentTypeScope.Website)] public partial class BlogPost : IWebPageFieldsSource { public const string CONTENT_TYPE_NAME = "Custom.BlogPost"; [ContentItemField("BlogPostTitle")] public string BlogPostTitle { get; set; } [ContentItemField("BlogPostBody")] public RichTextContent BlogPostBody { get; set; } [ContentItemField("BlogPostDate")] public DateTime BlogPostDate { get; set; } // NOTE: Author FK becomes a content item reference // Category becomes a taxonomy tag reference // Both require manual field mapping configuration } ``` Key transformation gaps the KMT handles automatically vs. manually: - ✅ Basic scalar fields (string, datetime, int) migrate with type mapping - ✅ Rich text body fields migrate as `RichTextContent` - ⚠️ Foreign key relationships (author, category) require manual field mapping config - ❌ Macro-based field defaults require C# reimplementation - ❌ Page type inheritance requires reusable field schema refactoring ### Framework and runtime changes - **Framework transition:** KX13 runs on .NET Framework or early .NET Core. XbyK requires .NET 8 or newer. As of late 2026, .NET 10 is recommended since .NET 8 reaches end of support November 2026 and .NET 9 reaches end of support May 2026. - **Database schema overhaul:** XbyK uses an entirely new set of SQL tables. Legacy custom module tables do not map automatically — the KMT recreates table schemas in the target based on class definitions, then inserts records. - **Authentication:** ASP.NET Core Identity replaces the legacy membership providers. Password hashes use a different algorithm. Without custom authentication middleware that accepts and re-hashes legacy passwords on first login, migrated users must reset passwords. This is a mandatory decision point before go-live. - **CI/CD serialization interaction:** XbyK uses a repository-based CI/CD pipeline that serializes content type definitions to XML files tracked in source control. When the KMT creates content types in the target database, those definitions must also be serialized and committed to your repository, or CI/CD deploys will overwrite them. Run `dotnet run --project -- --kx-serialization-sync` after each KMT pass, or configure the tool's `CIRepositoryPath` setting to write serialized definitions automatically. ## What the Kentico Migration Tool handles (and what it drops) The **Kentico Migration Tool (KMT)** is an open-source CLI application that transfers content and data from KX13 (and also Kentico 12 and 11) databases into an XbyK target database. It reads from the source SQL Server database, applies built-in and custom data transformations, and writes into the target using the Universal Migration Tool (UMT) libraries. ### Source version requirements The source instance must be **KX13 with Refresh 5 (hotfix 13.0.64) or newer**. Below that version, the Migration Tool will not run. KX12 and KX11 sources are supported, but the transformation rules differ and some content structures require additional configuration. Confirm your exact hotfix version in the Kentico administration before configuring the tool. ### KMT version and XbyK compatibility The KMT is versioned independently from XbyK. Always use the KMT version that matches your target XbyK installation. Running a mismatched KMT version against a newer XbyK database schema is the most common cause of schema-related failures on the first run. Check the [KMT GitHub releases page](https://github.com/Kentico/xperience-by-kentico-kentico-migration-tool/releases) for the compatibility matrix. ### What the Migration Tool transfers The KMT CLI accepts flags that control which object types are migrated. A typical invocation: ```bash Migration.Tool.CLI.exe migrate \ --sites --custom-modules --users --settings-keys \ --page-types --pages --type-restrictions \ --contact-management --forms --media-libraries \ --data-protection --custom-tables --members --categories ``` Flag order matters for dependency resolution. The tool internally orders operations based on object dependencies (sites before page types, page types before pages), but supplying flags out of dependency order may produce warnings in earlier KMT versions. Run `--sites --custom-modules --page-types` as a first pass before adding content flags. | KX13 Object | XbyK Target | Tool Support | Notes | |---|---|---|---| | Sites | Website channels | ✅ Migrated | Basic properties and settings transfer | | Page types | Page content types | ✅ Migrated | No page type inheritance; no macro field defaults | | Pages | Website channel pages | ✅ Migrated | URLs may need regex transformation | | Page Builder content | Page Builder content | ✅ Migrated | Widget *data* transfers; widget *code* does not | | Media libraries | Media libraries | ✅ Migrated | Filesystem or Azure Blob sources | | Page attachments | Content item assets | ✅ Migrated | Moved to Content Hub | | Categories | Taxonomies | ✅ Migrated | Different categorization model in XbyK | | Custom tables | Custom module classes | ✅ Migrated | Or optionally as reusable content items | | Contacts & activities | Contacts & activities | ✅ Migrated | Contact *groups* are NOT migrated | | Forms + submissions | Forms + submissions | ✅ Migrated | Form schema must exist in target before submissions migrate | | Users & roles | Users & roles | ✅ Migrated | Password hashes do not transfer | | Orders & customers | Orders & customers | ✅ Migrated | Added in KMT support for XbyK; custom order fields included | | Settings keys | Settings keys | ✅ Migrated | Only keys that exist in XbyK schema | | Language variants | Content item language variants | ✅ Migrated | See multilingual section below | | Field categories | Field categories | ❌ Not migrated | Must be recreated manually in target | | Contact groups | — | ❌ Not migrated | Must be reconstructed in XbyK | ### What the Migration Tool does NOT transfer - **Application code** — controllers, views, repositories, custom modules, API integrations - **Email Builder content and widgets** — XbyK uses Razor components with MJML markup; must be rebuilt from scratch - **Marketing automation** — not supported for migration - **Contact groups** — exist in XbyK but the segmentation model differs; must be reconstructed - **Macro expressions** — K# macros are not supported in most XbyK contexts; fields with macros will not function after migration - **License keys** — a new XbyK license is required - **Scheduled tasks** — business logic must be reimplemented as .NET background services or XbyK's scheduler - **Page ACLs and permissions** — not transferred; content security must be reconfigured - **Password hashes** — user accounts migrate but credentials do not; all migrated users must reset passwords or you implement a legacy hash middleware - **SKUs** — the tool migrates orders and customers but does not natively migrate KX13 product SKUs to XbyK content types - **Field categories** — the grouping of fields within a content type editor; must be recreated manually - **Web part configurations** — legacy web parts have no XbyK equivalent; these are a replatform task, not a migration task ## Multilingual migration specifics KX13 uses a document culture model: each page (`CMS_Document`) has a `DocumentCulture` field, and multilingual content exists as separate document records sharing a `DocumentNodeID`. XbyK uses **language variants** — a single content item with multiple language variant records attached. The KMT handles this transformation, but there are edge cases: - **Default language must be established first.** The KMT migrates the default culture's content item first, then attaches language variants. If your KX13 default site culture does not map cleanly to an XbyK language configured in the target, the migration will either error or assign content to the wrong language. Configure target languages in XbyK admin before running the KMT. - **Untranslated fields.** In KX13, fields with no translated value fall back to the default language value. In XbyK, untranslated language variant fields are empty — not inherited. After migration, content that relied on KX13 fallback behavior will appear blank for those languages. Audit fallback dependencies before migration. - **Culture codes vs. language codes.** KX13 uses full culture codes (`en-US`, `fr-FR`). XbyK uses language codes configured in the admin (`en`, `fr`). The KMT maps these based on your XbyK language configuration. Mismatches between source culture codes and target language codes are a common source of "language variant not found" errors on first run. - **Taxonomy translation.** XbyK taxonomies support translated tag names. KX13 categories did not. Migrated taxonomy tags arrive in the default language only; translations must be added manually post-migration. ## How to run a pre-migration audit Before touching the Migration Tool, audit your KX13 instance. The goal is to know exactly what you have, what maps cleanly, and what needs manual intervention. **Content inventory — SQL queries against KX13 database:** ```sql -- Active page count by page type SELECT ClassName, COUNT(*) AS PageCount FROM CMS_Document d JOIN CMS_Tree t ON d.DocumentNodeID = t.NodeID JOIN CMS_Class c ON t.NodeClassID = c.ClassID WHERE d.DocumentIsArchived = 0 GROUP BY ClassName ORDER BY PageCount DESC; -- Page types using inheritance SELECT ClassName, ClassParentID FROM CMS_Class WHERE ClassParentID IS NOT NULL AND ClassIsDocumentType = 1; -- Custom tables and record counts SELECT c.ClassName, c.ClassDisplayName, (SELECT COUNT(*) FROM sys.tables WHERE name = c.ClassTableName) AS TableExists FROM CMS_Class c WHERE c.ClassIsCustomTable = 1; -- Media library sizes SELECT LibraryName, LibrarySiteID, COUNT(mf.FileID) AS FileCount, SUM(mf.FileSize) / 1048576.0 AS TotalSizeMB FROM Media_Library ml LEFT JOIN Media_File mf ON ml.LibraryID = mf.FileLibraryID GROUP BY LibraryName, LibrarySiteID; -- Documents using direct file URLs instead of getmedia handler SELECT DocumentID, DocumentName, DocumentCulture FROM CMS_Document WHERE DocumentContent LIKE '%/SiteName/media/%' OR DocumentContent LIKE '%/files/%' AND DocumentContent NOT LIKE '%~/getmedia/%'; ``` **Code inventory:** - Map all custom widgets (Page Builder and Email Builder) — widget data migrates, widget code does not - List custom modules and their admin UI surfaces — each needs a rebuilt admin interface in XbyK - Identify all macro expressions in field defaults, transformations, visibility conditions, and web parts - Document scheduled tasks and their business logic — these become .NET background services - Catalog all external integrations (CRM, e-commerce, analytics, search) and their authentication methods **Data quality checks:** - Orphaned content — pages referencing deleted media, broken internal links - Content duplicated across tree sections or languages - Media referenced via direct file URLs instead of `~/getmedia/` paths — these won't resolve after migration - Fields using GUID or Time interval field types — no matching XbyK form components exist; these require custom component development or field type conversion - Documents with macro expressions in body content — not just field defaults The audit output becomes your migration checklist. Every item the KMT doesn't handle becomes a line item in your replatform project plan. ## Step-by-step migration process The migration follows an iterative pattern. The KMT is designed for multiple runs, not a single big-bang transfer. Each run is idempotent for most object types — objects already present in the target are updated rather than duplicated, based on GUID matching. ### 1. Prepare the XbyK target environment Create a fresh Xperience by Kentico project. XbyK requires: - **.NET 8 through .NET 10** (as of late 2026, .NET 10 is recommended) - **SQL Server 2019 or newer** with a case-insensitive collation (`SQL_Latin1_General_CP1_CI_AS` or equivalent) - **Visual Studio 2022+** or VS Code Configure target languages, website channels, and any required taxonomy structures before running the KMT. The tool expects these to exist or will create stubs that need post-migration cleanup. ### 2. Configure the Migration Tool Clone or download the [Kentico Migration Tool repository](https://github.com/Kentico/xperience-by-kentico-kentico-migration-tool). The key configuration lives in `Migration.Tool.CLI/appsettings.json`: - **Source connection string** — pointing at your KX13 SQL Server database - **Target connection string** — pointing at the XbyK SQL Server database - **`ConvertClassesToContentHub`** — list page types or custom tables that should become reusable content items instead of page types or module classes - **`CIRepositoryPath`** — path to your XbyK repository folder for automatic CI/CD serialization sync after migration - **Custom field mappings** — configure transformations for fields with unsupported data types or custom form controls Rich text fields require special attention. Legacy `~/getmedia/` URL patterns, internal page link syntaxes, and inline widget markup have all changed format between KX13 and XbyK. Configure regex transformation scripts in the field mapping section to handle URL rewrites. Example pattern: ```json { "FieldMappings": [ { "SourceField": "BlogPostBody", "TargetField": "BlogPostBody", "Transformation": "RichTextUrlRewrite", "Options": { "Pattern": "~/getmedia/([a-f0-9-]+)/([^\"]+)", "Replacement": "/getmedia/$1/$2" } } ] } ``` ### 3. Run iterative test migrations Run structural objects first, then content. This ordering reflects hard dependencies: 1. `--sites` — must exist before anything else 2. `--custom-modules --page-types --users` — schema objects before data 3. `--pages --media-libraries` — content after schema 4. `--contact-management --forms` — independent of page content 5. `--categories` (now taxonomies) — after content types exist Run each pass, validate, fix configuration, and re-run. The tool logs migration outcomes to both console output and a `MigrationLog` table written to the target database — query this table directly to identify failed records and their error reasons: ```sql -- Review migration errors from KMT log table SELECT ObjectType, ObjectID, LogType, LogMessage, LogTime FROM Migration_Log WHERE LogType = 'Error' ORDER BY LogTime DESC; ``` ### 4. Validate each run After each run, check record-count parity between source and target for each object type: ```sql -- Source KX13: page count by type SELECT c.ClassName, COUNT(*) AS SourceCount FROM CMS_Document d JOIN CMS_Tree t ON d.DocumentNodeID = t.NodeID JOIN CMS_Class c ON t.NodeClassID = c.ClassID GROUP BY c.ClassName; -- Target XbyK: content item count by type SELECT ContentTypeName, COUNT(*) AS TargetCount FROM CMS_ContentItem ci JOIN CMS_Class c ON ci.ContentItemContentTypeID = c.ClassID GROUP BY ContentTypeName; ``` Beyond counts, validate: - **Field-level spot checks** — compare specific field values for 5–10 records per content type - **Media file integrity** — do images resolve in the target? Check `Media_File` records against physical file existence - **Taxonomy mappings** — are categories correctly converted to taxonomy tags? - **Page URLs** — do generated URLs match expected patterns? Check `WebPageUrlPath` in XbyK - **Language variants** — do all expected language variants exist for multilingual content? - **CI/CD serialization** — are content type definitions serialized to the repository folder? For Azure Blob Storage: verify that `Media_File` metadata records in the XbyK database have `FileStorageKey` values that match the actual blob paths in your storage container. File extensions and MIME types must match the original source files exactly. ### 5. What a failed migration run looks like The KMT does not apply changes transactionally at the full-run level. If the tool fails mid-run: - **Already-processed objects** remain in the target database in their migrated state - **In-progress objects** may be partially written depending on where the failure occurred - **The target database is not automatically rolled back** Recovery steps: 1. Query `Migration_Log` for the last successfully processed object and the error that caused the stop 2. Fix the source data, field mapping configuration, or tool version as appropriate 3. Re-run the tool — it will skip objects already present (matched by GUID) and attempt the failed objects again 4. If the target database is in an unrecoverable state, restore from a pre-migration backup and re-run from the beginning **Always take a SQL backup of the target database before each migration run.** This is not optional for production-destined migrations. Common KMT error patterns and their causes: - `"Content type not found"` — page type migration failed or wasn't run before pages; run `--page-types` first - `"Language not configured"` — target XbyK instance is missing a language that exists in the source; add the language in XbyK admin - `"Media file missing"` — source filesystem path in config doesn't match actual media library location; verify `MediaLibraryRootPath` - `"Macro conversion failed"` — field contains K# macro; flag for manual C# replacement post-migration - Schema version mismatch errors — KMT version doesn't match target XbyK version; update KMT to matching release ### 6. Run a sample migration for stakeholder review Before the final migration, run a complete pass and let editors verify content in the XbyK admin. This surfaces: - Missing field categories (not migrated by the KMT — must be recreated manually) - Broken widget rendering (widget data present, widget code not yet rebuilt) - Content appearance differences between Content Hub's flat structure and KX13's tree view - Language variant gaps where fallback behavior was relied upon in KX13 Document every issue found. Each one is either a data migration fix (configuration change, re-run) or a replatform task (code to build). ### 7. Execute the final migration with delta sync The final migration runs during a maintenance window. Execute the bulk transfer, then run a delta pass to capture content created or modified since the last full run. The KMT handles delta sync by comparing source record modification timestamps against the migration log — objects modified after the last run are re-migrated. **Delta sync limitations:** - Deleted objects in the source are not automatically deleted from the target — you must handle deletions manually or via a custom cleanup script - Objects modified in the target (e.g., by editors testing in XbyK) may be overwritten by the delta sync if the source version is newer - Custom module data without reliable `ModifiedWhen` timestamps may not be captured correctly by delta detection Cut DNS to the XbyK instance after the delta sync completes and validation passes. ## Handling custom modules and forms outside the KMT Custom module data in KX13 resides in dedicated SQL tables (named after the module class, e.g., `Custom_EventRegistration`). To migrate this to XbyK: 1. Recreate the module class in XbyK admin or via CI/CD serialization 2. Use the XbyK Data Access API (`InfoProvider` classes) to insert records programmatically: ```csharp // Example: inserting a migrated custom module record var registration = new EventRegistrationInfo { EventRegistrationName = sourceRecord.Name, EventRegistrationDate = sourceRecord.Date, EventRegistrationEmail = sourceRecord.Email }; EventRegistrationInfo.Provider.Set(registration); ``` For SaaS deployments where direct SQL access is restricted, use the Xperience Portal for initial schema setup, the Management API for content imports, or the CI/CD repository for content type definitions. Direct database manipulation is not available on SaaS — all data operations go through the API layer, which has [rate limits (30 exports per component per environment per month, 60-hour download window on exports)](https://clonepartner.com/blog/blog/how-to-export-data-from-xperience-by-kentico-methods-apis-limits). For historical form submissions beyond what the KMT handles: extract them from KX13 via the `BizFormItemProvider` API or direct SQL against the `BizForm_` tables, transform the records to match the new XbyK form schema, and insert via the XbyK `BizFormItemInfo` provider. ## What are the most common migration pitfalls? **Treating it as an upgrade, not a replatform.** The KMT moves data. It does not transform your KX13 application into an XbyK application. Every line of custom code, every widget view, every integration endpoint needs review and likely rewriting. Kentico's own documentation notes that teams often "do not plan enough time to replace missing features from KX13 that are not available in XbyK." **Underestimating custom table migration effort.** The data transfers, but the UI doesn't. A KX13 site with 15 custom tables and admin screens requires 15 admin interfaces built in XbyK — or a decision to convert them to reusable content items and redesign the editorial workflow. Neither path is free. **Macro dependencies.** K# macro expressions are unsupported in most XbyK contexts. If field defaults, transformations, or visibility conditions depend on macros, they need replacement with C# code or XbyK's native conditional visibility mechanisms. Audit for macros before the first migration run, not after. **Page type inheritance refactoring.** XbyK does not support page type inheritance. Inherited fields must be refactored using **reusable field schemas** — independently defined schema groups that can be attached to multiple content types. This is a content model architecture task, not a data migration task, and should be completed before running the KMT so the target content types are correct from the start. **Email Builder rebuild.** The Migration Tool does not migrate KX13 emails or Email Builder content. XbyK's Email Builder uses Razor components with MJML markup — a completely different development model from KX13's HTML-based email templates. All email templates and autoresponders must be rebuilt from scratch. **Widget code vs. widget data.** The KMT transfers Page Builder widget *data* (the JSON stored in the `CMS_Document` `DocumentPageBuilderWidgets` column). It does not transfer widget *code* (ViewComponents, controllers, views). After migration, pages with widgets render in a degraded or blank state until widget code is rebuilt. If your KX13 site used the MVC development model rather than .NET Core Page Builder, the adaptation effort is higher — MVC controllers and partial views must be ported to ViewComponents. **Media path assumptions.** Content referencing media via direct file URLs (e.g., `/SiteName/media/folder/image.jpg`) instead of the `~/getmedia/` handler won't resolve after migration. The `~/getmedia/` handler itself changes path format in XbyK. Audit and configure regex transformations in the KMT field mapping config before running the tool. **Multilingual fallback behavior.** If your KX13 content relied on language fallback (untranslated pages display in the default language), that behavior does not carry over. XbyK language variants without content render as empty, not as fallback. This affects both content display and URL routing for multilingual sites. **CI/CD serialization conflict.** If your XbyK project uses CI/CD repository serialization (which it should for any team environment), content type definitions created by the KMT in the database must also be serialized to the repository. If they aren't, the next CI/CD deployment will delete or overwrite them. Configure `CIRepositoryPath` in the KMT settings or run serialization sync manually after each migration pass. **KMT version mismatch.** Running a KMT release that doesn't match your target XbyK version produces schema errors that are difficult to diagnose. Always verify version compatibility in the KMT release notes before configuring. ## How long does a Kentico to XbyK migration take? Keep the two clocks separate: the replatform project and the data migration. ### The replatform project (months) Redesigning templates, rewriting custom integrations for .NET 8+, and retraining editors is a software engineering project. Enterprise rebuilds routinely take 6 to 12 months depending on site complexity and team capacity. The variables are: number of custom page types, number of integrations, depth of Page Builder widget library, and marketing automation complexity. Kentico's own documentation states it is "not possible to provide a universal estimate for timeline or costs." ### The data migration (days) The data migration — moving content, contacts, media, forms — is duration-bounded by data volume, record complexity, and any API rate limits on the target environment. These estimates assume direct SQL access to both databases (self-managed deployment), no SaaS API rate limiting, and a moderately complex content model with 5–15 content types: | Data Volume | Estimated Duration | Notes | |---|---|---| | Under 1,000 records total | Under 24 hours | Includes validation passes | | 1–500 documents | 1–2 business days | Typical small site | | 500–5,000 documents | 3–7 business days | Includes 2–3 iterative test runs | | 5,000+ documents | 7–14+ business days | Bulk migration + delta sync pattern | | SaaS target with API limits | Add 2–5 days | API rate limits slow write throughput | These figures describe the data migration alone, not the full replatform. The KMT itself has no documented per-hour throughput limit published by Kentico, but practical throughput depends on SQL Server IO performance, network latency between source and target databases, and the complexity of field transformations applied. Rich text transformations and media file operations are typically the throughput bottlenecks on large sites. [Full migrations for production cutover](https://clonepartner.com/blog/migrate/kentico-to-xperience-by-kentico) typically run over a weekend to minimize content freeze windows. Plan for a content freeze on the KX13 source during the final delta sync to eliminate race conditions between source edits and migration completion. ## Should you migrate to XbyK or switch CMS? This is a legitimate architectural question. The answer depends on your team's Kentico investment and the proportion of KX13 features your site actually uses. **Reasons to move to XbyK:** - Your team has .NET expertise and wants to preserve that investment - You actively use Kentico's marketing features — contacts, activities, personalization, email marketing - Your existing license terms make the transition commercially favorable - XbyK SaaS removes infrastructure management from your team's responsibilities - Your content model is complex enough that rebuilding it on a different CMS would cost more than rebuilding on XbyK **Reasons to evaluate alternatives:** - Your KX13 site is primarily a content publishing site with minimal use of marketing or commerce features — many of these migrate more cheaply to simpler headless CMS platforms - Your team wants to leave .NET entirely - The replatform cost for XbyK (license, rebuild effort) is comparable to the cost of migrating to a lower-complexity CMS - You are planning a full redesign and have no dependency on Kentico's content model structure The first step is identical regardless of destination: extract your data from KX13 in a structured, portable format. For extraction options beyond the KMT, see [How to Export Data from Kentico: Extraction Methods, API Limits & Portability](https://clonepartner.com/blog/blog/how-to-export-data-from-kentico-extraction-methods-api-limits-portability). ## XbyK deployment: SaaS vs. self-managed Your deployment model affects both the migration process and ongoing operations. | Factor | Self-Managed (Private Cloud) | SaaS (Kentico-Hosted) | |---|---|---| | Database access during migration | Direct SQL access to both source and target | Mediated through Xperience Portal; no direct SQL | | KMT execution | Runs directly against both databases | Requires coordination with Kentico for initial import | | Media storage | Filesystem or Azure Blob under your control | Azure Blob managed by Kentico | | Export limits | No platform-imposed limits | 30 exports per component per environment per month; 60-hour download window | | CI/CD serialization | Full control of repository and deployment pipeline | Kentico manages deployment; repository integration varies | | Infrastructure burden | Your team manages patching, scaling, backups | Kentico manages all infrastructure | | Migration complexity | Lower — direct database access simplifies KMT configuration | Higher — API mediation adds coordination steps | | Post-migration operations | Your team manages upgrades | Kentico applies updates; review cadence is your responsibility | Self-managed deployments are operationally simpler for migration because you control both databases. SaaS deployments add a coordination layer during initial data import but eliminate ongoing infrastructure burden post-launch. ## Making the call The KX13 end-of-support deadline is fixed at December 31, 2026. The technical shape of this migration is well-defined: the Kentico Migration Tool handles structured data transfer, your development team handles application rebuild, and the data migration is the most bounded and predictable piece of the project. Start with a content audit using the SQL queries in this guide. Run a test migration early — ideally within the first two weeks of the project — so you discover field mapping gaps, language configuration issues, and CI/CD serialization conflicts before they affect your timeline. Separate the data migration scope from the replatform scope so each can be planned, priced, and staffed independently. The KMT is a solid starting point. For gaps it doesn't cover — custom table UIs, macro replacement, widget code, email templates, marketing automation — those are replatform tasks with their own timeline and their own team. ## Frequently asked questions ### Can the Kentico Migration Tool migrate all KX13 data to Xperience by Kentico? No. The Kentico Migration Tool transfers structured content, pages, contacts, media, forms, categories, and custom tables. It does not migrate application code, email templates, marketing automation, contact groups, macro expressions, page ACLs, or password hashes. Each gap requires manual rebuilding or custom scripting in XbyK. ### How long does a Kentico to Xperience by Kentico migration take? The data migration typically completes in 1–5 business days depending on volume and complexity. Small datasets (under 10,000 records) can finish in under 24 hours. The broader replatform project — rebuilding templates, code, and integrations — is a separate effort that routinely takes 6 to 12 months for enterprise sites. ### What happens to custom tables when migrating from KX13 to XbyK? Custom tables don't exist in Xperience by Kentico. The Migration Tool moves custom table data to either custom module classes (default) or reusable content items in the Content Hub. Your team must build the admin UI, listings, and filters from scratch. ### Will user passwords migrate from KX13 to XbyK? No. Xperience by Kentico uses ASP.NET Core Identity, which hashes passwords differently than the legacy KX13 membership providers. You must implement custom authentication middleware to accept legacy hashes, or migrated users will be forced to reset their passwords. ### What version of KX13 is required to run the Kentico Migration Tool? The source must be Kentico Xperience 13 with Refresh 5 (hotfix 13.0.64) or newer. Below that version, the Migration Tool will not run. The tool also supports Kentico 12 and 11 as sources, with different transformation rules.