Kentico Xperience 13 End of Support 2026: What Actually Changes

Kentico Xperience 13 End of Support 2026: What Actually Changes

Kentico Xperience 13 reaches end of technical support on December 31, 2026. From January 1, 2027, Kentico ceases all support, maintenance, updates, releases, hotfixes, patches, and repairs — including security repairs. Your site keeps running. Kentico does not remotely disable anything. What changes is who owns the risk.

The common framing is wrong: Kentico's own terminology is end of support, not end of life or decommissioning. The distinction matters because your infrastructure does not stop on January 1 — it becomes unsupported software, which is a different category of problem entirely.

This guide covers what Kentico's lifecycle page actually commits to, the .NET runtime dependency that goes unsupported even earlier, the technical constraints of extracting your data, migration path comparisons, and how to plan your timeline. For a broader view of enterprise software reaching end of support this year, see our 2026 EOL Calendar.

What Kentico's Lifecycle Page Actually Says

Kentico publishes its support commitments on its Product Support Lifecycle page. Here is what it states for Xperience 13:

January 1 – December 31, 2026: Kentico continues to provide technical support via remote communication, but issues releases "only in the form of security hotfixes." No other fixes, patches, enhancements, or updates are delivered.

From January 1, 2027: Kentico will "cease all support, maintenance, updates, releases, hotfixes, patches, repairs (including security repairs), and any other services" related to Xperience 13.

Risk assumption: "Any use of Kentico Xperience 13 after December 31, 2026 will relate to the unsupported software and as such will be at your sole risk."

Liability termination: "All liability on our part related to Kentico Xperience 13 … will terminate on December 31, 2026." After that date, Kentico disclaims liability for "any direct, indirect, incidental, special, consequential, or punitive damages."

This is unusually explicit. Many vendors leave the liability language vague; Kentico spells out that you own every consequence once the date passes. If a zero-day vulnerability is discovered in the Xperience 13 codebase on January 2, 2027, no patch will be issued.

What stops on January 1, 2027:

• Security hotfixes. Vulnerabilities discovered in 2027 remain permanently unpatched in KX13.
• Bug fixes and updates. Defects in the CMS or admin interface stay as-is.
• Vendor support. Kentico no longer provides technical support for Xperience 13.
• Vendor liability. You assume full liability for any claims, damages, losses, costs, or expenses, including those arising from security incidents.

What continues: your web servers, databases, content, and front-end all keep functioning exactly as they did on December 31. The support date itself does not disable the application.

What Happens to Your Site After December 31, 2026?

This is the question most planning guides skip. Operationally, nothing changes on January 1. Your DNS still resolves, your database still serves content, your editors can still publish pages. The application does not crash or degrade on a schedule.

What changes is the risk profile over time:

• Vulnerability accumulation. Every CVE published against the .NET runtime or Kentico's own codebase after December 31, 2026, has no corresponding patch. The longer you run, the larger the unpatched attack surface grows.
• Dependency drift. Third-party integrations — payment gateways, marketing automation, identity providers — update their APIs and SDKs. An unsupported CMS cannot receive compatibility updates. Integrations break silently or require custom workarounds.
• Hosting environment pressure. Cloud providers and managed hosting vendors regularly retire operating system images and runtime environments. A site running on an unsupported .NET version and unsupported CMS becomes progressively harder to host on modern infrastructure.
• Talent cost. Developers familiar with KX13's specific architecture — K# macros, the Portal Engine remnants, the CMS_Tree/CMS_Document schema — become scarcer as the platform ages. Emergency support costs rise.

The risk is not a cliff on January 1. It is a slow, compounding accumulation of exposure with no release valve.

Known Security Incidents on Unsupported Kentico Instances

The risk of running unsupported Kentico software is not theoretical. Kentico and security researchers have documented real compromises against older, unsupported versions.

Kentico's security advisories and external incident reports have linked compromised instances — specifically running versions 8 through 11 — to malware injection, advertisement hijacking, and persistent backdoor access. The attack vector in documented cases was typically an unpatched vulnerability in the CMS core or a bundled component, exploited after the vendor stopped issuing fixes.

For current, version-specific CVEs, consult:

• Kentico's official security advisories
• The NIST NVD entry for Kentico (CPE search)
• CVEdetails.com — Kentico

The pattern in documented cases is consistent: known vulnerabilities in unsupported versions, no available patch, and attacker access achieved through the unpatched surface. Organizations on KX12, KX11, or earlier are not approaching a deadline — they have already passed it and should treat their current posture as active exposure.

Every Earlier Kentico Version Is Already Out of Support

Version 13.x is the last supported Kentico product version. Every prior release lost support years ago:

Source: Kentico Product Support Lifecycle Policy

Does .NET Support End Before Kentico Does?

Yes. The .NET runtime underneath Kentico Xperience 13 goes unsupported 51 days before Kentico itself does.

.NET 8 (LTS) and .NET 9 (STS) both reach end of support on November 10, 2026. After that date, Microsoft no longer provides servicing updates, security fixes, or technical support for these versions. (dotnet.microsoft.com)

Kentico's Xperience 13 release notes acknowledge this directly: ".NET 8 and .NET 9 reach Microsoft's planned end of support on November 10, 2026. To continue receiving security updates for your ASP.NET Core projects, migrate to .NET 10, which is supported since Refresh 14." (docs.kentico.com)

Here is where Xperience 13's .NET support currently stands:

• .NET 6: Already discontinued in KX13. Projects that update to the latest Refresh must target .NET 8 through .NET 10. You cannot roll back to an older LTS release to buy time.
• .NET 8 / .NET 9: Both reach end of support on November 10, 2026.
• .NET 10: Supported since KX13 Refresh 14, released December 4, 2025. .NET 10 is an LTS release covered through November 2028.

Because Kentico Xperience 13 is built on top of .NET, Kentico "cannot provide support for a version of the framework Microsoft no longer supports." If your KX13 project still targets .NET 8 or .NET 9, you lose runtime security patches seven weeks before Kentico's own support window closes.

What Actually Breaks When You Upgrade to .NET 10

Moving from .NET 8 or .NET 9 to .NET 10 inside a KX13 project is not a one-line change with no consequences. The <TargetFramework>net10.0</TargetFramework> update is the starting point, but the following work is typically required:

• NuGet package compatibility. Packages targeting net8.0 or net9.0 may not have net10.0 targets. Transitive dependencies require auditing with dotnet list package --outdated and dotnet list package --vulnerable.
• Breaking changes in ASP.NET Core 10. Microsoft publishes a .NET 10 breaking changes list covering runtime, ASP.NET Core, and EF Core changes. Review especially: nullable reference type enforcement changes, HTTP/3 behavior shifts, and Blazor component lifecycle modifications if applicable.
• Kentico NuGet package versions. All Kentico.* NuGet packages must be updated to Refresh 14 versions simultaneously with the framework change. Mixing Refresh 13 Kentico packages with a net10.0 target framework will produce runtime errors.
• Compatibility shims. Microsoft.AspNetCore.SystemWebAdapters is available for projects migrating from System.Web dependencies, but KX13 projects on ASP.NET Core should not have residual System.Web dependencies. If they do, that is a separate remediation task.
• Testing burden. Expect regression testing of custom modules, Page Builder widgets, and any code that touches Kentico's internal APIs directly. Kentico's internal APIs are not guaranteed stable across major framework versions even within the same product Refresh.

The actual .NET 10 upgrade should be treated as a minor but real engineering task — estimated at 1–3 days for a straightforward ASP.NET Core KX13 project, longer if the codebase has accumulated compatibility debt.

One nuance that gets missed: if your live site is ASP.NET MVC 5 on .NET Framework rather than ASP.NET Core, the November 10 .NET 8/.NET 9 deadline is not the right runtime clock for that code path. .NET Framework 4.8 has a different lifecycle (currently supported through Windows OS lifecycle). The Kentico product deadline of December 31 still applies regardless.

Migration Path Comparison: Xperience by Kentico vs. Alternatives

When KX13 support ends, organizations face three general paths. The right choice depends on content complexity, team capability, integration footprint, and budget — not on which platform has the best marketing. The following comparison is based on publicly available data from each vendor's documentation and licensing pages.

Decision factors not captured in the table:

• If your team is PHP-capable but not .NET-capable (or vice versa), the talent cost of the platform choice outweighs most other factors.
• Contentful's API rate limits (25,000 API calls/month on free; custom on enterprise) affect high-traffic or high-edit-frequency sites more than Xperience by Kentico's model.
• WordPress's plugin ecosystem introduces its own dependency surface — roughly 50,000+ plugins with variable maintenance quality — which creates a different (not necessarily smaller) long-term security management burden than running a supported .NET CMS.
• Optimizely (formerly Episerver) is another .NET-native option for organizations preferring to stay in the .NET ecosystem without returning to Kentico, though licensing and implementation cost are typically higher than XbK for comparable feature sets.

Xperience by Kentico: A Rebuild, Not an Upgrade

Xperience by Kentico is Kentico's current platform — a ground-up rebuild on modern, cloud-native architecture. It is not an in-place version upgrade.

Because this is a platform rebuild, moving to Xperience by Kentico — or to alternative platforms — means rewriting application code, redesigning content models, and migrating data. The work breaks into four streams:

1. Data transfer. Kentico provides an open-source Migration Toolkit that transfers content and other data from Kentico Xperience 13, Kentico 12, or Kentico 11 to Xperience by Kentico. It migrates data models and content only — code migration is not supported. (docs.kentico.com)
2. Code and architecture adaptation. Custom code, customizations, and unsupported content need manual transfer and adjustment. If your live site runs on ASP.NET MVC 5, Kentico advises modernizing to ASP.NET Core before using the Migration Tool. (docs.kentico.com)
3. Widget and editor edge cases. Custom widget properties are not automatically migrated; only built-in editing components are supported by the widget migration path. Email Builder follows a different architecture than Page Builder. (docs.kentico.com)
4. Testing and cutover. Kentico's practical guide recommends a staging environment, redirect and broken-link QA, a content freeze during migration, and a soft-launch pattern where the new application comes up while the old site stays live for a short overlap. (kentico.com)

Migration Toolkit prerequisites: The source must be a Kentico Xperience 13 instance with Refresh 5 (hotfix 13.0.64) or newer. The development model (Core or MVC 5) does not affect the data migration.

Not all legacy data transfers 1:1. The Migration Tool cannot move every older Kentico data type exactly as-is; some items map to alternatives and some are discarded, depending on the source feature and the target model. Kentico's own hands-on walkthrough describes itself as the "minimal-effort path" and notes it does not cover the complete migration of all pages and features. (docs.kentico.com)

One published data point: Kentico's own corporate website migrated in roughly 60 hours using the Toolkit versus roughly 300 hours to rebuild — an 80% effort reduction. That is Kentico's figure for their own site, not a universal estimate. Site complexity, custom module count, and content volume all affect actual effort. Kentico publishes no universal timeline for migration.

Feature Parity: What KX13 Has That Xperience by Kentico Does Not (Yet)

A common planning mistake is assuming feature parity because both products carry the Kentico name. They do not have full parity. As of early 2026, notable gaps include:

• E-commerce / Kentico Kontent Commerce: KX13 had a built-in e-commerce module. Xperience by Kentico does not include native commerce functionality; Kentico recommends composable integrations with Shopify or similar. Organizations with KX13 e-commerce implementations face the most significant replatforming scope.
• Online Marketing / Contact Management: KX13 included Marketing Automation, Contact Groups, and Lead Scoring built into the CMS. Xperience by Kentico approaches this composably — these capabilities are expected to be handled via integrated marketing platforms rather than natively.
• Custom Tables: KX13 Custom Tables (structured database tables managed through the CMS admin) do not have a direct equivalent in Xperience by Kentico. Data stored in Custom Tables must be migrated to a separate data store or rebuilt as content items.
• Polls, Forums, and Community Features: KX13 included community modules (forums, boards, polls). These are not present in Xperience by Kentico and require third-party replacement or custom development.

Check Kentico's current Xperience by Kentico feature roadmap for the latest status on planned additions.

Technical Constraints of Extracting Kentico 13 Data

Whether you are moving to Xperience by Kentico or a different platform, extracting data from Kentico 13 means navigating a heavily normalized, legacy relational database. You cannot export a single table and have a working site on the other side.

The CMS_Tree and CMS_Document Split

Kentico splits page data across multiple tables. CMS_Tree handles hierarchical structure, routing, and node relationships. CMS_Document handles culture-specific content, metadata, and workflow states. Custom page types add their own specialized tables (e.g., CONTENT_Article or CONTENT_Product).

To extract a single usable page, your migration script must perform complex SQL joins across these tables or use the Kentico REST API, which has its own rate limits and payload constraints. Failing to map NodeAliasPath correctly will break URL structures and cause SEO loss. A minimal working query joining these tables for a single page type looks like:

SELECT
  t.NodeAliasPath,
  t.NodeGUID,
  d.DocumentName,
  d.DocumentCulture,
  d.DocumentModifiedWhen,
  a.ArticleTitle,
  a.ArticleText
FROM CMS_Tree t
INNER JOIN CMS_Document d ON d.DocumentNodeID = t.NodeID
INNER JOIN CONTENT_Article a ON a.ArticleID = d.DocumentForeignKeyValue
WHERE t.NodeClassID = (SELECT ClassID FROM CMS_Class WHERE ClassName = 'CMS.Article')
  AND d.DocumentCulture = 'en-US'

For multi-lingual sites, every culture variant requires a separate document row in CMS_Document, linked to the same CMS_Tree node. Missing this relationship produces duplicate or missing content in the target system.

K# Macros and Inline Widgets

Kentico 13 uses K# macros (e.g., {% CurrentUser.UserName %}) embedded directly in rich text fields. When content moves to a new CMS, these macros become dead text rendered as raw code on the front end.

Every rich text field must be parsed during migration. Macros must be stripped, translated into the target platform's equivalent syntax, or replaced with static values. Inline MVC widgets embedded in content areas must be mapped to block-editor equivalents in the target platform.

Common K# macro patterns that require handling during migration:

Attachments and Media Libraries

Media in Kentico is stored two ways: as direct page attachments (CMS_Attachment) or as centralized files in the Media Library (Media_File).

A standard CSV export gives you database references, not actual binary files. Your migration pipeline must download the physical files from the Kentico server or Azure Blob Storage, upload them to the target system, generate new media IDs, and rewrite all relative URLs (like /getattachment/...) inside HTML fields to point to the new paths. For a deeper look at this problem, see our guide on migrating images, attachments, and embeds without broken links.

Compliance Risks of Running Unsupported

Running Kentico Xperience 13 past December 31, 2026, creates specific, auditable compliance exposure. "Unsupported software" is not a general concern — it maps to named controls in the frameworks most enterprise organizations operate under.

SOC 2 (Trust Services Criteria CC6.8 and CC7.1): CC6.8 requires organizations to implement controls to prevent or detect unauthorized access through software components that are no longer supported by vendors. CC7.1 requires that the organization monitors for vulnerabilities in system components and applies patches within a defined SLA. Running KX13 post-EOL creates a direct finding against both controls in a SOC 2 Type II audit.

ISO 27001 (Annex A Control A.12.6.1 — Management of Technical Vulnerabilities): This control requires that "information about technical vulnerabilities of information systems being used shall be obtained in a timely fashion, the organization's exposure to such vulnerabilities evaluated and appropriate measures taken." Continuing to run software for which the vendor has ceased issuing patches is a documented failure mode for this control.

PCI DSS v4.0 (Requirement 6.3.3): All system components must be protected from known vulnerabilities by installing applicable security patches/updates. Requirement 6.3.3 specifically requires that critical patches are installed within one month of release. When no patches are released because the vendor has ended support, the system cannot be brought into compliance with this requirement — the system itself is the finding.

HIPAA (45 CFR § 164.308(a)(5)(ii)(B) — Protection from Malicious Software): Covered entities and business associates must implement procedures for guarding against, detecting, and reporting malicious software. Running a CMS with unpatched vulnerabilities is a recognized risk factor in HHS breach investigations.

Because Kentico explicitly terminates all liability on the end-of-support date, the financial and legal fallout of a breach falls entirely on your organization. Cyber insurance carriers are also increasingly treating unsupported software as a coverage exclusion or premium escalation trigger — review your policy language specifically around "vendor-unsupported software" and "end-of-life components."

How Long Does a Kentico 13 Migration Take?

Two separate clocks run when moving off KX13, and confusing them is where planning breaks down:

1. The replatform project — rebuilding the application on Xperience by Kentico or another CMS. This includes discovery, content modeling, front-end development, integration rewiring, QA, and cutover. Kentico itself declines to size this work, stating in its upgrade FAQ that it is "not possible to provide a universal estimate for timeline or costs". Our estimate, based on comparable replatforms rather than on Kentico data, is that a moderately complex site (50–200 page templates, 3–8 integrations) runs to 6 to 12 months, and that large-scale implementations with e-commerce, marketing automation, or extensive custom modules run longer still. Treat any figure here as a planning starting point, not a quote.

2. The data migration — moving structured content, media assets, taxonomy, users, and records from the KX13 database to the target platform's data model. This is a defined, bounded task that can be scoped and executed independently.

Factors that drive data migration timeline (in order of impact):

• Content volume. Total number of documents, media files, and custom table records determines raw transfer time.
• Target API rate limits. SaaS CMSs enforce API rate limits that cap how quickly records can be created. Contentful's content management API limits writes per second; Xperience by Kentico's limits depend on environment tier.
• Content model complexity. Sites with 20+ custom page types, complex relationships, or deeply nested widget zones require more mapping logic than sites with 3–5 simple page types.
• Data quality. Kentico databases accumulate orphaned records, duplicate media files, and draft content over years of operation. Pre-migration data cleanup directly reduces migration time.
• K# macro density. Rich text fields with heavy macro usage require parsing and transformation passes that add time proportional to field count.
• Multi-language. Each additional culture multiplies CMS_Document rows and validation complexity.

Timeline estimates are site-specific. Any vendor quoting a universal timeline without reviewing your actual database schema, content volume, and custom module inventory is quoting without adequate information.

Compliance with Migration Planning: The Minimum Required Checklist

Here is a practical pre-migration checklist:

1. Confirm your exact stack. Document your hotfix or Refresh level, whether the live site is MVC 5 or ASP.NET Core, the current target framework (.NET 6/8/9/10), major integrations, and which features depend on Page Builder, Email Builder, custom modules, commerce, or community features.
2. Decide whether .NET 10 is a bridge. For ASP.NET Core sites, .NET 10 extends Microsoft runtime support through November 2028, but it does not move Kentico's product deadline. Evaluate whether the engineering effort of upgrading to .NET 10 inside KX13 is better spent beginning the replatform.
3. Audit what will not migrate 1:1. Flag custom widget properties, custom editing components, unsupported content types, K# macros in rich text fields, Custom Tables, commerce data, and integrations that need manual handling outside the Migration Toolkit.
4. Map your compliance exposure. If you operate under SOC 2, ISO 27001, PCI DSS, or HIPAA, identify the specific controls affected by running unsupported software (see above). Get a risk acceptance or remediation commitment in writing from your security and legal teams.
5. Review your cyber insurance policy. Check for language around "end-of-life software," "unsupported components," or "vendor-unsupported systems." Some policies require disclosure of known end-of-support dates; failure to disclose can affect coverage after a breach.
6. Rehearse content and asset migration early. Validate media, attachments, redirects, SEO-critical URLs, and Page Builder rendering in a staging environment before you pick a cutover date.
7. Scope the data workstream separately from the replatform. Treat data migration as its own project with separate validation, ownership, and timeline. Starting this workstream at least 3–4 months before your internal go-live deadline ensures runtime work, content QA, redirect testing, procurement, and stakeholder approval do not all collapse into the same quarter.

When Should You Start Planning?

The calendar is working against you in two directions:

• November 10, 2026: .NET 8 and .NET 9 lose security patches. If your KX13 project is not on .NET 10, your runtime is unsupported seven weeks before the CMS is.
• December 31, 2026: KX13 support ends completely. Full liability transfer.
• Q3–Q4 2026 will be capacity-constrained for experienced Kentico implementation partners. The majority of KX13 customers—along with users of several other platforms tracked in our CMS & DXP End-of-Support Calendar—are facing the same deadline simultaneously. Accelerated implementations typically cost more and carry higher delivery risk.

A reasonable planning horizon: if your go-live target is before December 31, 2026, your replatform project should have started already or be starting now. If your organization needs to run KX13 into 2027 with a migration in progress, document the risk acceptance, ensure .NET 10 is in place, and establish a monitoring posture for the unsupported CMS layer.

For context on the broader .NET ecosystem deadlines converging this year, see our Microsoft 2026 End-of-Support Timeline.