Kentico 13 vs Xperience by Kentico: Architecture, TCO & Migration

Kentico 13 vs Xperience by Kentico: Architecture, TCO & Migration

Kentico Xperience 13 (KX13) and Xperience by Kentico (XbyK) share a vendor but not an architecture. KX13 is a monolithic .NET DXP that reaches end of support on December 31, 2026. XbyK is a ground-up rewrite on .NET 8+ with a headless-first Content Hub, an evergreen monthly release cycle, and a fundamentally different content model. Moving between them is a replatform, not a version upgrade — and deciding whether to stay in the Kentico ecosystem or leave it entirely requires understanding the technical, financial, and operational differences this guide covers.

For teams already committed to the KX13 → XbyK path, our step-by-step technical migration guide covers the data-transfer process in detail. For teams weighing XbyK against other platforms, see Xperience by Kentico Alternatives 2026 or Top Kentico Alternatives 2026.

How does the architecture differ between KX13 and XbyK?

Kentico Xperience 13 is a traditional, tightly coupled digital experience platform. The admin interface runs on .NET Framework 4.8 with a Web Forms-based UI; the live site uses ASP.NET Core. The two-application design requires web farm synchronization between admin and live instances. KX13 bundles content management, personalization, marketing automation, analytics, and e-commerce into a single monolithic installation — all modules share one database and one deployment unit.

Xperience by Kentico is a headless-first DXP rebuilt entirely on .NET 8+ (with .NET 10 support added in April 2026). "Headless-first" means that content is stored independently of its presentation layer: the same content item can be fetched via auto-generated GraphQL or REST APIs by any frontend framework, rather than being rendered exclusively by a single .NET application. The admin UI is a .NET backend paired with a React frontend. XbyK supports two rendering pipelines simultaneously:

1. Coupled rendering: A Page Builder pipeline where ASP.NET Core handles the presentation layer, architecturally similar to traditional Kentico but modernized.
2. Decoupled delivery: Auto-generated GraphQL and REST APIs for headless consumption by Next.js, Nuxt, mobile apps, or any HTTP client.

Both pipelines read from the same centralized Content Hub.

The shift is not incremental. The database schema, content model, API surface, and admin extension model are all different. The DocumentQuery API used in KX13 is replaced by ContentItemQueryBuilder in XbyK — and these APIs are not compatible. The KX13 CMS_Tree/CMS_Document table structure, which tied content to URL-based page nodes, is replaced by flat content type tables with separate channel-routing configuration. Any custom data extraction scripts, integrations, or internal tools querying the KX13 database directly will break and must be rewritten. KX13 perpetual licenses do not carry over — XbyK requires its own subscription.

Dimension	Kentico Xperience 13	Xperience by Kentico
Framework	.NET Framework 4.8 + ASP.NET Core	.NET 8+ (currently .NET 10)
Admin UI	Web Forms	React + .NET backend
Content delivery	Primarily coupled MVC, optional REST	Hybrid: Page Builder + GraphQL/REST
Content model	Page tree (CMS_Tree/CMS_Document)	Content Hub: flat content types + channel routing
Hosting	Self-hosted or cloud-hosted	SaaS (Kentico-managed) or self-managed
Update model	Major version upgrades + hotfixes	Evergreen: monthly refreshes + weekly hotfixes
E-commerce	Built-in KX13 e-commerce	New Digital Commerce Platform (no direct migration path)
AI capabilities	None native	AIRA AI suite (content writing, SEO, campaigns)

Content modeling: page tree vs Content Hub

This is where the migration gets structurally complex. KX13 organizes content in a hierarchical page tree — CMS_Tree and CMS_Document tables dictate that a piece of content exists at a specific URL node. Content is inherently coupled to its location in the tree. Reusing a case study or product description across multiple channels requires linked nodes or custom widgets, which typically produces duplicated data or brittle parent-child relationships.

XbyK replaces the page tree with a Content Hub — a flat repository where content items are instances of reusable content types, and field schemas can be shared across types. In XbyK's schema, content items live in CMS_ContentItem and typed extension tables, while routing is handled by separate channel-page configuration rather than the content record itself. Content is presentation-agnostic: the same item can feed a website page, an email, a mobile app, or a headless channel without duplication.

This paradigm shift means a direct, schema-for-schema migration from KX13 to XbyK typically produces a suboptimal result. Kentico's own migration FAQ warns that migrating content as-is often results in deep tree-based relationships that are not recommended for XbyK and can cause projects to go over budget due to extra code and missed optimization opportunities. Planning the target content model before running the migration tool is a prerequisite, not an optimization.

The most common modeling mistake: teams migrate the KX13 page tree structure intact (preserving folder nodes, parent-child URL nesting, and page-level widgets) and then discover that the resulting XbyK structure is difficult to query via the Content Delivery API and expensive to maintain. Re-architecting content models post-migration is significantly more costly than designing them correctly upfront.

What KX13 features does XbyK not yet have?

XbyK provides a more focused feature set than KX13 in several areas. Knowing what's missing — or what changed — prevents unpleasant surprises mid-project:

• E-commerce: XbyK has a new Digital Commerce Platform, but there is no direct migration path from KX13 e-commerce. Heavily customized KX13 shopping carts will require either a third-party integration (Shopify, BigCommerce) or a planned redevelopment effort on the new commerce module.
• Content personalization: KX13 page-level personalization variants do not migrate. XbyK supports personalization through Content Hub variants and dynamic widget content, but it must be reimplemented from scratch.
• Email marketing: KX13 email feeds, templates, and form autoresponders do not transfer via the migration tool. Email Builder widgets must be rebuilt. The new system separates email channels from web channels natively in the Content Hub, enabling better content reuse in newsletters — but legacy templates must be recreated.
• Marketing automation: The workflow builder in XbyK operates on a different tracking model. KX13 contact groups, scoring rules, and automation steps do not migrate because the underlying contact activity tables and trigger mechanisms have been redesigned.
• Machine translation: KX13's built-in translation module has no direct equivalent in XbyK.
• Content locking: The migration tool does not process content locking state. Pages checked out during migration may not transfer correctly.

XbyK compensates with capabilities KX13 never had: the AIRA AI suite for content creation and SEO, headless channels with auto-generated GraphQL APIs, headless activity tracking, marketing automation extensibility with custom actions, and workspaces with granular role permissions.

Authentication and security changes

KX13 used the ASP.NET Membership provider or early ASP.NET Identity implementations, often requiring complex custom code to integrate with modern SSO providers like Entra ID (formerly Azure AD) or Okta.

XbyK natively uses ASP.NET Core Identity with built-in support for OpenID Connect and OAuth 2.0, making SSO integrations for both the admin interface and the frontend significantly more straightforward. However, any custom membership providers, role-based access control scripts, or custom login web parts built in KX13 must be completely re-architected.

Password hash migration risk: If you are migrating registered member accounts, older Kentico versions used SHA-1 or SHA-256 hashing algorithms that are now considered weak. Plan either a forced password-reset flow at cutover or a hash-upgrade procedure in XbyK's Identity layer. Leaving legacy hashes in place is a security liability.

KX13 API deprecations with no XbyK equivalent

The following KX13 APIs and extension points break on XbyK with no direct replacement:

KX13 API / Pattern	XbyK Status	Notes
DocumentQuery / TreeProvider	Replaced	Use ContentItemQueryBuilder
CMSModuleLoader / macro engine	Removed	No macro engine in XbyK
Web Forms-based admin modules	Removed	Admin UI is React-based; use admin UI SDK
CMSAbstractWebPart	Removed	Page Builder uses widget components
Custom membership providers	Replaced	ASP.NET Core Identity with OIDC
SmartSearchIndexer	Replaced	XbyK uses Lucene or Algolia integrations
Inline widgets (WYSIWYG embeds)	Redesigned	Rich text fields have limited widget support in XbyK

How much does each platform cost?

Kentico does not publish exact enterprise quotes on its website. The figures below are drawn from third-party pricing trackers, partner-reported benchmarks, and publicly documented tier structures — treat them as directional starting points, not binding quotes.

Kentico Xperience 13 (license only; no longer available for new purchases):

• Business tier: starting near $12,500/year
• Enterprise tier: starting near $22,300/year
• Corporate tier: price on request

Xperience by Kentico (subscription-only — perpetual KX13 licenses do not transfer):

• Self-managed (license only): approximately $990–$1,250/month (~$12,000–$15,000/year)
• SaaS (Kentico-managed hosting + license): approximately $1,990–$2,900/month (~$24,000–$35,000/year)

These are entry-level tiers. Enterprise deployments with advanced personalization, multiple headless channels, or high contact volumes scale significantly beyond these figures. Mid-2026 partner reports indicate enterprise-level total annual spend can exceed $100,000 depending on scale and feature tier.

What does three-year TCO actually look like?

License fees are only one input. Below are three representative scenarios that anchor the ranges:

Scenario A — Small marketing site (20 pages, 1 channel, no e-commerce, self-managed):

• XbyK license (self-managed): ~$36,000 over 3 years
• Azure hosting (App Service + SQL): ~$6,000–$10,000/year → ~$21,000 over 3 years
• Implementation (content model redesign + template rebuild, ~200 hours): ~$30,000–$50,000
• Ongoing maintenance (developer time, ~2 hrs/month): ~$7,200 over 3 years
• 3-year total: ~$94,000–$114,000

Scenario B — Mid-market site with e-commerce (500 pages, 3 channels, Shopify integration, SaaS):

• XbyK SaaS license: ~$72,000–$105,000 over 3 years
• Implementation (content model + commerce integration + custom widgets, ~600 hours): ~$90,000–$130,000
• Third-party integrations (Shopify, CRM, email platform): ~$15,000–$30,000/year → ~$54,000 over 3 years
• 3-year total: ~$216,000–$289,000

Scenario C — Enterprise multi-channel (2,000+ pages, 5+ channels, full marketing automation, SaaS):

• XbyK SaaS enterprise license: ~$100,000+/year → ~$300,000+ over 3 years
• Implementation (full replatform, ~1,200+ hours): ~$150,000–$250,000
• DevOps, training, and ongoing development: ~$50,000–$80,000/year
• 3-year total: ~$600,000+

The single largest variable is implementation cost, which is driven by how much custom code exists in KX13 and how aggressively the target content model is redesigned. Teams that reuse the KX13 page tree structure in XbyK often spend 30–50% more on implementation than teams that redesign the content model upfront, because post-migration refactoring is more expensive than pre-migration planning.

What does the December 2026 end-of-support deadline actually change?

Kentico Xperience 13 reaches end of technical support on December 31, 2026. This is end of support, not end of function — your site will not stop running on January 1, 2027. But operating an unpatched digital experience platform exposes your organization to accumulating security risk with no vendor remediation path.

The support timeline has two explicit phases:

• 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 vulnerability responses, no support tickets accepted.

KX13 was originally built on .NET 6, which reached Microsoft end of support in November 2024. While Kentico subsequently updated KX13 to require .NET 8, the platform itself is receiving no further development investment. .NET 8 itself reaches end of support in November 2026, meaning that by early 2027 a KX13 deployment on .NET 8 will be running on an unsupported runtime as well as an unsupported application.

For a detailed breakdown of what changes after the deadline, see Kentico Xperience 13 End of Support 2026.

What does Kentico's migration tool actually move?

Kentico provides an open-source migration tool on GitHub that transfers structured content and data between KX13 and XbyK databases. It handles: page types, page content including Page Builder data, media libraries, custom module data, contacts, consent agreements, and forms.

The tool does not migrate:

• Application code (C# controllers, models, views), custom admin UI, or custom module UI elements
• Email templates, Email Builder widgets, or form autoresponders
• Content personalization rules
• Marketing automation configurations
• E-commerce data (no path to the new Digital Commerce Platform)
• File-system attachments not stored in the database (binary data must exist in CMS_Attachment or equivalent database tables)
• Content locking state or checked-out pages

Technical prerequisites: The tool requires KX13 Refresh 5 (hotfix 13.0.64) or newer on the source instance. Each tool release is versioned against a specific XbyK target version — running a mismatched version pair produces incomplete or broken output. Source instance API discovery automatically converts Page Builder data from KX13's serialization format to XbyK's format, but this conversion is only reliable for standard Kentico widget types; custom widgets require manual port.

What happens if a migration fails mid-cutover?

This is a common concern with no coverage in most migration guides. The XbyK migration tool is designed to be run iteratively, not as a single destructive cutover:

1. Initial full migration run: All content is transferred to the XbyK target environment. The KX13 source remains fully operational.
2. Delta sync runs: Subsequent tool executions transfer only records created or modified since the previous run, based on timestamp comparison. This allows multiple rehearsal runs without taking KX13 offline.
3. Cutover delta: A final delta sync immediately before go-live captures any content created during the migration window.
4. Rollback position: Because KX13 is never modified or taken offline during migration, rollback is always available until DNS is switched. If the XbyK deployment fails post-cutover, reverting DNS to KX13 restores service within TTL window.

The primary failure mode is not tool failure — it is content model mismatch. If target content types were defined incorrectly before migration, records import into wrong types or fail referential integrity checks. Fixing this post-migration requires a full re-run, not a patch. This is why content model design must precede migration execution.

For a detailed analysis of migration gaps, see What Kentico's Migration Tool Doesn't Move (KX13 → XbyK).

How long does a KX13 → XbyK migration take?

Two separate clocks are in play, and conflating them causes most planning failures.

Clock 1: The data migration. The transfer of content, media, contacts, and structured data from KX13's database to XbyK — via Kentico's migration tool or a custom extraction pipeline. Most data migrations complete within 1–5 business days, depending on volume, complexity, and API rate limits. Small datasets (under 10,000 records) can finish in under 24 hours. Enterprise volumes with complex relationships typically require 7–13+ business days including initial bulk migration and delta syncs.

Clock 2: The full replatform project. Redesigning content models, rebuilding page templates and widgets, rewriting custom C# code for .NET 8+, reimplementing integrations, reconstructing personalization rules, rebuilding email templates, retraining editors, and running UAT. This is measured in months, not days. Based on implementation partner benchmarks, this process typically takes 3–6 months for mid-market sites and 9–12+ months for enterprise deployments with significant custom code. Kentico's own documentation explicitly states it is not possible to provide a universal estimate for timeline or costs.

The most common causes of schedule overrun, in approximate order of frequency:

1. Content model redesign was deferred until after migration started — requiring a second full migration run after content type corrections
2. Custom KX13 widgets had no XbyK equivalent and required net-new development
3. E-commerce redevelopment (to the new Digital Commerce Platform or a third-party) was scoped separately but blocked the go-live
4. KX13 personalization rules were more extensive than initially inventoried
5. Third-party integrations queried CMS_Tree directly and required full rewrites

We recommend starting scoping at least 3–4 months before any internal deadline or the December 2026 end-of-support date to allow time for content model planning, iterative migration runs, and cutover rehearsals.

XbyK vs. competing platforms: indicative cost comparison

Teams weighing XbyK against alternatives should understand the rough cost positioning:

Platform	Model	Indicative Annual License (mid-market)	Implementation Cost (mid-market)
Xperience by Kentico	SaaS or self-managed	$24,000–$50,000	$90,000–$130,000
Optimizely CMS (SaaS)	SaaS	$40,000–$80,000+	$120,000–$200,000+
Umbraco Cloud	SaaS	$10,000–$30,000	$40,000–$80,000
Contentful (Enterprise)	SaaS	$36,000–$100,000+	$50,000–$120,000
Sanity (Team/Enterprise)	SaaS	$6,000–$50,000+	$30,000–$100,000

Implementation costs are highly variable and depend on existing codebase complexity, content volume, and integration count. These figures reflect partner-reported ranges for mid-market sites (200–1,000 pages, 2–4 integrations). The cost of rewriting .NET application code for XbyK is often comparable to the cost of migrating to a competing .NET platform like Umbraco. Non-.NET platforms (Contentful, Sanity) require a full frontend rebuild regardless of complexity.

For a detailed feature-level comparison, see Xperience by Kentico Alternatives 2026.

When to stay in the Kentico ecosystem — and when to leave

Stay on XbyK if:

• Your team is invested in .NET development and wants a single-vendor DXP rather than composing multiple best-of-breed tools
• You need integrated marketing automation, personalization, and analytics without managing separate vendor relationships
• Your editorial workflows map well to structured content types and the Content Hub model
• You don't have heavy e-commerce requirements or are willing to integrate Shopify/BigCommerce
• The license cost fits your budget at the tier you require

Evaluate alternatives if:

• You want to leave the .NET ecosystem entirely (Contentful, Sanity, and similar headless CMS platforms are frontend-agnostic)
• Your team has outgrown the integrated DXP model and prefers composable best-of-breed tools (separate CMS, CDP, marketing automation, and analytics vendors)
• TCO at the required XbyK tier exceeds what your use case can justify
• You need capabilities XbyK doesn't prioritize — notably machine translation, complex B2B commerce, or multi-tenant SaaS delivery

The cost-of-switching reality: The work required to rewrite your KX13 application code, templates, and integrations for XbyK is often within the same order of magnitude as migrating to a competing platform. This means the XbyK transition should be evaluated as a full replatforming decision, not a default upgrade path. Run the numbers for at least one alternative before committing.

Don't delay the decision. Content model planning, integration auditing, and vendor contract negotiation all take calendar time that compresses badly when deferred. Starting the evaluation 6 months before the December 2026 deadline leaves adequate time. Starting 2 months before does not.

Getting the data out — wherever you're going

Whether you're moving to XbyK, a headless CMS, or an entirely different stack, migrating your KX13 data is a discrete workstream that can start before the target platform is fully built. Extracting content from KX13's relational CMS_Tree structure, transforming it for a new content model, and loading it with full referential integrity is exactly the kind of work we do at ClonePartner.

For details on extracting data from Kentico specifically, see How to Export Data from Kentico.