Kentico vs WordPress (2026): Architecture, TCO & Migration Guide

Kentico vs WordPress (2026): Architecture, TCO & Migration Guide

Kentico is a licensed .NET digital experience platform built for enterprise marketing teams that need personalization, automation, and commerce in one stack. WordPress is an open-source PHP CMS that powers roughly 43% of all websites (W3Techs, 2025) and dominates through its plugin ecosystem, hiring pool, and near-zero licensing cost. If you're comparing the two in 2026, the decision is almost certainly driven by Kentico Xperience 13's end-of-support deadline on December 31, 2026 — and whether staying in the Kentico ecosystem or migrating to WordPress produces a better three-year cost and capability outcome.

After that date, Kentico ceases delivering security patches, hotfixes, and technical support for KX13. The site keeps running, but every unpatched vulnerability from January 1, 2027 onward becomes your liability. The risk compounds because KX13 runs on .NET 6, which reached its own end of support in November 2024 — meaning both the CMS layer and the runtime underneath are simultaneously unpatched. This double-expiry creates a security posture that most compliance frameworks (SOC 2, ISO 27001, HIPAA) treat as a material finding.

Faced with a mandatory rebuild to move to Xperience by Kentico, many engineering teams use this inflection point to re-evaluate their entire CMS architecture. Moving from Kentico to WordPress trades a tightly coupled, high-license .NET monolith for an open-source PHP ecosystem where you assemble the digital experience platform yourself.

This guide breaks down the architectural differences, three-year Total Cost of Ownership (TCO), known migration failure modes, and the data engineering mechanics required to migrate between these platforms.

How do Kentico and WordPress differ architecturally?

Kentico is a .NET-based digital experience platform (DXP) that bundles CMS, marketing automation, personalization, and e-commerce into a single product. Kentico Xperience 13 runs on ASP.NET MVC 5 and ASP.NET Core, backed by Microsoft SQL Server, and requires a Windows Server environment with IIS. The newer Xperience by Kentico is a complete rewrite on .NET 8+, with a hybrid headless architecture that delivers content through both a Page Builder (website channels) and auto-generated GraphQL endpoints (headless channels).

WordPress is an open-source CMS written in PHP, using MySQL or MariaDB for storage, and deployed on Linux (typically Apache or Nginx). Its architecture is monolithic at the core — a single application handles both the admin and the front-end — but it is extended through a plugin and theme layer. The result is extensibility rather than composability in the strict sense: plugins share a single PHP process and database connection pool, meaning they interact at runtime rather than through defined API contracts. This matters for debugging, upgrade risk, and plugin conflict surface.

Kentico's architecture was purpose-built for the enterprise marketing use case: if your team needs content personalization, journey orchestration, and built-in commerce on a Microsoft stack, it delivers those in a single license without third-party wiring. WordPress takes the opposite approach — a lightweight core extended by the widest plugin ecosystem of any CMS. That flexibility comes with integration overhead: connecting WooCommerce, a marketing automation platform, and a personalization layer means managing multiple vendors, plugin compatibility surfaces, and separate update cycles.

Database schema and content storage

Understanding the database schema is the most critical step in planning a migration, because it dictates exactly how data must be transformed and what can be lost in transit.

Kentico uses a highly normalized, relational SQL Server structure. Content is spread across multiple coupled tables:

• CMS_Tree: Manages the hierarchical structure, storing the NodeID and NodeAliasPath (the URL structure).
• CMS_Document: Stores language-specific versions of the content, workflow states, and publishing metadata.
• Custom Page Type Tables: If you create a "Blog Post" page type, Kentico generates a dedicated SQL table (e.g., CONTENT_BlogPost) with strictly typed columns for your custom fields.

WordPress uses a flat, Entity-Attribute-Value (EAV) model:

• wp_posts: Stores the core data for every piece of content — pages, posts, custom post types, media attachments, and revisions — in a single table.
• wp_postmeta: Stores all custom fields as key-value pairs.

Page Builders: MVC Widgets vs Gutenberg

Kentico Xperience 13 uses an MVC Page Builder where editors drag and drop widgets into predefined zones. Kentico stores layout and widget configuration as a complex JSON string in the DocumentPageBuilderWidgets column.

WordPress uses the Gutenberg block editor (introduced in WordPress 5.0, December 2018). Instead of storing layout data as JSON in a separate database column, WordPress stores block configurations as HTML comments directly within the post_content string:

<!-- wp:paragraph {"align":"center"} -->
<p class="has-text-align-center">This is a Gutenberg block.</p>
<!-- /wp:paragraph -->

Migrating between these paradigms requires programmatic parsing of Kentico's JSON and serialization into WordPress block markup — there is no automated converter, and the transformation must be written per widget type.

Developer talent and hiring

This is where the comparison gets asymmetric. WordPress draws from a PHP, JavaScript, and React developer pool that dwarfs Kentico's .NET specialist market. According to Stack Overflow's 2024 Developer Survey, PHP ranks among the top 10 most-used languages globally; C# ranks similarly, but .NET CMS experience specifically — not just .NET development in general — is a materially narrower hire. Kentico certifications expire every two years, the learning curve covers both the .NET ecosystem and Kentico's proprietary APIs, and experienced Kentico developers command premium rates ($80–$150/hr) in most markets. WordPress development capacity is significantly easier to source ($40–$120/hr), which has long-term implications for maintenance costs and organizational bus-factor risk.

What does Kentico cost vs. WordPress over three years?

Kentico Xperience 13 licensing starts at approximately $12,500/year for the Business tier and $22,300/year for Enterprise (verify current rates at kentico.com/pricing). The newer Xperience by Kentico starts at roughly $990/month (~$11,880/year) for self-managed and approximately $1,990–$2,900/month for the SaaS tier. Enterprise configurations with advanced DXP features can reach $100,000/year or more. Implementation partners, custom development, and hosting stack on top of these figures.

WordPress core costs nothing — it is GPL-licensed. Your spending goes to hosting, themes, plugins, and development labor. Managed WordPress hosting (WP Engine, Kinsta, Pressable) runs $30–$100/month for most business sites, with enterprise-grade managed hosting reaching $300–$500+/month for high-traffic configurations. Premium plugins and themes for a typical business site add $500–$2,000/year.

Here is a three-year TCO comparison for a mid-market marketing site (single site, moderate traffic, content-focused with basic personalization):

These ranges are intentionally wide because project scope varies enormously. The structural pattern is consistent: Kentico's licensing floor keeps TCO elevated even for straightforward sites. WordPress's cost floor is dramatically lower, but a complex enterprise WordPress build with WooCommerce, advanced caching, CDN, WAF, and custom integrations can approach $100K+ over three years — just from a different cost distribution (labor and plugin licensing rather than platform licensing).

When Kentico's TCO makes sense

Kentico's bundled DXP model earns its price when your team actively uses personalization engines, customer journey builders, and integrated commerce — features that would require four or five separate WordPress plugins plus custom middleware to replicate. If those capabilities sit unused, you're paying a platform tax for features that deliver no value. A useful diagnostic: audit actual platform feature usage in Kentico's analytics and marketing automation dashboards. If fewer than three DXP-specific features show weekly active use, the cost-benefit case for the platform tier weakens substantially.

When WordPress's TCO wins

WordPress wins on TCO when the site is primarily a content publishing platform: blogs, resource centers, news sites, marketing microsites, documentation hubs. The combination of free core, commodity hosting, and a large developer talent pool makes it difficult to justify Kentico's license cost for content-forward use cases.

What's driving the Kentico-to-WordPress migration wave in 2026?

The primary driver is the KX13 end-of-support deadline on December 31, 2026. Teams facing this deadline have three options:

1. Upgrade to Xperience by Kentico — Kentico's recommended path, but it is a complete rebuild, not a version bump. Xperience by Kentico is a ground-up rewrite with a different architecture, content model, API surface, and deployment model. Kentico's own migration toolkit explicitly documents that custom code does not carry forward and content models must be rebuilt.
2. Migrate to a different CMS — WordPress, Drupal, Umbraco, or a headless platform like Contentful or Kontent.ai.
3. Run past end of support — Technically possible, but it creates unpatched exposure across both the CMS layer (KX13) and the runtime (.NET 6), which reached its own end of support in November 2024. Most compliance frameworks flag this posture as a material finding.

For a detailed breakdown of all available alternatives including Drupal, Umbraco, and Optimizely, see our top Kentico alternatives for 2026.

What are the known migration failure modes?

Most migration guides describe only the happy path. In practice, four categories of problems account for the majority of migration failures and rework cycles:

1. Silent data loss from unmapped fields. Kentico's custom page type tables may contain fields that were deprecated in the UI but still hold production data. If your field mapping is derived from the current content type definition rather than the actual SQL table schema, those orphaned columns are never extracted. The content appears to migrate successfully — record counts match — but field data is missing. The fix is to derive field maps from INFORMATION_SCHEMA.COLUMNS against the actual database, not from Kentico's admin interface.

2. Broken media references in rich text. Kentico stores inline images in rich text columns as absolute paths referencing /CMSPages/GetFile.aspx?guid=... or similar handler URLs. These paths are invisible to a naive content extraction — they look like text, not like media assets. If the migration process only transfers media via the Media Library module and ignores inline references in DocumentContent or custom text columns, every affected page renders with broken images after the Kentico server is decommissioned. A complete migration requires regex-scanning every text column for GetFile.aspx and getattachment patterns.

3. URL structure divergence causing SEO regression. Kentico builds URLs from NodeAliasPath in CMS_Tree, which may include content type prefixes, language prefixes, or hierarchy segments that don't exist in WordPress's permalink structure. Teams frequently underestimate this gap. Migrations that launch without a complete 301 redirect map — covering every URL that has appeared in Google Search Console — typically see 20–40% organic traffic drops in the first 60–90 days post-launch. Recovery requires resubmitting sitemaps, monitoring crawl errors, and waiting for Google's re-crawl cycle, which can take 3–6 months on large sites.

4. Page Builder widget configurations that have no target. Kentico custom widgets (C# components with associated JSON configuration) have no generic WordPress equivalent. The migration tooling can extract the widget JSON, but unless a corresponding Gutenberg block, shortcode, or ACF layout exists on the WordPress side to receive it, that content either renders as raw JSON or is dropped. Every custom widget type requires a deliberate mapping decision before migration begins, not during.

5. Personalization variants that revert silently. If Kentico's content personalization is active (serving different content variants to different contact groups), the non-default variants exist in the database but are invisible to standard content extraction, which typically pulls only published default content. Sites using personalization must explicitly identify variant records and decide whether to consolidate to a single default or implement equivalent logic in WordPress before migration.

How long does a Kentico to WordPress data migration take?

The data migration — extracting content from Kentico and loading it into WordPress — typically completes within 1–5 business days, depending on data volume, complexity, and API rate limits. Small datasets under 10,000 records can finish in under 24 hours. Full migrations typically run over a weekend to minimize disruption.

By content volume:

• 1–500 pages/documents: 1–2 business days
• 500–5,000 pages/documents: 3–7 business days
• 5,000+ pages/documents: A custom engagement — usually an initial bulk migration followed by delta syncs, running approximately 7–13+ business days (actual duration depends on API rate limits, data complexity, and number of custom content types)

There is no native export from Kentico that produces WordPress-ready output. Every Kentico-to-WordPress migration is a custom data engineering job that requires explicit field mapping, widget-to-block translation, media re-hosting, and redirect map construction.

Data extraction

Our transfer preference is always API > JSON > CSV. CSV is the least preferred option because it strips hierarchical relationships and fails to handle deeply nested media references.

For Kentico, we typically extract data using the Kentico REST API or via direct SQL queries against the staging database. Direct SQL extraction is often necessary to pull the raw JSON configurations out of the DocumentPageBuilderWidgets column, which the REST API sometimes abstracts, and to catch orphaned field data in custom page type tables that is not surfaced through API responses.

Transformation and mapping

Once extracted, the data must be transformed to match WordPress's schema:

• Flattening the hierarchy: Kentico's NodeAliasPath (e.g., /Products/Software/SaaS) must be converted into WordPress parent-child post relationships, preserving the URL structure for SEO via either matching permalink slugs or explicit 301 redirects.
• Mapping custom tables to post meta: Columns from Kentico custom tables (e.g., ArticleAuthor, PublishDate) are mapped to WordPress wp_postmeta keys. This is a one-to-many transformation: one Kentico SQL column becomes one wp_postmeta row per post.
• Converting Page Builder to Gutenberg: Kentico widget JSON must be parsed and translated into WordPress block HTML comments, widget type by widget type.
• Building a redirect map: Kentico's URL patterns (often /pagetype/alias or deep hierarchical paths from CMS_Tree) rarely match WordPress's permalink structure. A 301 redirect map covering every indexed URL is non-negotiable for preserving SEO equity.
• Scanning rich text for inline media references: Every text column must be scanned for GetFile.aspx and getattachment URL patterns, assets downloaded and re-hosted in WordPress, and inline URLs updated to match new WordPress media paths.

Media library migration

Kentico stores media files in one of three locations: the database, the file system (~/CMSPages/GetFile.aspx), or Azure Blob Storage. All three require different extraction strategies.

During migration, these files must be downloaded and sideloaded into the WordPress /wp-content/uploads/ directory. Every inline image link within your page content must be programmatically updated to reflect the new WordPress media URL. Failure to address inline references results in broken images at scale when the Kentico server is decommissioned.

Continuous data sync and cutover

For enterprise sites, content editors cannot stop working for a week while the migration occurs. The standard approach is delta syncs: perform an initial bulk migration, allowing your development team to build out the WordPress front-end using real data. Once the WordPress site is approved, perform a final delta sync over a weekend, pulling only the records created or modified in Kentico since the initial extraction. This approach achieves near-zero content downtime, though cutover speed depends on the source system's API rate limits and change-tracking capabilities.

For the full technical walkthrough — SQL extraction queries, field mapping, media handling, and redirect strategies — see our Kentico to WordPress migration guide.

What content gets lost (or needs transformation) in the migration?

The data model gap between Kentico and WordPress is wide enough that certain content types don't have a 1:1 equivalent. The following categories require explicit decisions before migration begins:

• Page Builder widgets → Gutenberg blocks. Kentico's widget JSON has no direct equivalent in WordPress. Each widget type must be mapped to a Gutenberg block, a shortcode, or an ACF flexible content layout. Custom widgets need custom block development or manual rebuild. There is no automated converter.
• Personalization variants. Kentico's built-in personalization conditions (contact groups, personas, content personalization variants) do not exist in WordPress core. Active personalization requires a WordPress personalization plugin or consolidation to a single default variant — with the risk of silent variant loss described in the failure modes section above.
• Marketing automation workflows. Journey builder steps, scoring rules, and email triggers don't migrate to WordPress — they migrate to your new marketing automation platform (HubSpot, ActiveCampaign, Mailchimp, etc.). This is a parallel workstream, not a data migration task.
• Form data and form definitions. Kentico's BizForms map to Gravity Forms, WPForms, or Contact Form 7 on the WordPress side. Form definitions need rebuilding; historical submission data can be exported as CSV and imported separately.
• E-commerce catalog data. Kentico's built-in e-commerce (products, SKUs, orders, customer records) needs a target — WooCommerce is the most common. The data model translation is significant: Kentico's pricing rules, tax configurations, and shipping methods don't transfer automatically and require manual configuration in WooCommerce.
• URL structures. Kentico's URL patterns rarely match WordPress's permalink structure. A redirect map covering every URL that appears in Google Search Console — not just the current sitemap — is essential. Teams that skip this step consistently report 20–40% organic traffic drops in the 60–90 days following launch, with recovery timelines of 3–6 months depending on site authority and crawl frequency.

How does the editing experience compare?

WordPress's Gutenberg block editor (WordPress 5.0+) gives content teams a modular, drag-and-drop editing experience within a governed design system. Full-site editing (FSE), introduced progressively from WordPress 5.9, extends block editing to headers, footers, and templates. The block editor's learning curve is low for editors familiar with page builders; its constraint — that all content exists as blocks — enforces structural consistency across the site.

Kentico Xperience 13's Page Builder provides a WYSIWYG editing interface with configurable widgets and sections, but the editing workflow is more rigid — editors frequently need developer support to create new layouts or add new component types. Xperience by Kentico improves on this with a modernized admin UI, a Content Hub for reusable content across channels, and in-context visual editing, but the editing ergonomics still assume heavier developer involvement than WordPress's block editor.

For editorial teams that publish daily and iterate on page layouts frequently, WordPress gives them more independence from the development team. For marketing teams that rely on built-in A/B testing and personalization at the page level, Kentico's integrated approach means fewer tool-switching interruptions — both capabilities are in the same platform and the same admin session.

Security model: bundled vs. assembled

Kentico ships security as part of the platform: authentication, role-based access control, input validation, and XSS/CSRF protections are built in. Xperience by Kentico's SaaS deployment handles patching, and the self-managed option receives monthly security refreshes via NuGet. The trade-off is concentration risk: when a vulnerability hits a monolithic DXP, it affects every capability simultaneously. In May 2026, Kentico disclosed a critical SQL injection vulnerability (CVSS score 9.4) and a separate MFA bypass — both requiring emergency patching across all affected installations. Customers running self-managed deployments who had not applied the monthly NuGet refresh were exposed.

WordPress distributes security across core, themes, and plugins. WordPress core has a strong security track record — the security team releases patches rapidly and auto-updates are enabled by default for minor releases. The primary attack surface is the plugin layer. The average mid-market WordPress site runs 20–30 plugins, each maintained by different developers with varying security practices. Managed WordPress hosts (WP Engine, Kinsta, Pressable) mitigate plugin-layer risk with WAFs, malware scanning, and automatic core patching — but plugin hygiene and update discipline remain the site owner's responsibility.

Compliance considerations. For regulated industries (healthcare, finance, government), both platforms can meet common compliance requirements (HIPAA, SOC 2, GDPR), but the implementation path differs. Kentico's bundled model simplifies vendor audit scope: one DPA covers the platform. WordPress's assembled model distributes compliance obligations across hosting provider, plugin vendors, and any third-party integrations — each requiring its own assessment. Organizations in regulated industries should map their compliance obligations to specific plugins and hosting configurations before committing to WordPress.

Neither platform is inherently more secure. Kentico centralizes risk in the vendor; WordPress distributes it across the ecosystem. The right security posture depends on your team's operational discipline, hosting strategy, and audit requirements.

When should you stay with Kentico?

Migrating away from Kentico isn't always the right call. Consider upgrading to Xperience by Kentico if:

• Your team actively uses Kentico's built-in personalization, marketing automation, and journey orchestration — and those features are tied to measurable conversion or retention outcomes (audit actual weekly active use before making this determination).
• Your development team is invested in .NET and you have Kentico-certified developers on staff whose expertise would be stranded by a platform change.
• You need integrated e-commerce with marketing tools under a single vendor's SLA and support contract.
• Compliance requirements favor a single-vendor DXP with a unified audit surface over an assembled stack of plugins and hosting providers.
• Your organization already has Azure infrastructure, Microsoft licensing agreements, and a Microsoft-stack operations team.

One critical planning note: Xperience by Kentico is not a version upgrade from KX13. It is a rebuild. Kentico's own migration documentation confirms that custom code does not carry forward, content models must be recreated from scratch, and the deployment architecture is fundamentally different. Budget and timeline should reflect a new implementation, not an upgrade project.

When should you migrate to WordPress?

WordPress is the stronger choice when:

• Content publishing is the primary use case. Blogs, resource libraries, news sites, documentation, and marketing microsites are the use case WordPress was built for.
• Budget matters. Eliminating a five-figure annual license fee changes the three-year math significantly. The savings are structural, not one-time.
• You want hiring flexibility. PHP and WordPress developers are available in most markets at rates 20–40% below Kentico-specialist rates, and the talent pool is far larger.
• DXP features are already handled by external tools. If personalization, email marketing, and analytics already live in standalone tools (HubSpot, Google Analytics, Mailchimp), Kentico's bundled equivalents are duplicative cost with no net capability gain.
• You want ecosystem breadth. With 61,000+ free plugins in the official WordPress.org repository, WordPress has pre-built integrations for nearly every common third-party service.

Decision framework

The Kentico vs. WordPress comparison is not symmetrical. Kentico is a DXP that happens to include a CMS. WordPress is a CMS that can be extended toward DXP functionality. Choosing between them means deciding whether you want a vertically integrated platform with higher cost, narrower talent, and bundled features — or a horizontally extensible platform with lower cost, broader talent, and distributed operational responsibility.

A practical heuristic for teams on KX13 evaluating the December 2026 deadline:

For teams that are undecided: the most useful next step is an audit of your actual Kentico database — how many content types, how much media, how many custom widgets, and how deep the relational structure goes. That audit determines whether your migration is a 2-week data engineering project or a 6-month replatform, which in turn determines whether WordPress or XbyK produces the better outcome.

For a broader comparison including Umbraco, Drupal, Optimizely, and headless options, see our full Kentico alternatives guide. For the step-by-step technical migration walkthrough, see our Kentico to WordPress migration guide.

About ClonePartner's migration service

ClonePartner handles the data layer of Kentico-to-WordPress migrations: extraction, transformation, field mapping, media re-hosting, delta syncs, and redirect map generation. We do not redesign sites, rebuild themes, or manage replatform projects — that is your team's or your agency's scope.

Our process: Secure account connection → free 30-minute scoping call with fixed-price proposal and field-mapping document → unlimited sample migrations at no per-attempt cost → full bulk migration (typically run over a weekend) → delta sync before DNS cutover.

Pricing: Fixed price per project, starting at $500. No hourly billing, no hidden fees, no per-record metering.

Security: Infrastructure is protected by SOC 2 Type II and ISO 27001 controls. Data is encrypted with AES-256 at rest and TLS 1.2+ in transit. Staging databases auto-purge no later than 30 days after project close. NDAs and DPAs are available on request; a BAA is required before any PHI is processed.

We validate every migration with checksums, record-count parity, and field-level verification.