Migrating from Kentico to Payload: a 2026 guide for Kentico 13 end of life

Kentico Xperience 13 stopped getting real fixes on January 1, 2026, and has run in a security-hotfix-only phase ever since. That phase ends on December 31, 2026, and from January 1, 2027 Kentico provides no support, no patches, and no security repairs of any kind, which leaves the risk of running it entirely with you.

If you own a Kentico 13 site, that deadline is the whole story this year. You have to move, and the only real question is where to.

Kentico would like that destination to be Xperience by Kentico, its newer .NET 8 platform. That is a reasonable answer, though it is not the only one, and the usual framing hides the fact that matters most: whichever path you pick, you are rebuilding. Once that sinks in, the decision stops being a question of staying or upgrading and becomes a choice between rebuilding on a licensed .NET platform or rebuilding on a stack you own outright.

We are a React and Next.js shop, and we build on Payload CMS. We will be upfront about that bias throughout. We will also tell you where Xperience by Kentico is the smarter call, because for some teams it is. This guide lays out the real options, what a Kentico to Payload migration actually involves, what it costs, and how to decide.

Your three real options

When Kentico 13 hits end of life you have three real choices, and the third one rarely gets a fair hearing.

• The first is to stay on Kentico 13 and accept the risk. After December 31, 2026 you are running unsupported software with no security patches. For a brochure site behind a strong CDN and WAF you might tolerate that for a few months while you plan. For anything handling logins, payments, or personal data, running unpatched past the deadline is hard to defend to a security team or an auditor. This buys you a few months of breathing room while you migrate, and not much more.
• The second is to upgrade to Xperience by Kentico. This keeps you in the Kentico family and on .NET, now committed fully to .NET 8.
• The third is to rebuild on a different stack entirely. A headless CMS like Payload is the option in that category we know best.

The “just upgrade” framing skips over what the second option really costs you.

”Upgrade” is the wrong word for the Xperience by Kentico path

Moving from Kentico 13 to Xperience by Kentico is a rebuild with a migration tool attached rather than an in-place upgrade.

Xperience by Kentico is a ground-up rewrite with a different architecture underneath. Where Kentico 13 runs as a traditional all-in-one system, Xperience by Kentico is built around a centralized Content Hub, structured content items, and taxonomies, with content sync between environments. Your content models, widgets, custom modules, and legacy API integrations do not carry across untouched; they get rebuilt to fit the new model.

Kentico ships a Migration Toolkit to move data over, and it helps. But it does not transform your old content structures into the shapes the new platform recommends. There is a known gap between how Kentico now tells you to model content and what the toolkit can actually carry across automatically. The structural work lands on your team either way.

The distinction matters. If switching to Xperience by Kentico were a quick in-place update while moving to Payload meant a months-long rebuild, the comparison would be lopsided and most teams would stay. Since both are rebuilds of similar weight, the real question becomes what you want to be running, and paying for, once the work is done.

Why teams use end of life as the moment to leave

A few reasons come up again and again when teams reach this fork.

• Cost is the loudest one. Kentico Xperience 13 licensing starts around $12,500 per year for the Business tier and around $22,300 per year for Enterprise. The newer Xperience by Kentico is sold as a subscription: the self-managed license starts around $990 per month and the SaaS option starts around $1,990 per month. Stack the license on top of hosting, maintenance, and integration work and the three-year total cost of ownership commonly lands somewhere between $50,000 and $300,000 or more, depending on tier and complexity. That is a recurring line item that grows, and renewals tend to climb.
• The second reason is the .NET commitment. Xperience by Kentico goes all in on modern .NET. If your team is deep in .NET and happy there, that is a feature. If your team is JavaScript and TypeScript, or you are trying to consolidate your stack around one language across front end and back end, staying on .NET means staffing and maintaining a runtime you would rather not.
• The third reason is simpler. Since you are rebuilding regardless, the switching cost that normally locks people in is already on the table. Teams that have wanted off a heavyweight licensed platform for years treat the end-of-life moment as the cheapest chance they will get to leave.

What Payload actually is

Payload is an open-source CMS and application framework built on Next.js and TypeScript. A few of its properties matter directly to a team leaving Kentico.

The most immediate difference is the license. Payload is released under MIT and free to self-host, with no per-seat or per-year platform fee, so you pay for your own infrastructure and nothing beyond it. For a team coming off a five-figure annual Kentico license, that line on the budget goes to zero.

The second difference is how you model content. In Payload your collections, fields, and access control are written in TypeScript, in your repository, under version control, with no separate admin database schema to reconcile against your code. The shape of your content is the code itself, which means it reviews, diffs, and deploys like everything else in the application.

Then there is where it runs. Since version 3.0, released in November 2024, Payload installs directly into a Next.js app, so your CMS and your front end live in a single project and ship in one deploy. Payload also gives you a Local API, which lets server-side code query the database directly with no HTTP round trip. For a content site, that removes a whole category of latency and glue code you would otherwise maintain between a headless backend and a separate frontend.

Stability is worth a look too, since you are leaving a commercial vendor for an open-source project. Payload was acquired by Figma in June 2025 and remains open source and actively developed. If the worry is whether the project will still be around in a few years, it now has a large, well-funded company behind it and an MIT license that guarantees you keep the code regardless.

Kentico 13 vs Xperience by Kentico vs Payload

	Kentico Xperience 13	Xperience by Kentico	Payload
License model	Annual license (~$12.5K to $22.3K/yr)	Subscription (from ~$990 to $1,990/mo)	Free, MIT open source
Hosting	Self-hosted	Self-managed or Kentico SaaS	Self-hosted (any Node host)
Core stack	.NET (Framework 4.8 / Core)	.NET 8	Next.js, TypeScript
Headless	Add-on capability	Built-in option	Native, API-first
Content modeling	Page types / all-in-one	Content Hub, content items	Collections defined in code
Front end	Razor / MVC	Razor / MVC	Next.js (React)
Lock-in	License + .NET	License + .NET	You own the code
Support deadline	Dec 31, 2026	Active	Active

The table opens a conversation rather than settling it. The row that matters most for the long run is lock-in, because the license and the runtime stay with you for as long as you run the site.

How a Kentico to Payload migration works

The work breaks into five stages for the developers who will run it. None of them are exotic, and the first one decides how hard the rest will be.

Audit the Kentico instance first

Before any data moves, map what you actually have. The single biggest variable is whether your Kentico 13 site is built on Portal Engine or on the MVC model. Portal Engine sites keep a lot of logic and layout inside the CMS itself through web parts and portal templates, which means more to untangle and reproduce. MVC sites already separate the front end into a .NET application, so the content layer is cleaner to lift out.

Inventory the rest in the same pass: every custom module, every page type and field, every third-party integration, every scheduled task, and the media library. This audit is where you find the surprises, and finding them now is far cheaper than finding them during cutover.

Map content models to Payload collections

In Kentico your content lives in page types and custom module classes. In Payload it lives in collections, each defined as a TypeScript config with typed fields, relationships, and access rules.

The mapping is rarely one to one, and that is the opportunity. End of life is a good moment to fix the content model you have always meant to fix, so a bloated Kentico page type with forty fields, half of them unused, becomes a lean Payload collection plus a couple of relationship fields. Rather than copying the old structure verbatim, model the content the way the site actually uses it now.

A Kentico “Article” page type, for example, becomes a Payload collection that looks like this:

import type { CollectionConfig } from 'payload'

export const Articles: CollectionConfig = {
  slug: 'articles',
  admin: { useAsTitle: 'title' },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    { name: 'body', type: 'richText' },
    { name: 'author', type: 'relationship', relationTo: 'authors' },
    { name: 'publishedAt', type: 'date' },
  ],
}

That config is the whole schema. It generates the database tables, the admin UI, and fully typed API responses, and it lives in your repository where it reviews and deploys with the rest of the code.

Migrate content and media

With the target collections defined, write a migration script that reads from Kentico and writes through Payload’s Local API. The core loop is short:

import payload from 'payload'

for (const row of kenticoArticles) {
  await payload.create({
    collection: 'articles',
    data: {
      title: row.DocumentName,
      slug: row.NodeAlias,
      body: convertRichText(row.ArticleText),
      publishedAt: row.DocumentPublishFrom,
    },
  })
}

You pull records from the Kentico database or its REST and GraphQL endpoints, transform each one into the new shape, and create it in Payload in code. Media files move to your chosen storage adapter, whether that is S3, Vercel Blob, or another provider, and the script rewrites references as it goes.

Because the import runs through Payload’s own API rather than raw SQL, you get validation and hooks for free, so malformed legacy data surfaces during the migration instead of after launch.

Rebuild the front end in Next.js

If you are on Payload you are on Next.js, so the front end is a React application that reads content through the Local API. Razor views and portal templates do not port over; they get rebuilt as React components. For teams already working in React this is familiar ground, and it is usually the largest single chunk of the project. For a marketing site with a well-defined set of page templates it is also predictable work, which makes it easy to estimate.

Redirects, SEO, and QA

The migration is not done when the content lands. Map every old Kentico URL to its new path and put 301 redirects in place so you keep the search equity you have built. Carry over metadata, canonical tags, sitemaps, and structured data. Then test against the old site page by page: content parity, redirects, forms, integrations, and Core Web Vitals. This stage protects the traffic that justifies the whole project, so budget real time for it instead of squeezing it into the final day.

How long it takes and what it costs

Migration timelines track complexity more than platform. As a rough guide drawn from how these projects actually run, a small or mid-size site lands in the three-to-six-month range, and a large, heavily customized build runs six to twelve months. A Portal Engine site with many custom modules sits at the higher end. A cleaner MVC site with a tidy content model comes in lower.

The cost shape is where Payload changes the math. The migration is a one-time project cost on either path. The Xperience by Kentico route has a Kentico-built Migration Toolkit to move data, which the Payload route does not, so you write the import script yourself. Set against that, the Payload route skips relearning a new .NET platform and runs your CMS and front end as one Next.js codebase, which usually nets out to comparable engineering effort for a content-led site. The real divergence shows up after launch. With Xperience by Kentico you keep paying the annual or monthly license on top of hosting. With Payload the license cost is zero and you pay only for infrastructure: your database, your file storage, and your Node hosting. Over a three-year horizon, removing a five-figure recurring license changes the total meaningfully, and that saving compounds every year you run the site.

Start planning early. Most teams want twelve to eighteen months of runway ahead of an end-of-life date to handle discovery, the platform decision, the content migration, and SEO preservation without rushing the cutover. If you are reading this in 2026, that runway is already short, which is an argument for deciding soon rather than for picking any particular platform.

One cost that is easy to forget sits with your content team, not your engineers. Editors who know the Kentico admin have to learn a new one. Payload’s admin panel is clean and configurable, but the move is still a change for the people publishing every day, so factor in training and a short dip in editing speed right after launch.

We have run this kind of forced migration before. When Oracle Content Manager was being discontinued, Ingersoll Rand needed a new authoring system for its China sites on a fixed deadline, much like Kentico 13 owners do now. We rebuilt it on Payload in five months, migrating thousands of pages along with tens of thousands of media assets and redirects across more than 20 brand tenants, and shipped before the cut-off without disrupting the live platform. The trigger there was a vendor pulling the plug on a platform, which is the same position Kentico 13’s end of life puts you in. You can read the full Ingersoll Rand case study for the detail.

When you should stay on Xperience by Kentico

Payload is not the right answer for everyone, and pretending otherwise would not help you. Three situations point the other way.

• The first is team fit. If your engineers are most productive in C# and Razor, and hiring against that stack is easy for you, moving to a TypeScript platform trades a comfortable team for a saving they may not value.
• The second is your reliance on Kentico’s built-in digital experience features. Xperience by Kentico bundles marketing tooling, personalization, and campaign features into the platform. Payload is a content and application backend; equivalent capabilities come from your own choices and integrations rather than from the box. If your marketing team runs on those native Kentico features day to day, replacing them is real scope you need to count.
• The third is hosting. If you want a vendor-managed SaaS where someone else owns scaling and uptime, Kentico’s SaaS option exists for that. Payload’s self-hosted model gives you control and removes the license, and the price of that control is that operating the infrastructure becomes your job.

So the choice comes down to what you want to own. If an all-in-one .NET marketing platform with a license attached suits you, Xperience by Kentico is a reasonable home. If you would rather own your stack, write your content model in code, run your CMS and front end as one Next.js app, and stop paying a yearly license, that is the case for Payload, and it is the work we do.

Where WAYF fits

WAYF is an official Payload partner and Top Contributor, and we have built content platforms on Payload and Next.js for Fortune 500 companies, public institutions, and high-growth teams. Migrating off legacy and discontinued systems is a core part of what we do, including moves off Oracle Content Manager, WordPress VIP, and Wagtail. Kentico end of life is forcing the same rebuild decision on a lot of teams this year, and we help them make the call and then do the migration: the audit, the content model, the data move, the Next.js front end, and the SEO-safe cutover.

If you are weighing Xperience by Kentico against a move to Payload, we will look at your actual Kentico instance and tell you which path fits, including when staying on Kentico is the right call.

Book a call and we will tell you if Payload is the right move for your site.

FAQ

1. When does Kentico Xperience 13 reach end of life?

   Kentico Xperience 13 entered a security-hotfix-only phase on January 1, 2026. Full end of support is December 31, 2026. From January 1, 2027, Kentico provides no support, updates, hotfixes, or security repairs, and all risk of running the software is yours.

2. Is upgrading to Xperience by Kentico an upgrade or a rebuild?

   It is effectively a rebuild. Xperience by Kentico is a ground-up rewrite on .NET 8 with a new content architecture. Kentico provides a Migration Toolkit to move data, but content models, widgets, custom modules, and integrations are rebuilt to fit the new platform.

3. Can you migrate from Kentico to a headless CMS like Payload?

   Yes. You map Kentico page types and modules to Payload collections defined in TypeScript, write a migration script that imports content and media through Payload's API, rebuild the front end in Next.js, and put 301 redirects in place to preserve SEO.

4. How long does a Kentico to Payload migration take?

   As a general guide, small and mid-size sites take three to six months and large, heavily customized sites take six to twelve. Those are industry rule-of-thumb ranges, and an experienced team often moves faster: WAYF migrated Ingersoll Rand's 20+ tenant, multi-thousand-page platform to Payload in five months. Sites built on Kentico's Portal Engine with many custom modules sit at the higher end.

5. Is Payload CMS free?

   Payload is open source under the MIT license and free to self-host. You pay only for your own infrastructure, such as database, file storage, and Node hosting. There is no per-year platform license fee.

6. How much does Kentico licensing cost?

   Kentico Xperience 13 starts around $12,500 per year for Business and around $22,300 per year for Enterprise. Xperience by Kentico is sold as a subscription starting around $990 per month for the self-managed license and around $1,990 per month for SaaS, before hosting and maintenance.

7. What happens if I stay on Kentico 13 after 2026?

   After December 31, 2026 you are running unsupported software with no security patches. For sites handling logins, payments, or personal data, that is difficult to justify to a security team or auditor. It works as a short bridge while you migrate and should not be where you settle.

Sources

• Kentico Product Support Lifecycle
• Cantarus Kentico Xperience 13 End of Life Guide
• Bits Orchestra migration guide
• Kentico Migration Toolkit docs
• TrustRadius Kentico pricing
• PricingNow Kentico TCO
• Kentico licensing
• Payload GitHub
• Payload
• Figma: Welcoming Payload