Kentico vs Kontent.ai: Architecture, TCO & Migration Guide

Kentico vs Kontent.ai: Architecture, TCO & Migration Guide

Kentico (Xperience by Kentico and its predecessor Kentico Xperience 13) is a .NET-based digital experience platform that bundles content management, marketing automation, and e-commerce into a single installable or SaaS-hosted application backed by SQL Server. Kontent.ai is a headless, API-first content management system that stores structured content independently of any presentation layer and delivers it via REST and GraphQL APIs. They share a founder — Petr Palas — and a history, but they are separate companies with separate codebases, separate pricing models, and fundamentally different architectural assumptions.

If you are comparing them, you are deciding between an integrated DXP and a composable content platform. If you are migrating between them, you are not performing a software upgrade — you are executing a fundamental architectural shift from a tightly coupled web application to a composable, API-first stack.

This guide covers the architecture, real costs, API constraints, content modeling, and migration realities between the two — with enough technical detail to support an actual platform decision.

How are Kentico and Kontent.ai related?

Kontent.ai started life inside Kentico Software. It launched as Kentico Draft in 2016, became Kentico Cloud in 2017, rebranded to Kentico Kontent in 2019, and became Kontent.ai in July 2022 after raising $40 million in growth capital to operate as an independent company. Following that investment, Kentico Software continued developing its CMS under the name Kentico Xperience, while the headless product separated entirely.

This matters because teams still confuse the two. Kentico CMS pricing and Kontent.ai pricing cover two different product lines with no shared licensing model. Kentico CMS (now Xperience by Kentico) is a full digital experience platform with a built-in content editor, page builder, and marketing tools, licensed by channel. Kontent.ai is a headless-only SaaS product with subscription pricing based on content items, environments, and users.

There is no built-in migration path between them. No upgrade tool. No shared API. No shared infrastructure. Moving content from one to the other is a cross-platform data migration requiring custom extraction, transformation, and import scripts.

Architecture: Integrated DXP vs headless content platform

Kentico (Xperience by Kentico)

Kentico is a monolithic-origin DXP modernized into a hybrid-headless platform. Hybrid-headless means the platform supports both traditional server-side rendering (via its built-in Page Builder and ASP.NET MVC routing) and headless API delivery (via REST APIs that return JSON). You can use one mode, the other, or both simultaneously — but the rendering layer, the CMS, and the database are all operated by the same vendor or your own infrastructure.

It is written in C# and runs on .NET, ASP.NET Core, and SQL Server. The content model is stored in SQL Server across several interconnected tables:

• CMS_Tree — stores the position of documents in the website content tree and basic document properties shared across all language versions.
• CMS_Document — stores page properties unique to each language version, editable region content, and widget data.
• CONTENT_<doctype> — coupled data tables storing the fields of individual document types (e.g., the News page type has a CONTENT_News table with columns like NewsTitle, NewsSummary, NewsText).
• CMS_Attachment — stores media attachments linked to documents.
• CMS_VersionHistory / CMS_Workflow — store draft versions and workflow state data; required reading if you need to migrate anything other than the latest published version.

This architecture produces specific constraints:

• Coupled routing: A document's position in the content tree determines its URL. Moving a page in the CMS automatically updates its route — but also means the URL is encoded in the tree structure, not in a portable slug field.
• Page-centric modeling: Content is built for a single web page, not for reuse across channels.
• Server-side rendering: In traditional Kentico setups, the CMS handles routing, business logic, and HTML generation via ASP.NET MVC. In hybrid-headless mode, the Delivery API returns JSON that a separate front end consumes.
• Extraction complexity: Pulling data requires SQL access or the Kentico REST API. The View_CMS_Tree_Joined view joins CMS_Tree, CMS_Document, and coupled tables — the standard extraction entry point for migration scripts.

Xperience by Kentico introduced an evergreen SaaS update model with monthly updates, replacing the major-version upgrade cycle of KX13.

Kontent.ai

Kontent.ai is a SaaS-only headless CMS. There is no database you own, no server you manage, and no rendering layer included. Content is modeled as structured content types (not page types tied to a tree), stored as content items with typed fields, and delivered through two APIs:

• Delivery API — read-only, REST and GraphQL, for fetching published content. Rate limits differ from the Management API (see API section below).
• Management API — read-write, for creating content types, content items, uploading assets, and triggering workflow. Rate-limited to 10 requests per second and 400 requests per minute, scoped per environment.

All writes — imports, schema changes, content creation — go through the Management API. The Delivery API is what your front-end application calls at runtime.

Content items live in a flat repository connected via linked items — structured references, not positional inheritance. There is no hierarchical tree. Your front end decides what constitutes a "page" and what the URL structure is.

Official SDKs: Kontent.ai publishes supported SDKs for JavaScript/TypeScript, .NET, Java, PHP, Python, Ruby, Swift, and Android. For teams migrating from Kentico's .NET stack, the .NET SDK means Kontent.ai is not inherently stack-hostile — but the content delivery pattern shifts from server-rendered MVC to API-consumed JSON, which still requires significant front-end rearchitecting.

Kontent.ai is a Microsoft partner, MACH Alliance member, and recognized by Gartner and Forrester. In March 2026, Kontent.ai launched Expert Agents — purpose-built AI agents for content operations tasks including SEO optimization, localization support, and content auditing.

Kontent.ai vs Contentful, Sanity, and Storyblok

Teams moving off Kentico frequently evaluate Kontent.ai alongside other headless CMS options. Brief positioning:

Kontent.ai's differentiators relative to these alternatives: stronger native workflow and roles model, the Expert Agents AI layer, and a .NET SDK that eases adoption for teams coming from Kentico's ecosystem.

Key architectural differences

What does Kontent.ai cost vs Kentico?

Kentico (Xperience by Kentico) pricing

Kentico's license pricing is based on a channel model, not per-user or per-server. Published entry-level figures:

• Self-managed (private cloud): ~$1,250/month
• Fully managed SaaS: ~$2,900/month

These are starting prices. Additional traffic capacity, storage, channels, or AI usage increases the license cost. Teams still on Kentico Xperience 13 typically paid $12,500–$22,300/year depending on tier (Business vs Enterprise).

The managed SaaS license includes hosting, the rendering layer, marketing automation, forms, and analytics. Infrastructure costs for self-managed deployments include Azure App Services, Azure SQL, CDN, and internal effort for hotfixes, database backups, and .NET framework upgrades.

Kontent.ai pricing

Kontent.ai operates on three commercial tiers:

The Starter tier is a sandbox, not a production tier. A Next.js application doing Incremental Static Regeneration on 50 routes every 60 seconds generates approximately 72,000 Delivery API calls per day — seven times the monthly Starter allowance in a single day.

Business and Enterprise content item limits are not publicly published; they are negotiated based on usage. If content item volume is a constraint, confirm the specific cap with Kontent.ai sales before signing.

The Kontent.ai Management API is subject to both the hard rate limit (400 calls/minute) and a monthly Fair Use Policy that governs total volume. The Fair Use Policy terms are not published numerically; heavy automation pipelines or continuous content syncs should be modeled carefully and validated with Kontent.ai before commitment.

Kontent.ai Delivery API limits: The Delivery API (used by your front-end application at runtime) has separate rate limits from the Management API. Current published limits are 500 requests per second per environment for the REST Delivery API. GraphQL Delivery API limits follow the same envelope. For most production websites, the Delivery API limit is not the binding constraint — the Management API limit during content import is.

TCO: Full delivery stack comparison

Comparing license fees alone is misleading. Kentico's SaaS license includes rendering, hosting, marketing automation, forms, and analytics. Kontent.ai's license covers the content layer only. The following table shows a representative mid-market composable stack cost alongside Kentico SaaS:

This does not make Kontent.ai more expensive in every case. Teams with existing front-end infrastructure, marketing tools already licensed, and engineering capacity to own the delivery layer can run a composable stack for less than Kentico SaaS, particularly at scale where per-channel Kentico pricing compounds. The table makes the cost structure visible so the comparison is honest.

Kentico development requires specialized .NET developers. Kontent.ai development requires modern JavaScript/TypeScript developers for the front-end application, which requires continuous maintenance independent of the CMS. Eliminating the CMS maintenance burden does not eliminate the delivery layer maintenance burden.

How do the content models differ?

This is where migrations break. The two platforms model content differently at a fundamental level.

Kentico's model is page-centric. Every piece of content lives in a tree, inherits position from its parent node, and has a page type that maps to a coupled database table. Rich text fields commonly contain inline widgets, macros ({% %}), and Page Builder JSON. Relationships are often implicit through tree position rather than explicit linked-item references.

Kontent.ai's model is item-centric. Content types define a schema. Content items are flat — no tree hierarchy. Relationships are expressed through linked items or rich text components — structured references, not positional inheritance. There is no concept of a "page" at the CMS level; your front end decides what a page is and what its URL is.

What breaks during model mapping

• Tree hierarchy → flat items. Kentico's /products/widgets/blue-widget path encodes both navigation and content relationships. In Kontent.ai, you must create taxonomy groups or linked-item fields to express these relationships, and a dedicated "Navigation" content type that links to individual pages — or rely on URL slug fields and front-end middleware to reconstruct routing.

• Page Builder widgets → rich text components. Kentico's Page Builder stores widget configurations as JSON blobs tied to editable regions. Each widget must be mapped to a Kontent.ai content type or rich text inline component. There is no bulk-conversion tool.

• Macros and dynamic expressions. Kentico macros ({% CurrentUser.UserName %}) resolve server-side at render time. Kontent.ai has no server-side execution layer. Every macro must be removed or replaced with front-end logic.

• Media attachments vs asset library. Kentico stores attachments in CMS_Attachment (document-level) or the Media Library (site-level). Kontent.ai has a centralized asset library. Every attachment binary must be extracted, uploaded to the Kontent.ai Asset API, and every reference in content must be rewritten to point to the new Kontent.ai Asset ID before import.

• Workflow states. Kentico content in a "Draft" or "Pending Review" workflow state must be explicitly mapped to Kontent.ai's workflow steps. If this mapping is omitted, content imports as "Published" regardless of its original state — potentially exposing unpublished drafts to production.

• Rich text format differences. Kontent.ai requires rich text to use specific <object> tags for inline components and linked content:

<object type="item" data-type="item" data-id="12345678-1234-1234-1234-1234567890ab"></object>

Raw Kentico HTML containing unsupported tags, unmapped macros, or Page Builder JSON will be rejected by the Management API. Every non-standard element must be mapped, converted, or stripped before import.

What are the API constraints for migration?

Both platforms impose rate limits that directly determine migration speed and script architecture.

Kontent.ai Management API

The Management API is rate-limited to 10 calls per second and 400 calls per minute, scoped per environment. Multiple API keys targeting the same environment share a single rate limit — parallelizing with multiple keys does not increase throughput.

Throughput math: Importing a single content item typically requires 3 Management API calls (create item + upsert language variant + publish). At 400 calls per minute:

• Maximum items per minute: ~133
• Maximum items per hour: ~8,000 (under optimal conditions, no retries)
• Time to import 10,000 items: ~75–90 minutes of pure API time
• Time to import 50,000 items: ~6–9 hours of API time, excluding asset uploads

Asset uploads consume additional Management API calls. For a site with 50,000 content items and 20,000 assets, the API rate limit alone dictates a multi-hour import window. Scripts must implement exponential backoff with jitter on 429 responses — any script that blasts the API without backoff will stall the entire import.

Monthly API volume is governed by Kontent.ai's Fair Use Policy (terms unpublished numerically). Automated publishing pipelines and continuous content syncs should have their call budgets modeled before plan commitment.

Kontent.ai Delivery API

The Delivery API (read-only, consumed by your front-end application) supports up to 500 requests per second per environment for REST. GraphQL follows the same envelope. For most production websites, this is not the binding constraint — the Management API limit during migration is.

GraphQL vs REST tradeoffs: The GraphQL Delivery API lets you specify exactly which fields to return, reducing payload size and round trips — valuable for complex content types with many linked items. The REST Delivery API is simpler to cache at the CDN layer and easier to use with standard HTTP tooling. For migrations and content imports, use the Management API (REST only — no GraphQL write interface). For front-end delivery, GraphQL is preferable when content types are deeply nested or field selection is highly variable.

Kentico extraction methods

We extract data from Kentico using one of three methods, in order of preference: API > JSON > CSV. API-first avoids format conversion losses; JSON preserves type information and nested structures; CSV is a last resort because it flattens nesting and loses non-string type fidelity.

• Direct SQL access — querying View_CMS_Tree_Joined and coupled tables directly. Fastest method, bypasses API rate limits, gives access to version history (CMS_VersionHistory), workflow state (CMS_Workflow), and attachment binaries. Preferred for large datasets.

• Kentico REST API — safest for extracting live data without direct database access. Adds latency and pagination overhead for large datasets.

• DocumentQuery API — custom .NET scripts using DocumentHelper.GetDocuments().Type("custom.article") to fetch specific page types and serialize to JSON. Note: this retrieves only the latest published version. Extracting drafts requires querying CMS_VersionHistory and CMS_Workflow tables directly.

The migration process: Kentico to Kontent.ai

There is no vendor-provided migration tool that moves content from Kentico to Kontent.ai. Kentico's official Migration Tool targets only the KX13 → Xperience by Kentico path. Moving from Kentico to Kontent.ai requires custom migration scripts that extract relational data, transform it into a headless-compatible format, and import it via the Kontent.ai Management API.

Step 1: Flatten the content model

Map Kentico Page Types to Kontent.ai Content Types, removing tree-based routing dependencies. Document every page type's fields, their data types, and their relationships. Identify which fields contain macros, which contain widget JSON, and which reference attachments — these require dedicated transformation logic in later steps.

Create a dedicated "Navigation" content type in Kontent.ai that links to individual page content items, or establish URL slug field conventions and front-end routing middleware to reconstruct the URL tree from flat content.

Step 2: Extract data from Kentico

Preferred method: direct SQL access to View_CMS_Tree_Joined joined to coupled tables, with separate queries to CMS_Attachment for media and CMS_VersionHistory / CMS_Workflow for draft content. Serialize to JSON, preserving field types.

For each document type, extract: NodeID, DocumentID, all coupled table fields, attachment binaries or file paths, workflow state, and language variant data.

Step 3: Migrate assets

Extract binary files from CMS_Attachment or the Kentico Media Library. Upload each binary to the Kontent.ai Asset API. Capture the returned Kontent.ai Asset ID. Build a lookup table mapping Kentico attachment IDs to Kontent.ai Asset IDs. Apply this lookup during content transformation so every asset reference in rich text and structured fields points to the correct Kontent.ai ID before import.

Step 4: Transform rich text

Parse Kentico rich text HTML using an HTML parser (not string replacement). Strip or replace:

• Macros ({% %} expressions) — remove or convert to static values or front-end-resolved tokens
• Inline widgets — convert to Kontent.ai <object> tags referencing the appropriate content item ID
• Kentico-specific HTML attributes — strip any CMS-internal attributes unsupported by Kontent.ai's rich text schema
• Attachment src references — rewrite using the asset ID lookup table from Step 3

The Management API rejects payloads containing unsupported rich text elements. Validate rich text transformation against Kontent.ai's rich text specification before importing at scale.

Step 5: Import via Management API

Import in dependency order — referenced content items must exist in Kontent.ai before they can be linked from other items. Two patterns handle this:

1. Dependency-ordered import: Analyze the content graph, topologically sort items by dependency depth, and import leaves first.
2. Two-pass import: Create all items in pass one (without populating linked-item fields), then populate content and link references in pass two once all item IDs are established in Kontent.ai.

The two-pass pattern is simpler to implement for complex content graphs. Apply exponential backoff with jitter on every 429 response. Log all failed requests with payload context for retry.

Step 6: Validate

Validation is not a spot-check — it is a systematic comparison of source and target state:

• Record-count parity: If 15,432 published articles leave Kentico, exactly 15,432 published articles must exist in Kontent.ai.
• Checksums: Hash payload fields pre-import and verify via Delivery API post-import.
• Field-level type validation: Confirm dates, booleans, and floating-point numbers survived JSON serialization intact.
• Referential integrity: Verify all linked items and asset references resolve correctly through the Kontent.ai Delivery API.
• Workflow state audit: Confirm draft content did not publish, and published content is accessible.

Common failure modes

Based on cross-platform migrations at scale, these failure modes appear consistently when migrating to a headless architecture:

• Ignoring API limits: Any import script without exponential backoff will trigger 429 errors that stall the entire import. This is not recoverable without a restart from the last checkpoint.
• Orphaned links (dependency order failure): If Page A links to Page B and Page B does not yet exist in Kontent.ai when Page A is imported, the link resolution fails silently or errors. Use dependency-ordered import or two-pass import to prevent this.
• Workflow state mismatches: Kentico content in "Draft" or "Pending Review" must be explicitly mapped to Kontent.ai workflow steps. Omitting this mapping causes draft content to publish immediately on import — a data exposure risk.
• Rich text rejection: Pushing raw Kentico HTML containing macros, widget JSON, or unsupported tags directly into Kontent.ai rich text fields causes Management API rejections. Every non-standard element must be handled before import.
• Asset ID mismatches: Failing to update asset references after uploading binaries results in broken images and file links across all content. The asset lookup table from Step 3 must be applied comprehensively before any content import begins.
• Content item limit surprises: Teams on Kontent.ai Business tier occasionally discover mid-project that their content volume exceeds the negotiated item cap. Validate your target tier's item limit against your source content count before starting the migration.

Anonymized migration example

To illustrate realistic timelines and failure patterns, here is a representative engagement (details anonymized):

Client: Financial services company, migrating from Kentico Xperience 13.

Volume: 11,800 published documents across 7 page types, 6,200 assets (images and PDFs), 3 language variants per document for key content types.

Primary complications: Rich text fields contained ~400 inline macro expressions referencing user data; Page Builder widget JSON in 2,200 documents required manual mapping to 6 Kontent.ai content types; 900 documents were in "Draft" or "Awaiting Approval" workflow states requiring explicit mapping.

Timeline:

• Content model mapping and transformation scripting: 2 days
• Asset extraction and upload to Kontent.ai Asset API: 6 hours (API rate limits were the binding constraint)
• Content import (two-pass): 4.5 hours for pass one (item creation), 3 hours for pass two (content + links)
• Rich text validation and repair cycle: 1 day (317 documents required manual review due to non-standard macro patterns)
• Full validation (record counts, field checks, referential integrity): 4 hours

Total elapsed time: 4 business days

Primary failure encountered: 317 documents contained macro expressions that did not match the expected {% %} pattern — they used a custom syntax from a third-party Kentico plugin. These required a separate parsing pass with plugin-specific rules before the Management API would accept the payloads.

When does Kentico force a decision?

Kentico Xperience 13 support ends on December 31, 2026. After this date, Kentico provides no hotfixes, security patches, or technical support for XP13. This is End of Support, not End of Life — the software continues to run, but newly discovered security vulnerabilities will not be patched, and dependencies on .NET versions and server infrastructure will continue to evolve without the CMS responding.

From January 1, 2027, any CVE affecting Kentico XP13, its .NET runtime, or its SQL Server dependencies remains unpatched by the vendor. For organizations with compliance requirements (SOC 2, PCI DSS, HIPAA), running unsupported software with unpatched CVEs creates audit findings. This is the forcing function behind most current Kentico vs Kontent.ai evaluations and the broader search for Kentico alternatives.

What does the Kentico Migration Tool actually cover?

If you are considering staying in the Kentico ecosystem (KX13 → Xperience by Kentico), here is what the official migration tool handles — and what it does not:

The Kentico Migration Tool transfers content and data models from Kentico Xperience 13, Kentico 12, or Kentico 11 to Xperience by Kentico. Code migration is not supported.

What migrates:

• Sites → Website channels
• Page types → Page content types
• Content items and documents
• Media libraries
• Custom tables
• Page Builder content (in legacy mode initially)

What does not migrate (requires manual rebuild):

• KX13 SKUs and e-commerce data
• Emails and email templates; form autoresponders
• Marketing automation workflows — these must be rebuilt from scratch in XbyK
• Custom code, customizations, and integrations
• Content models that don't align with XbyK's recommended modeling patterns

This matters for the Kentico vs Kontent.ai decision because teams assume staying in-ecosystem means a lower-friction upgrade. Migrating to Xperience by Kentico is not a version upgrade — it is a controlled replatforming that affects content modeling, custom code, integrations, and editorial workflows. If you are rebuilding significant portions of your site regardless, that is the moment to evaluate whether the Kentico ecosystem is the right fit for your next five years.

Who should choose Kentico? Who should choose Kontent.ai?

Choose Kentico (Xperience by Kentico) when:

• You need an integrated DXP with built-in marketing automation, forms, email, and analytics — and do not want to integrate and license each separately
• Your team is .NET-native and wants to stay in a familiar stack
• You want a vendor-managed rendering layer (Page Builder) alongside headless delivery
• You are already on KX13 and want the lowest-friction vendor transition
• Your content model is primarily web-page-centric, not multi-channel

Choose Kontent.ai when:

• You are adopting a composable, best-of-breed architecture with separate tools for each function
• Your content serves multiple channels (web, mobile apps, IoT, digital signage) and needs to be channel-agnostic
• You have strong front-end engineering capacity and want full control over the delivery layer
• You want to eliminate server and database infrastructure management entirely
• You are actively evaluating AI-assisted content workflows (Expert Agents, March 2026)

Neither is the right choice when:

• Kontent.ai is wrong if you expect a turnkey website with visual editing, built-in hosting, and no front-end development. You must build and host a separate application.
• Kentico is wrong if you are actively moving away from .NET and want a stack-agnostic content layer. The platform's strongest value proposition is its .NET integration depth.
• Both are wrong if your primary concern is minimizing long-term TCO without engineering investment — both require meaningful implementation effort, just in different areas.

Decision matrix: Kentico vs Kontent.ai

How ClonePartner handles Kentico to Kontent.ai migrations

ClonePartner performs data migrations — extracting content from Kentico and importing it into Kontent.ai via the Management API. We do not perform front-end rebuilds.

Our process:

1. Connect accounts — read access to the Kentico database (preferred) or REST API; Management API credentials for Kontent.ai
2. Content model mapping — document page type → content type mappings, rich text transformation rules, asset handling strategy, workflow state mapping
3. Sample migration — run unlimited sample migrations until the data maps correctly, at no additional cost
4. Full migration — bulk import via Kontent.ai Management API with exponential backoff, multi-stage validation (checksums, record-count parity, field-level type checks, referential integrity via Delivery API)
5. Delta sync — catch content changes made during the migration window; background sync with fast cutover so the source system stays operational

Pricing is one fixed price per project, starting at $500. No hourly billing, no per-record metering, no change orders. Price depends on data volume and complexity. A free 30-minute scoping call produces a fixed-price proposal.

Making the call

The Kentico vs Kontent.ai decision is an architecture decision. If your team wants an integrated DXP with .NET continuity and a vendor-managed rendering layer, Xperience by Kentico is the path of least friction from KX13. If your team is building a composable stack, needs multi-channel content delivery, and has the engineering capacity to own the front-end and delivery infrastructure, Kontent.ai provides a clean, API-first content layer — at the cost of assembling and maintaining everything the Kentico license bundles.

Neither path eliminates migration effort. The KX13 → XbyK path requires rebuilding custom code, widgets, and marketing features. The KX13 → Kontent.ai path requires rebuilding the entire delivery layer. The question is which architecture you want to operate for the next five years — and whether the migration investment is better placed in a platform that matches your future direction.

The December 2026 KX13 deadline is fixed. Content migration is the fast part — typically 1–5 days depending on volume. Front-end rebuild, integration work, and QA are the long lead items. Start scoping both in parallel, not sequentially.