What is your developer-dependent CMS actually costing you? Calculate your costs and get a full report
What is your developer-dependent CMS actually costing you? Calculate your costs and get a full report
Migrating to Agility
Export a Kentico Xperience 13 or Xperience by Kentico site with the REST service, GraphQL or the .NET query APIs, then map page types, widgets, media, cultures and URLs to Agility models, pages, locales and redirects.
We last checked this guide on November 9, 2026, against Kentico's documentation for Xperience by Kentico and Kentico Xperience 13. Kentico sites differ in their customizations, so if something here doesn't match your site, Kentico's documentation for your version has the latest.
A Kentico site keeps its pages in a content tree, structures them with page types (content types in Xperience by Kentico), and lays out many pages with Page Builder widgets. The content itself maps cleanly to Agility models and linked content. The work is in the widget layouts, media URLs inside text, and the site's URL history.
This guide applies the phases in Migrating to Agility to a Kentico site.
| Product | Support status (from Kentico) | Export route |
|---|---|---|
| Xperience by Kentico | Current product. Each release is supported for at least 12 months. | Headless GraphQL API, the .NET content query API, or the database. See step 3. |
| Kentico Xperience 13 | Technical support ends December 31, 2026. During 2026 Kentico releases security hotfixes only, and from January 1, 2027 all support stops, including security repairs. | REST service, the .NET DocumentQuery API, or the database. See step 2. |
| Kentico 12 and 11 | Out of support (12: end of 2022 for MVC, end of 2023 for Portal Engine; 11: November 30, 2021). | Same as Xperience 13 for page content. |
| Kontent.ai (formerly Kentico Kontent) | A separate product and company | Use its own export tools, such as the data-ops CLI. This guide doesn't cover it. |
Support dates are from Kentico's support lifecycle and support policy pages.
Record, from the Kentico admin and the database:
Also list what isn't content: forms and their submissions, contacts and marketing data, and any commerce data. They stay in Kentico for the record, or move to whichever system will own them, such as a form provider or your CRM.
The built-in REST service runs on the admin application at /rest. Turn it on under Settings > Integration > REST, where you also choose whether it serves pages, objects or both, and whether it is read-only. Use read-only for an export.
| Request | Returns |
|---|---|
GET /rest/content/currentsite/{culture}/document/{alias path} | One page |
GET /rest/content/currentsite/{culture}/all/{alias path} | A page and every page below it |
GET /rest/content/currentsite/{culture}/childrenof/{alias path} | The pages directly below a page |
GET /rest/{object type}/... | Non-page objects, such as categories |
What to know before you script it:
format=json.version=last and selectonlypublished=false to include unpublished pages and the latest drafts. Decide which you are migrating and tell content owners.See Kentico's REST service documentation.
| Option | What you get | Use it when |
|---|---|---|
| DocumentQuery and ObjectQuery (.NET) | Pages (PublishedVersion or LatestVersion) and other objects, through Kentico's own API | You want to write the export in C#, for example a console app that references the site's Kentico packages. |
| A database read | Everything, including widget layouts | You need Page Builder data or values the REST service doesn't return. Read from a copy of the database. |
| Kentico export packages | A zip for importing into another Kentico site | Not useful here. The package is a Kentico-to-Kentico format. |
If you read the database, Kentico documents the page tables:
CMS_Tree has one row per page, whatever the number of cultures.CMS_Document has one row per page per culture. Its DocumentPageBuilderWidgets column holds the page's Page Builder widgets as JSON.DancingGoat_Article, with one row per page per culture.View_CMS_Tree_Joined joins the common columns of the tree and document tables.CMS_Attachment holds attachments stored in the database, and CMS_Relationship holds references made with Pages fields.Each headless channel has its own GraphQL endpoint, https://{your domain}/graphql/{channel GUID}, authenticated with Authorization: Bearer {API key}. What to know:
take is 100, so page through every query.MaxFieldCycleDepth setting changes this.See Kentico's headless content retrieval documentation.
| Option | What you get | Use it when |
|---|---|---|
| ContentRetriever and ContentItemQueryBuilder (.NET) | Website pages and reusable content items, through Kentico's own API | You are exporting a website channel, or want the export in C#. |
| A database read | Everything, including widget layouts | You need Page Builder data. Read from a copy of the database. |
| Continuous Integration files | Supported objects serialized as XML in App_Data\CIRepository | You already use CI and want to read the model from files. |
Kentico documents the content item tables:
CMS_ContentItem has one row per content item, with its content type and whether it is reusable.CMS_ContentItemCommonData has one row per item per language. Its ContentItemCommonDataVisualBuilderWidgets column holds the Page Builder widgets as JSON.DancingGoat_Coffee.CMS_ContentItemReference holds references between items.CMS_WebPageItem holds each page's place in the content tree, and CMS_WebPageUrlPath its URL path per language.Kentico's open-source migration tool moves Xperience 13, 12 and 11 sites into Xperience by Kentico. You don't need it to move to Agility, but its list of supported data is a clear map of where Kentico stores pages, widgets, attachments, categories, URLs and cultures. Read it before you write your own export.
| Kentico | Agility | Notes |
|---|---|---|
| Page type or content type for structured content (articles, products, people) | Content model plus a list container, and a dynamic page for each item's URL | See Generating Dynamic Pages From Content. |
| Pages in the content tree that are one-off pages | Pages in the sitemap, built from a page model and components | The tree becomes the sitemap. |
| Reusable content items (Content hub) | Content models and shared lists, referenced with linked content | |
| Page Builder widgets | Component models placed in zones | Aim for a small set of components editors can understand, not one per widget type. Widget properties become component fields. |
| Page Builder sections and editable areas | Page model zones, and layout choices in your front end | Sections are layout. Keep only the choices editors really make. |
| Pages fields and content item references | Linked Content | |
| Linked pages | One content item shown in several places, or one page plus redirects | Agility has one item per piece of content, so pick a canonical URL. |
| Categories or taxonomies | A content model and list, such as Category or Tag | Fields that reference them become Linked Content. A small fixed set can be a Drop-down List instead. |
| Media libraries, attachments and content item assets | The Agility media library | Upload the file, then reference the returned cdn.aglty.io URL from an Image or File field. |
| Cultures or languages | Agility locales | See step 6. |
| Forms | A form provider or your CRM | Rebuild forms in the tool that will receive submissions. |
For field types, map each Kentico field by what it holds: short text to Text, long or rich text to HTML, numbers to Number or Decimal, dates to Date/Time, a yes/no value to True/False, files to Image or File, and references to Linked Content. See Fields and Linked Content Field Types. A linked-content field stores its selection in two companion fields, _ValueField (the linked item's content ID) and _TextField. Read back an item you set by hand in the editor and copy that shape.
Rich text from Kentico needs some work before it belongs on the new site:
~/getmedia/{GUID}/{file name}. Look up each GUID in your media export, upload the file to the Agility media library, and rewrite the link to its cdn.aglty.io URL. Libraries can also use direct paths to the file, so look for those too.~/getattachment/{GUID}/{file name}. Treat them the same way.{% ... %} and are evaluated when a page renders. Agility stores text as written, so replace each macro with the value it produced, or remove it.divs, inline styles and classes that only the old site used. Keep headings, lists, links and tables.Legacy Content Migration covers parsing HTML into structured fields.
Kentico stores a row per page per culture: in CMS_Document and the page type's table in Xperience 13, and in CMS_ContentItemCommonData in Xperience by Kentico. URLs are per language too.
In Agility, the same content item has the same content ID in every locale. Create each item in your main locale, record its content ID, then save the same content ID in each other locale. See Creating Content and Pages in Other Locales.
Build the URL map per language, and limit each redirect to its locale where the languages use different URL prefixes.
Import in dependency order, keeping a map from Kentico GUID or ID to Agility content ID, page ID or asset URL:
Store the Kentico GUID in a SourceID Text field so re-runs update items instead of duplicating them. Use the Management SDK, saving in sequential batches and checking every result, as shown in Migrating Content into Agility with an AI Agent. Pages are created with the SDK's page methods; see Pages. An AI agent with the Agility MCP Server is a fast way to read a sample of the export, propose models and import 10 to 20 items into Staging for review first. Throughput guidance is in Migrating to Agility.
Kentico sites keep a record of URL history, so use it:
/blog/{slug}, rebuild that structure with a dynamic page and import the slug.~/getmedia/ URLs, add redirects for the important ones.For the SEO side, including titles, meta descriptions and sitemaps, follow Keep Your Search Rankings Through a Migration.
~/getmedia/, ~/getattachment/ or {% macros.