How to Export Data from Xperience by Kentico: Methods, APIs & Limits

How to Export Data from Xperience by Kentico: Methods, APIs & Limits

Xperience by Kentico has no single "Export Everything" button. Your export path depends on your deployment model (SaaS vs. self-hosted), the data you need (content items, contacts, media, configuration objects), and whether you're extracting for migration, backup, or integration. The platform stores everything in Microsoft SQL Server, but direct database access is only available on self-hosted deployments — SaaS customers must work through the Xperience Portal, CI/CD serialization, the GraphQL API, or the Management API.

This matters right now because Kentico Xperience 13 (KX13) reaches End of Technical Support on December 31, 2026, after which Kentico will no longer provide hotfixes, security patches, or technical support. If you're still on KX13 and planning a move — whether to Xperience by Kentico or another platform entirely — your first step is getting the data out cleanly.

The native Export/Import feature from earlier Kentico versions generates proprietary ZIP/XML packages readable only by other Kentico instances. It's designed for Kentico-to-Kentico transfers (staging to production, version upgrades) and produces heavily fragmented XML where a single page's data is split across multiple nodes representing tree structure, document metadata, and coupled data. If you're replatforming to a headless CMS like Contentful, a SaaS platform like HubSpot, or any non-Kentico system, this format is useless without writing a complex middleware parser. You must extract the data programmatically.

This guide covers every extraction path available, what each method returns, API rate limits, and how to handle large datasets without degrading your production environment.

What Data Lives in Xperience by Kentico?

Before choosing an export method, map what you're extracting. Xperience by Kentico is a hybrid headless digital experience platform built on ASP.NET Core. Its data model spans several domains:

• Content items — pages, reusable content, headless items, and emails, all stored as structured content types in the Content Hub
• Media and assets — files stored either in the database or Azure Blob Storage (SaaS uses Blob Storage exclusively)
• Contacts and activities — visitor tracking data for digital marketing (the EMS layer)
• Form submissions — data captured via Form Builder
• Configuration objects — content types, website channels, email channels, headless channels, workflows, taxonomies, custom modules
• Page Builder data — widget configurations, sections, and templates stored as JSON within content item records
• Users and roles — administration users and member accounts

The data model differs significantly between KX13 and XbyK. In KX13, page hierarchy lives in CMS_Tree, language variations in CMS_Document, and custom fields in dedicated coupled tables (e.g., CONTENT_Article). In XbyK, content items are distributed across CMS_ContentItem (system metadata), CMS_ContentItemCommonData (properties and widget data — one row per language variant per item), and per-content-type data tables. The ContentItemIsReusable flag distinguishes reusable items managed in the Content Hub from channel-specific pages and emails.

Language variants are a silent extraction trap. Each content item in XbyK has a separate CMS_ContentItemCommonData row for each language. A bilingual site with 5,000 content items has up to 10,000 rows in this table. Any extraction query that does not filter or group by ContentItemCommonDataContentLanguageID will return duplicates or miss variants depending on how it's written.

Because of this highly normalized, relational architecture, flat CSV exports from the UI are impossible for anything beyond simple listing data. Full site content requires programmatic extraction.

Xperience by Kentico Export Methods Compared

Every row in this table has gaps. No single method exports everything you need for a clean migration.

Decision Logic: Choosing an Export Method

Use these conditional rules rather than evaluating all methods in parallel:

If deployment is SaaS:

• Need complete data (contacts, forms, content, media) → Portal database export + Portal storage export → restore database locally → query SQL
• Need content only, no direct SQL → CI/CD serialization (excludes contacts and forms) or GraphQL API (headless channel content only)

If deployment is self-hosted:

• Need everything → .bacpac export or .bak backup → restore to isolated SQL Server → query freely
• Need content only → CI/CD serialization or Management API
• Need headless delivery data → GraphQL API

If source is KX13:

• Migrating to XbyK → Kentico Migration Tool (covers contacts, activities, forms)
• Migrating to a third-party platform → KX13 REST Service (batched) or custom .NET endpoints against CMS_Tree/CMS_Document, plus separate media file download
• Have codebase access → custom .NET endpoint using DocumentHelper is faster and more flexible than the built-in REST service

If you need contacts or form submissions:

• No path other than direct SQL access (self-hosted or restored SaaS Portal export) works. CI/CD, GraphQL, Management API, and Community REST all exclude this data.

How to Export via Direct SQL Server Access (Self-Hosted)

Self-hosted Xperience by Kentico deployments — whether on-premises, on Azure VMs, or on Azure App Service with Azure SQL — give you direct SQL Server access. This is the most complete and fastest export path, especially for high-volume data.

You can:

• Run SELECT queries against any table using SSMS, sqlcmd, or the community SQL Browser package that adds a Development → SQL Browser application to the admin UI
• Export the entire database as a .bacpac via SSMS (Tasks → Export Data-tier Application) for import into Azure SQL or another SQL Server instance
• Take a full .bak backup and restore it to a separate SQL Server for extraction at your own pace

XbyK content query with language variant handling:

-- Export all content items with their content type and language
SELECT 
    ci.ContentItemID,
    ci.ContentItemName,
    ci.ContentItemIsReusable,
    cc.ContentItemCommonDataID,
    cc.ContentItemCommonDataContentLanguageID,
    ct.ClassName
FROM CMS_ContentItem ci
JOIN CMS_ContentItemCommonData cc 
    ON ci.ContentItemID = cc.ContentItemCommonDataContentItemID
JOIN CMS_Class ct 
    ON ci.ContentItemContentTypeID = ct.ClassID
-- Filter to a specific language to avoid duplicate rows:
-- WHERE cc.ContentItemCommonDataContentLanguageID = 1
ORDER BY ci.ContentItemID, cc.ContentItemCommonDataContentLanguageID

KX13 content query example (different schema):

SELECT 
    t.NodeAliasPath,
    d.DocumentName,
    d.DocumentCulture,
    c.ArticleTitle,
    c.ArticleBody
FROM CMS_Tree t
INNER JOIN CMS_Document d ON t.NodeID = d.DocumentNodeID
INNER JOIN CONTENT_Article c ON d.DocumentForeignKeyValue = c.ArticleID
WHERE t.NodeSiteID = 1 AND d.DocumentCulture = 'en-US'

Custom module data tables in both KX13 and XbyK are dynamically generated — their names follow the pattern <ModuleCodeName>_<ClassCodeName>. Query CMS_Class filtered by ClassIsCustomTable = 1 to enumerate them before scripting a bulk export.

Extracting EMS (Marketing) Data via SQL

Kentico's Enterprise Marketing Solution stores contacts, activities, and email marketing data. The OM_Activity table tracks every page visit, form submission, and login. On a high-traffic site, this table routinely exceeds 50 million rows.

Never attempt to extract OM_Activity via the REST API. It will cause out-of-memory exceptions or timeouts. Extract via direct SQL, chunking by ActivityCreated timestamps:

-- Batch extract activities in 30-day windows
SELECT * FROM OM_Activity
WHERE ActivityCreated >= '2024-01-01'
  AND ActivityCreated < '2024-02-01'
ORDER BY ActivityCreated

How Do SaaS Database Exports Work in Xperience Portal?

For SaaS deployments, Xperience Portal is your only path to a full database copy. The system provides Restore points and Exports as separate applications under Data Management.

What you can export:

• Database — current state of the environment's SQL database
• Storage — current state of files in Azure Blob Storage (media, assets, application files)
• Application service — application binaries and runtime files

Operational constraints:

• Exports are limited to 30 exports per component per environment per month (custom enterprise plans may have different allocations)
• Exported files are retained for 60 hours after creation — files are automatically deleted after this window
• Weekly restore points are created automatically on Sundays with 30-day retention; these include downloadable export data
• The June 2026 refresh changed export finalization behavior: exports now appear in the Portal while still finalizing, but the database download link is unavailable until finalization completes
• Earlier versions had a confirmed issue where exports that included the database could time out before completion and block subsequent export operations

Once downloaded, restore the database export to a local SQL Server instance and query without constraints. This is the recommended approach for SaaS customers performing full data audits or preparing for platform migration.

Can You Use CI/CD Serialization for Data Extraction?

CI/CD serialization converts database objects into XML files on the file system. Designed for environment synchronization, it can function as an export mechanism for configuration and content data — but with explicit exclusions.

The Continuous Integration feature serializes to App_Data/CIRepository:

dotnet run --no-build -- --kxp-ci-store

The Continuous Deployment feature serializes to a $CDRepository folder:

dotnet run --no-build -- --kxp-cd-store --repository-path ".\$CDRepository"

What CI/CD serializes: Content types, website/email/headless channels, page tree structure, content items (including Content Hub assets), taxonomies, custom modules and their schema, and most configuration objects.

What CI/CD does not serialize: Contacts, visitor activities, form submission data. Kentico's documentation explicitly states that "contacts representing visitors or data records submitted via forms are not supported by CI."

What CI/CD also does not capture: Version history — only the latest published state of each object. Workflow state transitions and draft versions exist only in the database.

The XML output is Kentico-specific. To use it for a non-Kentico migration, parse the XML files programmatically and transform to your target format (JSON, CSV, or direct API calls). This avoids the need for direct SQL access entirely, making it the practical choice when Portal export is rate-limited and SQL access is unavailable.

How Does the GraphQL API Work for Data Extraction?

Xperience by Kentico delivers content to headless channels via auto-generated GraphQL APIs. Each headless channel gets a typed endpoint protected by token-based authentication.

What it exposes: Only content items assigned to a headless channel — headless content items and reusable content items linked to the channel. Responses are structured JSON with typed fields matching your content type schema.

What it does not expose: Website channel pages (unless also assigned to a headless channel), contacts, form data, configuration objects, media library metadata, or Page Builder widget configurations.

Example query for content items in a headless channel:

{
  allArticle(
    where: { BasicMetadataPublicationDate: { greaterThan: "2024-01-01" } }
    first: 100
    after: "cursor_value"
  ) {
    nodes {
      system {
        id
        codename
        language
      }
      articleTitle
      articleBody
      basicMetadataPublicationDate
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

Example response structure:

{
  "data": {
    "allArticle": {
      "nodes": [
        {
          "system": {
            "id": "a1b2c3d4-...",
            "codename": "my_article",
            "language": "en-US"
          },
          "articleTitle": "Sample Article",
          "articleBody": "<p>Content here</p>",
          "basicMetadataPublicationDate": "2024-03-15T00:00:00Z"
        }
      ],
      "pageInfo": {
        "hasNextPage": true,
        "endCursor": "cursor_value_next"
      }
    }
  }
}

Language variants in GraphQL: Each language variant is returned as a separate node. Filter by where: { system: { language: { eq: "en-US" } } } to extract a specific language.

Rate limits: Xperience by Kentico does not publish rate limits for the content GraphQL API. No global rate limiter is applied by default. Only admin user management endpoints (sign-in, password reset) have built-in rate limiting via a token bucket algorithm: 100 requests capacity, replenished at 10 tokens every 6 seconds. Developers can add custom rate limiting using ASP.NET Core Rate Limiting middleware, but this is project-specific configuration, not platform-imposed.

Authentication token expiry: GraphQL API tokens do not have a documented expiry by default when created via the administration. Tokens created with custom expiration dates will return 401 responses after expiry — build token refresh logic into long-running extraction scripts.

As of April 2026, a Headless REST API is available in preview alongside GraphQL, but it is not yet production-ready for extraction workloads.

The Management API (Xperience by Kentico)

The Management API is XbyK's native REST API for programmatic content management. It differs from the community REST package and from GraphQL — it is shipped by Kentico, covers content items (not just headless channel content), and was extended in the May 2026 refresh to support retrieval of Page Builder components programmatically.

What the Management API covers:

• Content items (create, read, update, delete) across all channels
• Language variants — each variant is addressable individually via /{contentItemId}/versions/{languageCodeName}
• Page Builder section and widget data (post-May 2026 refresh)
• Content type definitions
• Media library metadata (not binary file content)

What it does not cover: Contacts, activities, form submissions, or binary file download.

Example: retrieve a content item's language variant

GET /api/v1/contentitems/{contentItemId}/versions/en-US
Authorization: Bearer {management_api_token}

Pagination: The Management API uses cursor-based pagination with continuationToken in the response header. Always check for this token and loop until it is absent.

The Management API is the most complete programmatic extraction path for content items in XbyK self-hosted or SaaS deployments when you do not have SQL access and do not need contacts or form data. Its absence from the comparison table in most third-party documentation is a notable gap.

The KX13 REST Service

If you're exporting from Kentico Xperience 13, the platform includes a built-in REST service at <admin domain>/rest. This is the standard programmatic extraction method for KX13 instances without direct SQL access.

Setup and Authentication

The REST API is disabled by default. Enable it in Settings → Integration → REST and configure authentication. KX13 supports Basic Authentication (Base64-encoded credentials in the Authorization header) or hash-based authentication.

Querying Content

GET /rest/content/currentsite/en-us/all?format=json
Authorization: Basic base64_encoded_credentials

Example response structure:

{
  "CMS_Document": [
    {
      "DocumentID": 1234,
      "DocumentName": "Sample Article",
      "NodeAliasPath": "/Blog/Sample-Article",
      "DocumentCulture": "en-US",
      "ArticleTitle": "Sample Article Title",
      "ArticleBody": "<p>Article content...</p>",
      "ArticleDate": "2024-03-15T00:00:00"
    }
  ]
}

Other key resource paths:

# Get all pages under a specific path
GET /rest/content/currentsite/en-us/all/news?format=json

# Get a single page by alias path
GET /rest/content/site/mysite/en-us/document/company/about?format=json

# Get custom page type data
GET /rest/content/currentsite/en-us/document/custom.blogpost?format=json

# Get objects by type
GET /rest/<object-type-codename>?format=json

Limits and Constraints

• No published rate limits, no response-time SLAs, no documented pagination ceiling. In practice, requesting all on a site with 50,000+ pages causes out-of-memory exceptions or gateway timeouts. Use maxrelativelevel, topn, and offset parameters to batch:

GET /rest/content/currentsite/en-us/all?topn=500&offset=0&format=json
GET /rest/content/currentsite/en-us/all?topn=500&offset=500&format=json

• Performance impact: The REST API processes requests synchronously through the Kentico application layer. Heavy queries degrade performance for live website visitors. Run bulk extractions during off-peak hours or against a staging instance.
• Relational data: The API does not automatically expand relational data (linked pages, category assignments) in a single request. Resolve DocumentCategoryIDs or NodeLinkedNodeID via secondary requests.

Community REST Endpoints (Xperience by Kentico)

Xperience by Kentico does not include the built-in REST service from KX13. Kentico ships a community-maintained REST integration via the xperience-by-kentico-community-rest NuGet package.

Current documented limitations: Managing web pages and content items is not implemented. Uploading binary assets is also unsupported. The endpoints handle configuration objects and custom module data — useful for exporting configuration state, insufficient for content migration.

For content extraction in XbyK, use the Management API instead.

Custom .NET Endpoints (KX13)

If you have access to the KX13 codebase, custom API endpoints using the Kentico API (DocumentHelper, UserInfoProvider) are often the most reliable and performant extraction method. A custom endpoint lets you flatten CMS_Tree and CMS_Document data, resolve media URLs, strip Kentico-specific metadata, and shape output to match your target system's schema — before the data leaves the server.

var articles = DocumentHelper.GetDocuments("custom.Article")
    .Path("/Blog", PathTypeEnum.Children)
    .Culture("en-US")
    .CombineWithDefaultCulture()
    .Published()
    .Select(a => new {
        Title = a.GetStringValue("ArticleTitle", ""),
        Body = a.GetStringValue("ArticleBody", ""),
        Date = a.GetDateTimeValue("ArticleDate", DateTime.MinValue),
        Url = DocumentURLProvider.GetAbsoluteUrl(a)
    });

Expose this via a secured Web API controller. The key advantage over the generic REST service: you control response shape, can resolve relationships in a single database round-trip, and eliminate verbose Kentico-specific metadata that migration tooling doesn't need.

What Can the Admin UI Export?

The admin interface provides listing-level data export — useful for quick audits, inadequate for migrations.

In KX13: Listing pages export to XLSX, CSV, or XML. The Advanced Export dialog supports SQL WHERE conditions, ORDER BY expressions, and column selection. Disabling "Current page only" exports all matching records.

In Xperience by Kentico: The September 2026 refresh added CSV export on all listing pages. Developers enable it by calling PageConfiguration.EnableExport within ConfigurePage. The export action opens a column-selection dialog and exports all rows matching the active search and filter state.

This path works for pulling filtered user lists or a content item inventory. It does not provide relational data, linked content, Page Builder configurations, or media files.

What Does the Kentico Migration Tool Cover?

The Kentico Migration Tool is Kentico's official CLI utility for migrating data from KX13 to Xperience by Kentico. It is relevant to any team operating against the December 2026 deadline.

What it migrates: Custom object types, custom classes and their data, pages, sites (mapped to website channels), contacts, activities, forms and submitted data.

What it does not migrate:

• Page type inheritance (no equivalent in XbyK)
• Macro expressions in field defaults
• Field types with no XbyK equivalent (GUID fields, Time Interval fields) — these fields are hidden, not converted
• Email marketing campaigns, contact groups, and form autoresponders — must be rebuilt manually
• Page Builder widgets in legacy mode (legacy mode is scheduled for discontinuation; use property mapping migration for long-term compatibility)

Webhook-based incremental sync: The Migration Tool performs point-in-time extraction. For sites that cannot go dark during migration, consider a two-phase approach: bulk migration with the tool, followed by a delta sync period where changes in KX13 (tracked by DocumentModifiedWhen or ActivityCreated timestamps) are replayed into XbyK before cutover.

Handling Media Files and Attachments

Media files require separate handling from database content in every export method.

Xperience by Kentico (SaaS) stores media in Azure Blob Storage. The SaaS Portal storage export captures these files separately from the database export. Both must be downloaded.

Xperience by Kentico (self-hosted) and KX13 store media on the file system or as binary data in Media_File. Most modern implementations use the file system.

To migrate media files to a new platform:

1. Query Media_File (KX13) or CMS_ContentItem filtered by media content types (XbyK) to get file metadata: FileGUID, FilePath, FileExtension, FileName.
2. Map these records to physical files: KX13 stores them in ~/<SiteName>/media/<LibraryName>/, XbyK SaaS stores them in Azure Blob Storage at a container path matching the media library structure.
3. Upload to your target storage (AWS S3, Cloudinary, or the new CMS's media library).
4. Update inline image references in rich text. Kentico stores inline images as ~/getmedia/<guid>/filename.ext. Run a regex substitution over all HTML content fields to replace these relative paths with absolute URLs in the target system. Example pattern: ~/getmedia/([a-f0-9-]{36})/[^"]+

That last step catches most migration teams. If skipped, every inline image in migrated content becomes a broken reference.

What Can't Be Exported?

Every method has blind spots. Here's what tends to catch teams off guard:

• Language variants — each content item in XbyK has a separate CMS_ContentItemCommonData row per language. Extraction queries without explicit language filtering return unexpected row counts.
• Page Builder widget configurations — stored as JSON blobs within content item records. Direct SQL and database exports capture them; the GraphQL API does not expose them. The May 2026 refresh extended the Management API to retrieve Page Builder components programmatically, making this the preferred extraction path for Page Builder data without SQL access.
• Workflow state and version history — CI/CD serializes only the latest published state. Full version history requires a database export.
• Marketing automation rules and contact scoring models — configuration objects that do not round-trip outside the Kentico ecosystem without manual reconstruction.
• Custom module data tables — CI/CD serializes the module schema, but the underlying data tables (<ModuleCodeName>_<ClassName>) are dynamically generated. Confirm table names via CMS_Class before writing extraction queries.
• SaaS infrastructure — Azure Blob Storage contents, CDN configurations, App Service environment variables, and connection strings live outside the Xperience database and require separate export steps.
• Passwords — stored as hashed values and cannot be exported as plaintext. Plan for forced password resets on the target platform.
• Webhook and event configurations — integration configurations (Zapier connections, custom module settings) are project-specific and not portable between platforms.

How to Prepare for a Migration Out of Kentico

If you're moving data from Xperience by Kentico or KX13 to another platform, follow this sequence:

1. Audit your data model. Use SQL queries or the CI/CD store command to inventory content types, field schemas, and content item counts per type. Identify which content lives in website channels vs. the Content Hub vs. headless channels. Note how many language variants exist per content type.

2. Choose your extraction method. Self-hosted: use .bacpac or direct SQL. SaaS: download the Portal database export and restore locally. Content only with no SQL access: CI/CD serialization or the Management API. Headless channel content: GraphQL API.

3. Extract binary files separately. Media in Azure Blob Storage (SaaS) or the file system (self-hosted) must be exported independently from database content. Catalog files by GUID before extracting to preserve mapping to content records.

4. Map relational data. Content items reference each other via ContentItemReference fields and GUIDs (XbyK) or NodeLinkedNodeID and DocumentCategoryIDs (KX13). Migration scripts must preserve these references or translate them to the target system's link model.

5. Plan for contacts and form data. Excluded from CI/CD serialization, GraphQL, and the Management API. Requires direct SQL access or a full database export.

6. Account for language variants. Every bilingual or multilingual site has multiple rows per content item in CMS_ContentItemCommonData. Validate row counts against expected content item counts before and after extraction.

Start scoping at least 3–4 months before your deadline — especially with the KX13 support end date creating urgency across the ecosystem.

What Can't Be Done via Webhooks or Event-Driven Extraction?

Xperience by Kentico does not ship a native outbound webhook system for content events (publish, update, delete). There is no built-in mechanism to stream content changes to an external system in real time.

Workarounds for incremental extraction:

• Management API with timestamp filtering: Query content items filtered by modifiedAt or use the continuationToken pattern to retrieve only items modified since a previous extraction timestamp.
• Custom event handlers: In self-hosted deployments, implement IContentItemEventHandler in the application codebase to intercept publish events and push changes to an external endpoint. This requires codebase access and is not available on SaaS without a custom deployment.
• SQL polling: For direct-SQL deployments, poll CMS_ContentItemCommonData filtered by ContentItemCommonDataModifiedWhen on a scheduled interval.

None of these approaches match the reliability or latency of a native webhook system. For migrations with live production sites, plan a final delta sync within 24 hours of cutover.

How Long Does a Kentico Data Extraction Take?

Data extraction time depends on method, volume, and the target of the extraction. These are representative ranges based on method characteristics, not service-specific guarantees:

• Small datasets (under 10,000 content items): Direct SQL or Management API extraction completes in hours. CI/CD serialization for the same volume typically runs under 30 minutes.
• Medium datasets (10,000–50,000 content items, no EMS data): Direct SQL with optimized queries: under 8 hours. Management API with pagination: 1–3 days depending on network latency and rate of API calls.
• Large implementations (50,000+ content items, millions of EMS activity records): SQL extraction of OM_Activity alone may take hours for tables over 50 million rows. Plan for batched extraction over multiple days. EMS data should always be extracted via SQL — never via API.
• SaaS Portal export: Export finalization time is variable and depends on database size. Kentico does not publish SLA figures for finalization duration.

Media file migration time is entirely dependent on file count, average file size, and upload bandwidth to the target storage. Budget separately from database extraction.

When the Export Is the Easy Part

Getting data out of Xperience by Kentico is tractable if you have the right access level: SQL Server on self-hosted, or Portal database exports on SaaS. The harder work is transformation — mapping structured content types to your target system's model, preserving relational links, handling Page Builder JSON blobs, accounting for language variants, and replacing inline getmedia image references before they become broken links in production.

At ClonePartner, we've handled Kentico data migrations across our 1,500+ completed projects, with a preference for API-first extraction (Management API or GraphQL where available, SQL for contacts and EMS data) and a dedicated engineer owning each project from scoping through delta sync. If you're facing a KX13 end-of-support deadline or moving off Xperience by Kentico, a 30-minute scoping call is where we start.