Can You Keep Running Kentico 13 in 2027? Risks, Costs, and Interim Options

This is a decision guide, not an end-of-life alarm. KX13 won't switch off on January 1, 2027, but "it still runs" is not the same as supported, secure, or compliant. Below are the changes, the costs, what to do if you can't migrate in time, and how to set up your own site.

Will Kentico 13 stop working after support ends?

No. KX13 is a customer-hosted application, and the End of Technical Support date does not switch it off. Continued operation depends on your license model: a perpetual license permits indefinite use, while a subscription license stops after expiration and a grace period.

What ends is Kentico's obligation to keep it running. From January 1, 2027, Kentico ceases "all support, maintenance, updates, releases, hotfixes, patches, repairs (including security repairs), and any other services" for KX13, and states that continued use is "at your sole risk". An implementation partner can still diagnose or adapt custom code; what disappears is the vendor patch pipeline for the product.

That splits four things that used to travel together. A site can be running: the application still executes, regardless of vendor status. It is no longer supported: Kentico stops fixing, patching, or maintaining KX13. It cannot be assumed secure: a newly disclosed vulnerability in KX13 product code in 2027 has no vendor patch. And it is not automatically compliant: whether an unsupported system meets your obligations depends on your industry and your auditor or insurer, not on the software itself. A security review asks whether it's patched; an auditor or insurer asks whether an unsupported system meets your obligations. 

What risks increase when Kentico 13 becomes unsupported?

Risk depends on your implementation and splits into dated deadlines, slow erosion, and operational exposure. Not every site carries all three at the same intensity — a small marketing site on a stable stack may barely notice the first, while a commerce platform on shared infrastructure feels all three quickly. The point isn't that every KX13 site is in immediate danger; it's knowing which of the three applies to yours.

Dated deadlines vary depending on how the site is built:

Moreover, your database has its own clock. SQL Server 2016 extended support ended July 14, 2026; eligible customers may buy Extended Security Updates for a limited period, so "2016" does not automatically mean "unpatched." SQL Server 2017 follows on October 12, 2027, and SQL Server 2019 runs to January 2030 (Microsoft).

Slow erosion follows the longer you wait: unpatched vulnerabilities can accumulate in product code and dependencies, and engineers fluent in KX13's Web Forms admin and macro engine become harder to source.

Operational exposure is the part teams underweight. Without a vendor to escalate to, your rollback and disaster-recovery plan becomes the safety net for any failed change. Testing also has to be scaled to the change: smoke testing after certificate and infrastructure changes, targeted regression after dependency updates, and broader regression for runtime or platform changes.

"On paper, KX13 keeps running after December 2026. In our assessments, the problem is rarely the CMS itself — it's the accumulated custom code. When a portal has dozens of custom widgets and integrations wired into the CMS, every unpatched dependency becomes something you own, with no vendor fix behind it. We check the live-site runtime and the widget inventory before anyone discusses a timeline." 
— Roman Hutnyk, CEO of Bits Orchestra and a former Kentico MVP

Can infrastructure hardening make Kentico 13 safe?

No, not in the sense the question implies. Hardening reduces exposure. It does not replace product support, and the two are not equivalent.

Restricting the administration application — VPN, IP allow-list, or a private endpoint — removes a major admin-side attack surface and, for a public KX13 site, it is one of the highest-value controls. A web application firewall, rate limiting, network segmentation, and monitoring reduce known-pattern attacks and shorten detection time.

Where a vulnerability sits on a path that must stay public, such as a member login or a public form, a firewall rule may serve as a compensating control, but it is weaker than a fix. A vulnerability in an unsupported runtime, or in a dependency you can't upgrade without a vendor release, is harder still. Migration is what removes the unsupported-product condition over the long term; it is not the only response to any single vulnerability, but it is the only one that resolves the underlying status.

What drives the cost of keeping Kentico 13 running?

Cost sits in four places. Direct costs are budget line items: hosting, monitoring and firewall tooling, planned maintenance, and regression testing. Hidden costs surface through delay: the scarcity premium for KX13 specialists, staging upkeep, and incident response without a vendor path. Risk-exposure costs are carried as probability — a breach, insurance friction, business interruption. Opportunity costs are features not shipped during a freeze.

Migration cost varies by system. Bits Orchestra publishes reference ranges of roughly:

• $15,000–$40,000 for a version upgrade with limited integrations, 
• $40,000–$120,000 for content restructuring with multiple integrations and SEO work, 
• $120,000–$300,000+ for enterprise modernization (USD, scoped after a dependency audit, before taxes, Kentico licensing not included).

The lowest tier reflects a straightforward version upgrade, not a full architectural KX13-to-XbyK migration, which lands higher. Migration also does not end lifecycle management: XbyK uses subscription licensing and a rolling release-support policy.

What are your interim options if you can't migrate in 2026?

Treat each option as a temporary, conditional decision with a review date.

Two of these are commonly oversold, not because the mechanics are wrong, but in how they get pitched internally. Re-hosting is often framed as "addressing the KX13 risk," but it changes nothing about the support clock — it's infrastructure work wearing a risk-management label. A maintenance agreement is called a "safety net," but it catches incidents as they happen, not the absent vendor patch upstream. Both belong inside a bridge, not a permanent answer, and neither substitutes for a documented, time-boxed decision.

Can you migrate to Xperience by Kentico without a redesign?

Yes. Migration and redesign are separate decisions, and separating them is usually what makes the deadline reachable. XbyK is a rewritten platform on ASP.NET Core with a React-based administration. In a default migration, KX13 sites become website channels and KX13 page types become page content types; structured content moves into a website channel, and remodeling selected content into reusable Content Hub items is an optional, later decision rather than a requirement for the migrated solution to run — with one exception noted below for media assets.

What the Migration Tool carries, and what it doesn't, sets the scope:

• Content and templates: structured content, plus Page Builder content and custom page templates from KX13 (templates arrive as preset templates; Page Builder data runs in legacy compatibility mode, with optional conversion to the new format). Widget code generally needs minor adjustments (Migration Tool).
• Administration, integrations, and search: custom administration UI (rebuilt in the React model), integrations against new APIs, and search (typically reimplemented via Lucene, Azure AI Search, or Algolia). Marketing capabilities vary — some have XbyK equivalents, others need a new implementation.
• Commerce and media: the Migration Tool can transfer certain commerce data such as customers and orders, but commerce features are configured or rebuilt and the product catalog is modeled for the new solution (Kentico migration guide). Media is the exception: it's recommended to move into Content Hub assets, though the tool can migrate files as media libraries on a temporary basis. 

The tool requires a source instance on KX13 Refresh 5 (hotfix 13.0.64) or newer, and the supported object set changes between releases — confirm both at project time.

A Bits Orchestra project shows the shape of this. A building-materials manufacturer ran a KX13 dealer portal for 350+ distributors, with 12,000+ SKUs and 80+ custom widgets on a .NET Framework monolith, and needed to move without a greenfield rebuild. The team used the Migration Tool plus a custom script for non-standard content, ran three rehearsal migrations, and cut over in a single weekend with KX13 kept read-only for 48 hours as a fallback. Catalog page loads improved from roughly 3.1s to 2.0s. The redesign came later, as a separate decision.

For a step-by-step view, see how to upgrade from KX13 to Xperience by Kentico.

Phased migration vs single cutover: which is safer?

For most projects, a parallel build — developing XbyK while KX13 stays in production — is the safer default; a production-phased rollout is the riskier exception, not a synonym for "phased." The terms are often confused. A parallel build carries low coexistence risk and suits most projects. Rehearsal migrations repeat the data move in non-production before cutover. A production-phased rollout, where both platforms serve live traffic for a period, is different: it requires traffic routing, shared authentication, content ownership rules, and synchronized data, and it can increase total effort rather than lower it. For a smaller, self-contained site, a single cutover is often the lower-risk choice. 

Your 2027 decision: four paths

Rate your site on exposure, data sensitivity, customization, current runtime, and how long an interim period must last.

Every path starts from the same input — a dependency audit. Before requesting an estimate, prepare:

• KX13 Refresh and hotfix level (the Migration Tool needs Refresh 5 / 13.0.64 or newer);
• whether the live site is MVC 5 or ASP.NET Core, and current .NET, Windows Server, and SQL Server versions;
• page types and Page Builder component inventory; custom modules and administration UI;
• forms, search, commerce, marketing, and authentication;
• integrations and data ownership; content, assets, URLs, redirects, and SEO requirements.

That inventory is what separates a defensible hold from an unmanaged one, and a realistic estimate from a guess— it's also the starting point for choosing a Kentico development partner, since a vendor's ability to scope from this list, rather than a generic quote, is the fastest signal of competence. Bits Orchestra's Kentico migration services start with that dependency assessment before any implementation scope is set.