Kentico to WordPress Migration: A Technical Guide

Kentico to WordPress Migration: A Technical Guide

Migrating from Kentico to WordPress means extracting content from a .NET-based SQL Server database — where pages are split across CMS_Tree, CMS_Document, and per-page-type coupled data tables — transforming it into WordPress's wp_posts/wp_postmeta model, remapping media from Kentico's Media Library or Azure Blob Storage into the WordPress uploads directory, converting Page Builder widget JSON into Gutenberg block markup, and standing up 301 redirects so you don't forfeit your indexed URLs. There is no native export path that produces WordPress-ready output. Every Kentico-to-WordPress migration is a custom data engineering job.

This guide covers Kentico Xperience 13 (KX13) — the version most teams are migrating away from right now — and notes differences for older Kentico 12 and 11 instances where they matter.

Why Teams Are Moving from Kentico to WordPress

The primary driver in 2026 is the KX13 end-of-support deadline. Kentico Xperience 13 support ends on December 31, 2026. After that date, Kentico no longer provides hotfixes, security patches, or technical support. The platform keeps running, but from January 1, 2027, product updates, security hotfixes, and technical support for the version cease entirely.

The risk compounds because KX13 is built on Microsoft's .NET 6 framework, which reached end of support in November 2024, adding another layer of unpatched vulnerability exposure beyond Kentico's own EOL. Teams that haven't migrated to .NET 8 via Refresh 11 face vulnerabilities at both the CMS and framework level going unaddressed simultaneously.

For teams unwilling to undertake the complete rebuild that Xperience by Kentico requires, migrating to WordPress offers tangible advantages:

• Licensing cost. Kentico's DXP licensing (especially bundled Discovery + Content + Engagement tiers) runs into six figures annually. WordPress hosting, plugins, and development cost a fraction of that for content-focused sites.
• Editorial autonomy. Kentico's admin interface — still built on ASP.NET Web Forms and .NET Framework 4.8 — frequently bottlenecks marketing teams behind developer queues for routine content changes.
• Ecosystem scale. WordPress holds roughly 60% CMS market share, with 60,000+ plugins and a developer talent pool orders of magnitude larger than Kentico's.
• Stack simplification. If you're not actively using Kentico's personalization engine, e-commerce module, or marketing automation, you're paying for capabilities that WordPress plugins handle at a fraction of the cost.

The trade-off is real: you lose Kentico's built-in A/B testing framework, granular role-based permissions (WordPress's five default roles are significantly simpler), and native .NET integration. If those features are load-bearing for your business, evaluate them explicitly before committing to a platform change—or consider a Kentico to Umbraco migration if staying on .NET is a hard requirement.

How Kentico Stores Content (And Why It Matters for Migration)

Kentico's page database structure is the first thing you need to understand before writing a single extraction query. The Xperience database stores pages — nodes in the content tree — across several interconnected tables. A single "page" in Kentico is data spread across three or more tables, and every custom page type adds another table to the join chain:

CMS_Document relates to CMS_Tree via the DocumentNodeID field. When joining to page type tables, use DocumentForeignKeyValue, which maps to the primary key in the coupled data table. CMS_Tree → CMS_Document is a one-to-many join (one node, multiple language versions); CMS_Document → coupled table is a one-to-one join.

Kentico provides a View_CMS_Tree_Joined convenience view that joins CMS_Tree and CMS_Document, but it excludes coupled data — you need explicit JOINs for each page type. A migration script that doesn't account for this produces incomplete records missing all custom fields.

WordPress uses a flat relational model. Content lives in wp_posts. Hierarchy is loosely enforced via the post_parent column (for hierarchical post types like Pages) or through taxonomies (wp_terms, wp_term_taxonomy). Custom fields are stored as key-value pairs in wp_postmeta. To move data successfully, you must flatten Kentico's tree into WordPress Custom Post Types (CPTs), preserving parent-child relationships where they matter and discarding the tree structure where it doesn't.

Where Kentico Stores Media

Kentico has three distinct media storage mechanisms, and your instance may use all of them:

1. Media Libraries — files on the filesystem (typically ~/<sitename>/media/) or mapped to Azure Blob Storage. Metadata lives in the Media_Library and Media_File database tables.
2. Page Attachments — binary data stored directly in the CMS_Attachment table, or optionally on the filesystem. Tied to specific pages via AttachmentDocumentID.
3. Content item assets (XbyK only) — handled via CI/CD pipelines in the newer platform; not relevant for KX13 migrations.

Sites running on Kentico can contain content stored in the database (page content, site configuration, e-commerce history) and on the filesystem (media library, attachments). If your instance uses Azure Blob Storage for media, you cannot read those files directly from the database — even Kentico's own migration toolkit has this limitation. You'll need to download the blobs locally or write a script that reads from the Azure Storage SDK directly before proceeding with extraction.

How to Extract Data from Kentico for WordPress

For a detailed breakdown of every export method, see our companion post: How to Export Data from Kentico: Extraction Methods, API Limits & Portability.

The short version: direct SQL extraction is the most reliable path for cross-platform migrations. Kentico's native Site Export Wizard produces a proprietary ZIP (XML + files) designed strictly for Kentico-to-Kentico transfers — it is not parseable by WordPress importers. The REST API exists but has practical limitations that make it a poor primary extraction path.

SQL Extraction (Recommended)

Connect directly to the Kentico SQL Server database and query the joined page data. A simplified extraction query for a single page type:

SELECT 
  t.NodeID,
  t.NodeAliasPath,
  t.NodeGUID,
  d.DocumentName,
  d.DocumentPublishFrom,
  d.DocumentPublishTo,
  d.DocumentCulture,
  d.DocumentPageBuilderWidgets,
  c.ArticleTitle,
  c.ArticleSummary,
  c.ArticleText
FROM CMS_Tree t
JOIN CMS_Document d ON d.DocumentNodeID = t.NodeID
JOIN DancingGoat_Article c ON c.ArticleID = d.DocumentForeignKeyValue
JOIN CMS_Class cl ON cl.ClassID = t.NodeClassID
WHERE cl.ClassName = 'DancingGoat.Article'
  AND d.DocumentCulture = 'en-US'
ORDER BY t.NodeAliasPath

You need one query variant per page type because each coupled data table has different columns. Automate this: query CMS_Class first to enumerate all page types and their ClassTableName values, then generate extraction queries dynamically. The CMS_Class table contains one row per page type with ClassTableName giving you the coupled table name and ClassFields (an XML blob) describing the schema.

REST API Extraction (Limited)

Kentico's built-in REST service (/rest) can return page data in JSON or XML using paths like /rest/content/currentsite/en-us/all/news. But practical limitations make it unreliable as a primary extraction path:

• Pagination is supported for objects but unreliable for deeply nested page trees
• Creating (or processing) multiple objects of the same type in a single request is not supported
• Performance degrades on large datasets — the API was designed for integration, not bulk export
• The REST service must be explicitly enabled and configured in Kentico's admin settings; many production instances have it disabled

For Kentico exports specifically, SQL extraction produces cleaner, more complete datasets than the REST API for any site with more than a few hundred pages.

Mapping Kentico Content to WordPress Data Structures

Content type mapping is where most migration complexity lives. Kentico and WordPress model content differently at every level:

Before writing import scripts, configure the target WordPress environment:

1. Register CPTs in WordPress (register_post_type).
2. Recreate Kentico fields using ACF field groups.
3. Where possible, align ACF field names with Kentico coupled table column names to simplify the mapping. If Kentico has a CONTENT_CaseStudy table with a ClientName column, create a case_study CPT with an ACF field named client_name — this makes the transformation layer trivial.

Converting Page Builder Widgets to Gutenberg Blocks

In KX13, widget configurations live as JSON in the DocumentPageBuilderWidgets column of CMS_Document. WordPress Gutenberg stores blocks as HTML comments directly in post_content. These are structurally incompatible formats with no automated conversion path.

Kentico JSON example:

{
  "editableAreas": [
    {
      "identifier": "main",
      "widgets": [
        {
          "type": "Kentico.RichText",
          "properties": {
            "content": "<p>Migration is complex.</p>"
          }
        }
      ]
    }
  ]
}

WordPress Gutenberg target:

<!-- wp:paragraph -->
<p>Migration is complex.</p>
<!-- /wp:paragraph -->

Widget conversion decision framework:

The decision threshold: if your custom widget requires more than 4 hours of WordPress block development to replicate, the per-widget conversion cost exceeds what most content budgets allow for migration. For Portal Engine instances (Kentico 12 and older), the situation is worse — widget data is stored in DocumentWebParts as XML, not JSON, requiring a different parser entirely.

Common Kentico widget types and their WordPress equivalents:

Migrating the Media Library

WordPress stores all media in wp_posts under the attachment post type, with files in /wp-content/uploads/YYYY/MM/. Kentico's media lives in a fundamentally different structure, and migrating it without breaking links requires four distinct steps:

1. Extract the physical files. Download files from the Kentico ~/<site-name>/media/ directory or Azure Blob Storage container. For page attachments stored as binary in CMS_Attachment, extract the AttachmentBinary column value and write it to disk using the original AttachmentName filename.
2. Extract the metadata. Query the Media_File and CMS_Attachment tables to get original file names, alt text (FileDescription / AttachmentDescription), MIME types (FileMimeType / AttachmentMimeType), and file paths.
3. Upload to WordPress. Use the WordPress REST API (/wp-json/wp/v2/media) or WP-CLI (wp media import) to sideload the files into the WordPress uploads directory. This generates the necessary Attachment IDs and responsive image sizes. For sites with thousands of images, WP-CLI is significantly faster — each REST API upload is a separate multipart POST with authentication overhead.
4. Rewrite inline references. Kentico uses GUID-based URLs for media (e.g., /getmedia/12345678-1234-1234-1234-123456789012/image.jpg). Parse extracted HTML content using a proper HTML parser (not regex), find these GUIDs in href and src attributes, and replace them with new WordPress media URLs.

How to Import Content into WordPress

WordPress offers several import surfaces. For migration-scale imports, the REST API (/wp-json/wp/v2/) is the most programmable option.

WordPress REST API Import

import requests
import json
 
WP_URL = "https://your-site.com/wp-json/wp/v2/posts"
HEADERS = {
    "Content-Type": "application/json",
    "Authorization": "Basic <base64-encoded-credentials>"
}
 
def create_post(title, content, slug, date, status="publish"):
    payload = {
        "title": title,
        "content": content,
        "slug": slug,
        "date": date,
        "status": status
    }
    response = requests.post(WP_URL, headers=HEADERS, json=payload)
    return response.json()

Key constraints to plan for:

• WordPress core provides no built-in rate limiting for the REST API, but your hosting provider or CDN may. Managed WordPress hosts (WP Engine, Kinsta, Pressable) frequently impose their own request caps — verify before running bulk imports.
• For large imports, use sequential POST requests with exponential backoff rather than concurrent requests. Managed hosts commonly block rapid sequential requests that resemble DDoS patterns.
• Custom meta fields require either the meta parameter (only works for fields registered with show_in_rest => true) or a separate POST to /wp-json/wp/v2/posts/<id> with an update payload after the initial insert.
• ACF fields require either the ACF REST API extension or WP-CLI population via wp post meta update.

WP-CLI Import (Faster for Bulk)

For sites with direct server access, WP-CLI bypasses HTTP overhead entirely:

wp post create --post_title="My Article" \
  --post_content="$(cat article.html)" \
  --post_status=publish \
  --post_type=post \
  --post_date="2024-03-15 10:00:00"
 
# Set ACF or custom meta after post creation
wp post meta update <post_id> client_name "Acme Corp"

WP-CLI is the faster path for bulk operations when you have server access. It also allows direct import of structured HTML files without HTTP multipart encoding.

URL Mapping and Redirect Strategy

Kentico uses NodeAliasPath for URL routing — paths like /products/coffee-grinder — while WordPress uses permalink structures defaulting to /%postname%/ but configurable. Kentico also allows multiple URLs per document via the CMS_DocumentAlias table; WordPress natively supports only one slug per post.

The redirect plan:

1. Export all indexed URLs from Kentico using NodeAliasPath from CMS_Tree, joined with your sitemap or Google Search Console data. Also query CMS_DocumentAlias to capture all historical aliases — these are frequently forgotten and result in inbound link loss.
2. Map each old URL to its new WordPress slug. Where possible, preserve the path structure exactly — this avoids redirects entirely and has zero SEO impact.
3. Create 301 redirects for any URLs that must change. Use the Redirection plugin (stores rules in wp_redirection_items) or add server-level rules to .htaccess / Nginx config for better performance. Server-level redirects avoid WordPress bootstrap overhead on every redirect hit.
4. Handle Kentico-specific URL patterns:

# Redirect legacy .aspx URLs
rewrite ^/(.+)\.aspx$ /$1 permanent;

For media GUID redirects, a static Nginx rewrite cannot work without a lookup table because WordPress organizes uploads by YYYY/MM/ subdirectory — the new path is not derivable from the GUID alone. Use one of these approaches instead:

• PHP lookup endpoint: Create a WordPress endpoint that accepts a Kentico GUID parameter, queries a kentico_guid_map custom table populated during migration, and issues a 301 to the resolved URL.
• Nginx map directive: Generate a static map file from your migration's GUID mapping table and use ngx_http_map_module to resolve GUIDs to paths at the server level. This is faster and requires no PHP execution per redirect.

# Nginx map approach (generate map file from migration data)
map $uri $kentico_media_redirect {
    "~^/getmedia/12345678-1234-1234-1234-123456789012" "/wp-content/uploads/2024/01/image.jpg";
    # ... generated entries from mapping table
}
 
server {
    if ($kentico_media_redirect) {
        return 301 $kentico_media_redirect;
    }
}

SEO redirect considerations: 301 redirects pass approximately 90–99% of link equity according to Google's documented behavior. Redirect chains (old URL → intermediate URL → final URL) degrade crawl efficiency and should be collapsed to direct redirects. If your Kentico instance had .aspx URLs that were themselves already redirected, trace the full chain and set the WordPress destination as the terminal target.

Handling Multilingual Content

Kentico's CMS_Document table stores one record per language version per page, identified by DocumentCulture (e.g., en-US, de-DE, fr-FR). WordPress has no native multilingual support — you need WPML or Polylang to handle translated content.

WPML approach:

1. Extract all distinct DocumentCulture values from your Kentico database: SELECT DISTINCT DocumentCulture FROM CMS_Document.
2. Configure WPML with matching language codes before import.
3. Import the default language content first using the standard REST API or WP-CLI approach.
4. For each translation, create the translated post via the WPML REST API extension: POST /wp-json/wpml/v1/posts with the lang parameter and original_post_id linking to the default-language post.
5. Map Kentico DocumentCulture codes to WPML language codes: en-US → en, de-DE → de, fr-FR → fr.

Polylang approach:

Polylang doesn't expose a REST API for creating translated posts — you must use WP-CLI with the Polylang CLI extension or insert directly into wp_term_relationships after post creation to link language taxonomy terms.

Common multilingual failure modes:

• Importing only DocumentCulture = 'en-US' silently drops all other languages — no error, no warning, just missing content
• Language switcher URLs break if the translated posts exist but aren't linked via WPML/Polylang relationships
• Kentico's default language isn't always en-US — check CMS_Site.SiteDefaultEditorCulture to confirm your source default

What About Kentico's Own Migration Tool?

Kentico provides an official Migration Tool — but it's designed exclusively for migrating from KX13 to Xperience by Kentico (XbyK), not to WordPress or any other platform.

Due to differences in the feature set between products, the Kentico Migration Tool cannot transfer all data available in older Kentico versions — certain data types are migrated to suitable alternatives or discarded. Even for its intended target, the tool struggles with customized content models. Community reports indicate that after significant investment in configuration, teams frequently pivot to custom approaches when their content model diverges from the tool's assumptions.

For a WordPress target, the Kentico Migration Tool is irrelevant. Your options are custom SQL extraction scripts, the REST API, or a managed migration service. For more detail on what the tool does and doesn't cover, see What Kentico's Migration Tool Doesn't Move (KX13 → XbyK).

Common Failure Modes

Broken internal links. Kentico stores internal links as relative paths or GUID-based references. A find-and-replace across wp_posts.post_content after import is mandatory — but regex-based replacement misses edge cases (URLs in HTML attributes, JSON-encoded content, widget properties). Use a proper HTML parser (Python's BeautifulSoup, PHP's DOMDocument) to rewrite href and src attributes systematically.

Lost media references. If your Kentico instance stores page attachments in the database (CMS_Attachment with binary data) rather than on the filesystem, you must extract the binary via AttachmentBinary, write it to disk, upload to WordPress, build the GUID mapping, and then rewrite every content reference. Skipping any step leaves broken images site-wide with no error surfaced during import.

Orphaned multilingual content. Kentico's CMS_Document table stores one record per language version per page. If you filter to DocumentCulture = 'en-US' only, you silently drop every other language version. Extract all cultures, import into WordPress using WPML or Polylang, and map DocumentCulture codes to WordPress locale codes. Test language switcher functionality explicitly before cutover.

Permission model mismatch. Kentico's granular permission system — per-module, per-content-tree-branch, with custom roles — doesn't map to WordPress's five default roles. If you have custom Kentico roles controlling access to specific content branches, plan to either flatten them into WordPress's model (Administrator / Editor / Author / Contributor / Subscriber) or implement a membership plugin like Members or PublishPress Capabilities.

Page Builder data loss. Kentico's Page Builder widget JSON in DocumentPageBuilderWidgets has no WordPress counterpart. If you import it raw into post_content, editors see serialized JSON strings rendered as visible text on the live site. Strip it during transformation or convert it explicitly — there is no middle ground, and this is one of the most common mistakes in unmanaged migrations.

Portal Engine XML in Kentico 12 and older. In Kentico 12 and earlier using Portal Engine, widget data is stored in DocumentWebParts as XML rather than JSON. This requires a different parser from the KX13 JSON approach, and the widget type taxonomy is different. Confirm your Kentico version and editor mode before writing extraction logic.

Pre-Migration Checklist

• Identify your Kentico version. KX13, K12, or K11 — the database schema and widget storage format differ
• Enumerate all page types. Query CMS_Class WHERE ClassIsDocumentType = 1 to list every page type and its ClassTableName
• Audit media storage. Run SELECT DISTINCT FileLibraryID FROM Media_File and check for Azure Blob Storage configuration in CMS_SettingsKey where KeyName = 'CMSAzureAccountName'
• Export indexed URLs. Pull from Google Search Console or crawl with Screaming Frog. Also query CMS_DocumentAlias for historical aliases
• Map content types to WordPress. Decide which page types become Posts, Pages, or CPTs; document the mapping explicitly
• Identify widget types in use. SELECT DISTINCT JSON_VALUE(value, '$.type') FROM CMS_Document CROSS APPLY OPENJSON(DocumentPageBuilderWidgets, '$.editableAreas [0].widgets') (adjust for your SQL Server version)
• Plan multilingual handling. Check SELECT DISTINCT DocumentCulture FROM CMS_Document; choose WPML or Polylang and map locale codes
• Set up a staging WordPress instance. Never import directly into production
• Implement a content freeze. Prevent editors from making changes in Kentico during the migration window to avoid delta sync complexity
• Test redirect rules. Validate 301s for every legacy URL pattern before DNS cutover using a crawler against the staging environment

For a broader migration planning framework, see The Ultimate Knowledge Base Migration Checklist.

Running KX13 Past End of Support: The Risk Calculus

Without security hotfixes after December 31, 2026, new vulnerabilities in KX13 or its dependencies will go unaddressed. The risk compounds from multiple directions: the CMS layer (Kentico) stops receiving patches, the framework layer (.NET 6) already stopped receiving patches in November 2024, and third-party packages your solution depends on may drop .NET 6 support, creating dependency resolution failures.

The practical exposure for an internet-facing KX13 instance post-EOL:

• Unpatched CMS vulnerabilities — any XSS, CSRF, SQLi, or auth bypass discovered after January 2027 remains permanently exploitable
• Unpatched .NET 6 runtime vulnerabilities — Microsoft has already stopped backporting security fixes to .NET 6; this clock started in November 2024
• Third-party package drift — NuGet packages drop older TFM targets over time, creating build failures if you need to patch your own code

If you're evaluating whether to stay on KX13 past December 2026, we've published a detailed risk framework: Running a CMS Past End of Support: The Risk Playbook. Also see our breakdown of what actually changes when KX13 support ends.

How Long Does the Data Migration Take?

The data migration — extracting from Kentico's SQL Server, transforming, and importing into WordPress — completes within 1–13 business days in most cases, with the distribution skewing toward the lower end for straightforward content models.

Small datasets under 10,000 records with simple content models can finish in under 24 hours. Multilingual sites with complex widget configurations consistently drive the upper range.

These figures describe the data migration itself — schema extraction, transformation, import, and validation. Theme development, plugin selection, QA testing, editor training, and DNS cutover are separate workstreams. Kentico's own documentation acknowledges that universal timeline estimates for platform migrations are not possible given the variance in implementation complexity. Start the scoping conversation at least 3–4 months before your internal deadline, particularly if your instance has multilingual content, custom modules, or e-commerce data.

How ClonePartner Handles Complex CMS Migrations

We've completed 1,500+ successful migrations and built 500+ integrations. For Kentico-to-WordPress projects, our process follows a structured pattern:

1. Connect accounts — we get read access to your Kentico SQL Server database (or a backup) and your WordPress staging environment.
2. Migration audit — we enumerate your page types, media storage locations, URL structure, widget types, and multilingual configuration to produce a fixed-price proposal.
3. Sample migration — we run sample migrations on a representative subset of your content until the data maps correctly. This is included in the project price.
4. Full migration — we execute the complete data transfer and validate with record-count parity checks, field-level sampling, and referential integrity verification.
5. Delta sync — any content created in Kentico during the migration window gets synced to WordPress before cutover.

A dedicated migration engineer owns your project. We hold SOC 2 Type II and ISO 27001 certifications, with GDPR, CCPA, and HIPAA safeguards in place. NDAs and DPAs available on request; BAAs executed before any PHI transfer. Staging databases purge no later than 30 days after project close.

One fixed price per project, starting at $500.