How to Export Data from Kentico: Extraction Methods, API Limits & Portability

How to Export Data from Kentico: Extraction Methods, API Limits & Portability

Kentico (both Kentico Xperience 13 and the newer Xperience by Kentico) is a complex, highly relational .NET content management system. When migrating away from Kentico — to WordPress, Contentful, Sanity, or any other platform — operators quickly discover that the native export features are not designed for data portability.

If your goal is a complete, structured extract — page content, media, metadata, custom module data, and configuration — you need to understand each extraction path, what it actually outputs, and where it breaks.

KX13 urgency note: Kentico Xperience 13 reaches end of support on December 31, 2026. After that date, Kentico provides no hotfixes, security patches, or technical support. Existing KX13 instances continue to run but as fully unsupported software. As of January 1, 2026, KX13 has already entered security-only support — no new features, no functional bug fixes, only security hotfixes through EOL.

For context on why flat CSV exports struggle with relational CMS data like Kentico's content tree, see our breakdown of Using CSVs for SaaS Data Migrations.

Why the Site Export Wizard fails for replatforming

The most common mistake teams make is assuming the "Export" button in the Kentico admin UI will yield a usable data dump for a cross-platform migration. It won't.

The objects available for selection during export do not include individual pages within the content tree. To export pages, you must export entire sites with their full page tree — no selective node export is available. This is the single biggest constraint: it's all-or-nothing for content.

The wizard is accessed from the administration interface under Sites → Export site (or Export objects for non-page data). It produces a ZIP file stored in ~/CMSSiteUtils/Export containing serialized XML representations of your data. The XML schema mirrors Kentico's internal C# object model and has no published XSD or transformation documentation, which makes parsing the output for non-Kentico targets substantially harder than querying the REST API or database directly.

What the Site Export includes

Configurable toggles during export cover: Export pages, Export page histories, Export page relationships, Export page level permissions, Export blog comments, and Export event attendees. For media libraries, a separate toggle controls database-stored media records and the physical binary files themselves.

Where it breaks for external migrations

• Kentico-native format. The ZIP package is designed to be imported exclusively by another Kentico instance running the same or newer version. There is no published schema definition for the XML inside the package.
• No selective page export. Out of the box, there is no way to specify specific pages or nodes to export or import. It is the full content tree or nothing.
• Media file size risk. The "Export physical files" option is not selected by default because it can make the package size extremely large. The recommended approach is to export media files manually from the filesystem or storage provider.
• Version compatibility. A KX13 export ZIP cannot be imported into an Xperience by Kentico instance — the underlying data model is fundamentally different and there is no conversion path through the export format.

What can the REST API extract from Kentico?

The REST service allows you to retrieve page and object data from Xperience instances. It supports JSON, XML, RSS, and Atom output formats and must be explicitly enabled in Settings → Integration → REST, where you can configure whether it allows access to objects, pages, or both. The service is disabled by default.

Authentication

Kentico secures its REST API using either Basic Authentication (over HTTPS) or Hash-based URL signatures. With Hash authentication, every API request must include a hash query string parameter generated by the Kentico application. This prevents request tampering but makes programmatic extraction more complex: you cannot dynamically alter query parameters without generating a new hash for the exact URL string being signed.

Pagination: the page vs. object split

This is the detail that catches most teams building extraction scripts.

The offset parameter sets the number of the first record returned and allows paging through data. The offset parameter only works when getting object data — it is not supported for pages.

The maxrecords parameter limits the maximum number of retrieved records. For example, to load items 11–20 from object data, append ?offset=10&maxrecords=10 to the request URL. The maxrecords parameter also only works for objects, not pages.

You can paginate through users, custom module data, custom tables, and other objects — but for pages (the content you likely care most about), you receive the entire result set in one response. For sites with thousands of pages, that creates serious problems: no documented response-size cap, no cursor-based pagination, and a timeout risk that scales linearly with content volume.

REST API: no published rate limits

Kentico publishes no rate limits, response-time SLAs, or API performance benchmarks for the REST service. The Staging Sync Server uses SOAP/WCF over HTTP. The REST service has no documented caching layer, no documented pagination ceiling, and no documented include-depth behavior. For Xperience by Kentico, there are similarly no published delivery rate limits or response-time targets.

In practice, infrastructure constraints — IIS request timeouts, Azure App Service memory limits, and SQL Server query timeouts — throttle or drop aggressive concurrent requests. IIS defaults to a 110-second request timeout (executionTimeout in httpRuntime). A site with 5,000+ pages will routinely exceed this limit on a single unbounded page request. To raise the limit without switching to SQL extraction, add the following to web.config:

<httpRuntime executionTimeout="3600" maxRequestLength="2097152" />

This extends the timeout to one hour and raises the request size ceiling to 2 GB. Note this is a mitigation, not a fix — for sites above approximately 10,000 pages, SQL extraction is more reliable than any REST-based approach.

REST API extraction example

To retrieve all cms.article pages in JSON for a given site:

GET /rest/content/currentsite/en-us/all?classnames=cms.article&coupleddata=true&format=json

To retrieve only cms.article pages, append ?classnames=cms.article to the request URL. The coupleddata parameter determines whether the request retrieves data stored in the fields of specific page types — without it, you get CMS metadata only, with no content field values.

To include child objects and control tree depth:

The children=true parameter indicates whether the result includes child objects. The maxrelativelevel parameter sets the maximum depth of the exported object tree structure. These two parameters together control how much of the content tree is traversed in a single request.

Known REST API limitations

• No page pagination. The offset and maxrecords parameters work only for objects. For pages, the entire result set is returned in a single response or the request fails.
• Relational depth. The API returns flat representations. If a page references a Media Library image via GUID, the API returns the GUID — you must make a secondary lookup against Media_File or the media REST endpoint to resolve it to a path.
• Performance impact on production. Querying the entire page tree on a large site forces the Kentico application pool to load and serialize all documents in memory. This can spike CPU and memory on the live instance and should be done during off-peak hours or against a read replica.
• Missing coupled data. Omitting ?coupleddata=true is the single most common extraction error — you receive CMS node metadata with no content field values from the coupled table.

How does direct SQL access work for Kentico data extraction?

Direct database access is the extraction method with the fewest artificial constraints and the fastest execution for large datasets. Kentico stores everything in Microsoft SQL Server, so SQL gives you full control over what you extract, in what order, at what concurrency, and at what pagination granularity.

The tradeoff: you need direct access to the SQL Server database. This rules out Xperience by Kentico SaaS instances, where database access is blocked — you must rely on APIs or request a database backup from Kentico support through the Xperience Portal.

KX13 database schema

Kentico's database schema is highly normalized. Content is split across multiple tables, and a simple SELECT * from any single table will not yield a usable export.

The View_CMS_Tree_Joined view handles the join between CMS_Tree, CMS_Document, and coupled data. For most extraction work, this is the correct starting point:

SELECT 
    NodeID,
    NodeAliasPath,
    DocumentName,
    DocumentContent,
    ClassName,
    DocumentCulture,
    DocumentWorkflowStepID,
    DocumentPublishedVersionHistoryID
FROM 
    View_CMS_Tree_Joined
WHERE 
    SiteName = 'YourSite'
    AND DocumentCulture = 'en-US'
    AND DocumentWorkflowStepID IS NULL  -- published documents only

Common edge cases in SQL extraction:

• NULL DocumentContent: Structured page types store content in coupled tables (CONTENT_*), not in DocumentContent. If this field is NULL for a given row, the actual field values live in the corresponding coupled table, joined on DocumentID.
• Orphaned documents: Deleted nodes can leave CMS_Document rows without a corresponding CMS_Tree entry. The view handles this, but raw table queries will surface orphaned records.
• Workflow draft versions: DocumentWorkflowStepID IS NULL filters for published documents. To include drafts, remove this filter — but expect duplicate NodeID values at different version states.
• Page type mismatches: If a page type's coupled table was dropped but CMS_Class still references it, joins on the view will silently drop those rows or throw errors depending on your query structure. Cross-reference CMS_Class.ClassTableName against INFORMATION_SCHEMA.TABLES before writing coupled-table joins.

To extract content from a specific page type including coupled data, join explicitly:

SELECT 
    t.NodeAliasPath,
    d.DocumentName,
    d.DocumentCulture,
    a.ArticleTitle,
    a.ArticleText,
    a.ArticleSummary
FROM 
    CMS_Tree t
    INNER JOIN CMS_Document d ON t.NodeID = d.NodeNodeID
    INNER JOIN CONTENT_Article a ON d.DocumentForeignKeyValue = a.ArticleID
WHERE 
    t.NodeSiteID = 1
    AND d.DocumentCulture = 'en-US'
    AND d.DocumentWorkflowStepID IS NULL

The Xperience by Kentico (XbyK) schema shift

Xperience by Kentico (built on .NET Core) uses a completely different database schema. The CMS_Tree / CMS_Document architecture has been replaced by the Content Hub model.

Content is now stored across three primary tables:

There are no coupled tables in XbyK — all field data for a content type lives in CMS_ContentItemCommonData as structured JSON within the ContentItemCommonDataPageBuilderWidgets field or in discrete columns depending on content type configuration. Extracting XbyK content via SQL requires parsing JSON column values in addition to relational joins.

Version differences: KX11, KX12, KX13, XbyK

The Kentico Migration Tool supports KX11, KX12, and KX13 as source systems, but the schema differs across versions:

KX11 and KX12 share the same general extraction pattern as KX13 but may lack certain columns (KX11 predates Page Builder entirely). Always verify column existence against INFORMATION_SCHEMA.COLUMNS before running extraction queries against older versions.

Workflow versions caveat

If you use Kentico's versioning, CMS_Document contains draft and archived versions alongside the published version. Filter on DocumentWorkflowStepID IS NULL for published-only extraction. Omitting this filter returns all versions, including drafts that may contain unpublished or incomplete content.

Continuous Integration as an extraction path

Kentico provides a continuous integration solution that serializes database objects into XML files on the file system. The system stores these XML files in CMS\App_Data\CIRepository.

CI was designed for team development workflows, not data migration. However, it produces structured, deterministic XML that represents your configuration objects in a machine-readable format and can be version-controlled.

What CI exports well: Page types, page templates, custom module classes, form definitions, settings keys, scheduled tasks, and other configuration objects.

What CI does not export: Continuous integration always works with the main version of each object. Older versions, deleted versions, and non-published versions of pages are excluded. Physical media binaries are never included — CI serializes metadata only. Page content itself may or may not be included depending on your version and CI configuration.

For KX13, enable CI via Continuous integration in the admin UI, then click Serialize all objects. The resulting CIRepository folder gives you a file-system-based representation of your configuration.

Practical limitation: A large Kentico site generates tens of thousands of individual XML files. Parsing these files requires writing a custom deserialization script and understanding Kentico's internal object serialization conventions, which are not publicly documented via XSD.

Content Staging and Staging Module

Kentico's Content Staging module (distinct from CI) allows synchronization of objects and pages between Kentico environments over HTTP using SOAP/WCF. While primarily designed for staging-to-production workflows, it can be used to selectively push objects between instances. It is not a general-purpose export mechanism — it requires a target Kentico instance — but it is worth evaluating if your goal is selective content migration between two live Kentico environments rather than full extraction.

What does the Kentico Migration Tool actually migrate?

The Kentico Migration Tool transfers content and other data from Kentico Xperience 13, Kentico 12, or Kentico 11 to Xperience by Kentico. The tool migrates data models and content only, reading directly from the source SQL Server database and writing to the target XbyK database. Migrations can be performed multiple times with built-in and custom data transformations.

The tool handles: pages and content types, media libraries and attachments, contacts and activities, forms and form data, consent agreements, and custom modules.

What the Migration Tool does NOT move

• KX13 emails and their content; form autoresponders from KX13 are not migrated.
• Marketing automation workflows, contact groups, personas, A/B testing configurations, social marketing, email marketing campaigns, and search configuration are all out of scope.
• KX13 categories, commerce data, and marketing entities are not captured by the auditor component.

If you're not migrating to Xperience by Kentico — for example, moving to WordPress, Contentful, or a headless CMS — the Migration Tool is irrelevant to your project. You need direct SQL extraction, REST API scripting, or a combination, since the tool only writes to an XbyK target.

For a detailed breakdown of what the official tool misses in KX13 → XbyK moves, see our post on What Kentico's Migration Tool Doesn't Move (KX13 → XbyK).

How does Xperience by Kentico handle data export differently?

If you're already on XbyK (the modern platform), the data portability picture changes significantly:

• GraphQL API delivers content from headless channels. Each headless channel auto-generates a strongly-typed GraphQL API endpoint for content delivery with union/polymorphic query optimization. This is retrieval-only — there are no mutations or subscriptions, and there is no REST content delivery API in XbyK.

Example: to query all Article content items via the XbyK GraphQL endpoint:

query {
  allArticle {
    items {
      system {
        id
        codeName
        language { name }
      }
      articleTitle
      articleText
      articleSummary
    }
  }
}

The strongly-typed schema means field names in queries map directly to content type field code names. Use GraphQL introspection (__schema) to enumerate available types and fields before writing extraction queries.

• Management API (exited preview in 2025) supports programmatic management of content types, pages, media, forms, and custom modules. As of May 2026, the Management API was extended to retrieve and manage Page Builder components and retrieve page templates.
• CI/CD in XbyK converts content and other objects from the database into XML files in a repository on the file system. The CD repository can then be deployed together with other project files.
• Database export is available through Xperience Portal for SaaS instances, with a 2 GB deployment package limit for standard operations. The SaaS custom restore feature allows uploading larger datasets to bypass this limit.

Dealing with attachments and media libraries

Extracting text content is only half the battle. Media extraction is where many Kentico migrations stall.

Kentico stores files in two distinct ways:

1. Attachments: Files attached directly to a specific page, stored in the CMS_Attachment table.
2. Media Libraries: Global file repositories, with metadata in Media_File and physical files on the filesystem or Azure Blob Storage.

Files: database vs. filesystem storage

Document attachments and CMS.File documents can be physically stored in the file system, in the database, or in both. This is configured in Settings → System → Files → Storage via the CMSStoreFilesInFileSystem and CMSStoreFilesInDatabase settings keys.

Your extraction strategy depends on this configuration:

• Database storage: Binary data lives in CMS_Attachment.AttachmentBinary. Query this column to retrieve the file bytes. If the column is NULL for a given row, files are stored on disk, not in the database.
• Filesystem storage: Attachment files live under ~/<site code name>/files/. Media library files live in their respective media library folders under ~/media/<library name>/.
• Azure Blob Storage: If your deployment uses Azure Blob Storage for media, physical files are not on the local filesystem. The Media_File table still holds metadata; the binary is in the configured blob container.

You can migrate the contents of the Media_* database tables for metadata. Media files themselves are physical files — they are not stored in the database by default — so you must copy the files separately from the filesystem or blob container. The SQL export alone does not capture binaries unless database storage was explicitly configured.

Azure Blob Storage extraction path

For Kentico deployments using Azure Blob Storage, the mapping from database metadata to physical file is as follows:

1. Query Media_File for FileGUID, FileName, FileExtension, and FilePath columns.
2. The blob path follows the pattern: <container>/<site-code-name>/media/<library-folder>/<FilePath>. Verify this against your CMSAzureAccountName and CMSAzureRootContainer settings keys.
3. Generate a SAS token with Read and List permissions on the container for bulk download. Use the Azure CLI: az storage blob generate-sas --container-name <container> --name <blob-path> --permissions r --expiry <datetime>.
4. Use azcopy sync or az storage blob download-batch to bulk-download files matching the Media_File path patterns.

For attachment blobs, the path pattern is: <container>/<site-code-name>/files/<guid-partitioned-path>/<AttachmentGUID>/<AttachmentName>. The GUID-partitioned structure uses the first two characters of the GUID as a folder prefix to distribute files across directories.

Resolving inline media references

Content stored in DocumentContent or coupled table fields often references media via Kentico's proprietary routing:

• ~/getmedia/<guid>/filename.ext — Media Library files
• ~/getattachment/<guid>/filename.ext — Page attachments

Any migration to a non-Kentico target must:

1. Query Media_File (for getmedia) or CMS_Attachment (for getattachment) using the GUID from the URL to retrieve file metadata and physical path.
2. Map that path to the physical file location (filesystem or Azure Blob).
3. Download the binary files from the storage provider.
4. Replace all ~/getmedia/ and ~/getattachment/ URL patterns in exported HTML content with the target platform's URL format.

Note: not all media references follow this pattern. Some content uses direct file URLs bypassing the getmedia handler. A full extraction script must handle both patterns.

Common Kentico export failures and how to avoid them

1. Export ZIP exceeds server memory. Large sites with media stored in the database produce multi-gigabyte export packages. The Kentico export process loads data into memory. If your IIS application pool has a memory cap (common in shared or Azure-hosted environments), the export silently fails or produces a corrupt package. Check app pool memory limits before running; consider direct SQL extraction for any site with more than a few hundred attachments stored in the database.

2. REST timeout on large page trees. Since the REST API cannot paginate page responses, requesting all pages on a site with 5,000+ documents can exceed the IIS default request timeout of 110 seconds (executionTimeout in httpRuntime). Raising this to 3600 seconds via <httpRuntime executionTimeout="3600" /> in web.config mitigates the issue for moderately large sites. For very large content trees, switch to SQL-based extraction with explicit OFFSET/FETCH NEXT pagination.

3. Missing coupled data. Omitting ?coupleddata=true on REST requests returns CMS node metadata without content field values. This is the most common "where is my content?" error in Kentico extraction scripts.

4. Attachment binary mismatch. Attachments can be stored in the database, on the filesystem, or both. If you query CMS_Attachment.AttachmentBinary and receive NULLs, files are stored on disk. Check Settings → System → Files → Storage before writing extraction logic.

5. Media library physical files not in export. The Site Export Wizard's "Export physical files" option is deselected by default because it can make the package extremely large. Teams who run the export without selecting this checkbox receive media metadata but no actual file binaries. Media files must be exported manually from the filesystem or blob container.

6. Page Builder JSON not parsed. Widget configurations are stored as serialized JSON in CMS_Document (KX13) or CMS_ContentItemCommonData (XbyK). Page Builder widgets that reference other content store only the linked item's GUID; widgets that hold their own content store the complete data in serialized format. If you're migrating to a non-Kentico target, you must parse and transform this JSON as part of the extraction pipeline — it cannot be transferred as-is.

7. NULL DocumentContent misread as empty page. Pages built with structured page types store their field data in coupled tables, not in DocumentContent. A NULL value in this column does not mean the page has no content — it means content lives in CONTENT_<PageTypeName>. Cross-reference CMS_Class.ClassTableName to identify which coupled table to join.

8. Orphaned attachments and nodes. Years of content editing leave behind attachment records with no parent document, and document records with no corresponding tree node. These surface as errors during migration if not pre-filtered. Add existence checks against CMS_Tree and CMS_Document in your extraction queries, or run a pre-migration audit using the Kentico Migration Tool's auditor component (even if you are not migrating to XbyK — the auditor output is useful diagnostically).

Which extraction method should you use?

The right choice depends on your target platform and dataset size.

Kentico data extraction is rarely a single-tool problem. The right approach almost always combines methods: SQL for content and relational data, filesystem or blob copy for media binaries, REST or CI for configuration objects, and custom scripts to resolve inline getmedia/getattachment references and parse Page Builder JSON.

What falls through the cracks regardless of method

• Inline GUID references. Content embeds ~/getmedia/ and ~/getattachment/ URLs that must be resolved to physical paths and replaced with target-platform URLs.
• Coupled table data. Actual content field values live in CONTENT_* tables, not in CMS_Document. Extracting only core CMS tables produces metadata without content.
• Page Builder JSON. Widget data requires parsing and transformation — GUIDs within the JSON reference content items that must be resolved separately.
• Orphaned attachments. Files attached to documents that no longer exist, or files that exist but are unreferenced. These cause mapping errors if not filtered before migration.
• Inconsistent page types. Long-lived Kentico sites accumulate unused page types, duplicate content structures, and abandoned custom modules. Enumerate all distinct ClassName values in your content tree before designing your extraction schema.
• Azure blob paths. If files were moved between storage configurations (disk → blob, or blob → disk), CMS_Attachment metadata may reference paths that no longer match physical file locations. Validate file existence before bulk download.

How long does a Kentico data extraction take?

When planning a migration away from Kentico, keep two timelines separate: the data extraction and the platform rebuild.

The data extraction timeline depends on three variables: total record count across content and media, the storage configuration for attachments and media (database vs. filesystem vs. blob), and whether inline references require transformation. SQL-based extraction of content records is fast — a 10,000-page site with no media generates a complete SQL dump in minutes. The slow operations are media binary retrieval (especially from Azure Blob at scale), inline reference resolution (regex scanning content fields for getmedia/getattachment patterns), and content transformation (mapping Kentico's schema to the target platform's structure).

For orientation, the dominant cost in most Kentico migrations is engineer time spent on schema mapping and transformation logic, not raw data transfer speed. A site with 500 pages and a complex custom module structure takes longer to extract cleanly than a site with 5,000 simple article pages.

The platform rebuild is a separate project. Kentico itself states it is "not possible to provide a universal estimate for timeline or costs" for building a new site. Internal rebuild projects typically take months and are scoped independently of extraction work.

We recommend beginning the data scoping and extraction process at least 3–4 months before your Kentico license expires or your internal EOL deadline, specifically to allow time for transformation logic, validation, and re-extraction after content is finalized.

Get your Kentico data out cleanly

Extracting relational content, resolving media GUIDs, and transforming normalized SQL tables into structures a target system can ingest requires custom middleware to untangle Kentico's proprietary schema. The extraction patterns described in this post — View_CMS_Tree_Joined for content, coupled table joins for field data, blob container mapping for media, and regex-based reference replacement for inline URLs — form the core of any reliable Kentico extraction pipeline.

ClonePartner specializes in Kentico data extraction and cross-platform migration, with direct experience across KX11, KX12, KX13, and Xperience by Kentico. Our transfer preference is API > JSON > CSV, but for Kentico specifically, direct SQL combined with filesystem or blob access is the most reliable path for large-scale or cross-platform migrations.

Our process:

• One fixed price per project, starting at $500. No hourly billing, no hidden fees, no change orders, and no per-record metering.
• A dedicated migration engineer owns your project from start to finish.
• Unlimited sample migrations are included until the data mapping is validated against your target platform.
• Enterprise security: SOC 2 Type II and ISO 27001 audited, with AES-256 encryption at rest, TLS 1.2+ in transit, and staging databases purged within 30 days of project close.