Kentico to WordPress: Moving Off the .NET Stack Without Losing the Content Tree

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

I have a soft spot for the .NET CMS world, because I once lived in it. When enterprise clients in my region would not touch open source — “anyone can see the code” was treated as a weakness back then — we built our own content management system on Microsoft’s ASPX stack. So when a team tells me they are on Kentico and thinking about WordPress, I do not need the architecture explained to me. I have built the thing they are standing on.

Kentico — these days Kentico Xperience — is a capable .NET DXP. Content stored in a hierarchical tree, strongly-typed page types, a media library, workflow, personalization, all sitting on SQL Server. It is serious software for serious sites. It is also expensive to license, expensive to staff, and tied to a .NET hosting reality that a lot of content teams no longer want to carry.

This is how I think about moving off it. Plain terms first, then the technical detail near the end.

Why teams leave Kentico for WordPress

The reasons follow a familiar shape:

• Licensing and total cost. Kentico’s licensing, plus .NET developers, plus Windows/SQL Server hosting, is a heavy annual bill for what is often, honestly, a content website. WordPress collapses most of that cost.
• Developer dependency. In Kentico, page types and templates are developer territory. Editors who want a new field or a new section file a request and wait. WordPress with ACF and blocks hands a lot of that back.
• The hiring pool. Kentico specialists are a narrow market. WordPress talent is everywhere. When a key developer leaves a Kentico shop, replacing them is a real project.
• Ecosystem gravity. WooCommerce, SEO plugins, forms, and a plugin economy with a stake in keeping the platform alive — versus a single vendor whose roadmap you do not control.

What I learned building the same kind of system

The CMS we built on ASPX came out well. Fast. Dozens of agencies used it, and we never charged for it because the goal was solving the problem, not the money. And then it got away from us, because it had no backward compatibility — every version forgot the past, and every release meant someone knocking on our door needing their data migrated by hand. We could not carry it, and we walked away.

I bring this up because it taught me what actually makes enterprise CMS platforms heavy, and it is not the features. It is that a system nobody in your building can change without a certified specialist is not an asset — it is a dependency wearing the costume of an asset. This was the disease that killed the great ECM platforms of the 2000s — Vignette, Interwoven, FatWire, Stellent — every one of them acquired, absorbed, and quietly retired, not because the software failed but because complexity was mistaken for capability. Kentico is far lighter than those were, but the same question applies: how much of what you pay for do you actually use, and how much is weight? Answer that honestly before you migrate, because the answer tells you what to leave behind.

How I plan a Kentico migration

1. Inventory the model — every page type, field, custom table, the content tree structure, media library, and the multilingual cultures.
2. Prune the page types and fields that exist for reasons nobody remembers.
3. Map to WordPress — page types to custom post types, fields to ACF, the content tree to WordPress’s parent/child page hierarchy, custom tables to CPTs or custom tables, media to the media library.
4. Build the empty target and validate it with the editors.
5. Transform against a database snapshot, dry-run on staging, repeat.
6. Redirects before cutover — Kentico’s URL structure and aliases become your redirect map.
7. Cut over, then watch.

The Technical Part: Where a Kentico Migration Actually Breaks

The specifics that decide the outcome. This is the section for whoever does the work.

The content tree is the heart of it

Kentico organises content as a hierarchical tree — every page has a position, a parent, and an alias path derived from the tree. WordPress does not think this way; its pages have parent/child relationships, but posts and custom post types are essentially flat with taxonomy. Preserving the tree is the central modelling decision. Pages with meaningful hierarchy map to WordPress hierarchical page/CPT structures; content that is really a flat collection (news, articles, products) should be flattened into posts with taxonomy rather than forced into a tree. Decide, per section, which it is. And preserve the alias path of every node, because that path is your redirect map — losing it means losing years of SEO.

The data lives in SQL Server

Kentico stores content in SQL Server, and the cleanest extraction is usually a direct, read-only query against a database snapshot — or Kentico’s REST service / content staging API if you have it enabled. Page-type data is spread across the tree tables and the type-specific data tables; you have to join them to reconstruct a full page. Whatever route you choose, snapshot to a file and transform against the frozen copy so your runs are repeatable and safe to fail. Do not transform against live production.

Page types and fields map well — web parts and widgets do not

Kentico page types map naturally to custom post types and their fields to ACF. The trap is web parts, widgets, and the portal-engine layout (or MVC view components in newer builds). These are presentation and logic, not content — they do not migrate. Every dynamic region, every listing web part, every personalised widget has to be rebuilt as a WordPress block, query, or template. Inventory them early; they are invisible in a data export and easy to forget until a section of the site comes out empty.

Multilingual cultures

Kentico handles languages as cultures, with content variants per culture code. Before migrating, choose the WordPress model — multisite, Polylang, or WPML — because the transform that maps Kentico’s culture variants into your chosen structure depends entirely on that choice. Watch for pages that exist in some cultures but not others; the transform has to handle partial translations without creating orphan pages.

Media library and content-embedded links

Kentico’s media library and page attachments both hold files, and both need downloading and re-importing into the WordPress media library. The part that bites: rich-text fields contain absolute links to Kentico media paths (/getmedia/..., attachment GUIDs). Every one has to be rewritten to the new WordPress attachment URL, or your migrated pages keep loading images from a Kentico instance you are about to decommission.

Workflow, personalization, and forms

Kentico bundles workflow states, personalization rules, and an on-platform forms module. None of it migrates as content. Workflow becomes WordPress’s post statuses plus an editorial-workflow plugin if you need it; personalization becomes a WordPress personalization plugin or is dropped (be honest about how many segments were actually in use — in my experience it is far fewer than were built); forms become Gravity Forms, Fluent Forms, or similar, and every form’s submission handling and notifications must be rebuilt. Inventory these before you scope the project, because they are real work hiding outside the content.

Users and permissions

Kentico user accounts and roles do not port cleanly, and password hashes are not portable. Plan for password resets and a hand-built mapping of Kentico roles to WordPress roles.

My honest closing position

Kentico is good software, and moving off it is not an admission that you chose wrong. It is usually a recognition that the site grew into something lighter than the platform was built for — a content website carrying the cost of a full DXP. Moving to WordPress is right-sizing that: trading a licensed, specialist-dependent .NET stack for a platform your team can actually staff and your editors can actually use.

I say this as someone who built one of these systems and had to abandon it. The lesson I carry from that is simple: a CMS is only an asset for as long as ordinary people in your building can change it without calling someone. Map the tree carefully, rebuild the web parts, rewrite the media links, plan the password resets — and the content lands somewhere it can stay accurate and stay alive on your own terms, which is the whole point of moving at all.

One More Thing: But Can’t WordPress Just Do What Kentico Does?

Here’s the question I get the moment a Kentico team decides to move: if we leave the .NET stack, are we downgrading to something less serious? No. And the people who still file WordPress under “just a blog” are the ones most surprised by the answer.

WordPress is not new to this. The REST API has shipped in core since late 2016 — nearly a decade of production hardening. WPGraphQL is now backed by Automattic and on its way to canonical status as WordPress’s GraphQL layer. So if the decoupled front-end is the part of Kentico you actually liked, you keep it: WordPress runs headless too — REST or WPGraphQL — feeding whatever front-end you point it at.

But the everyday fit is even cleaner than that. Custom post types plus ACF map onto Kentico’s page types and their fields almost one-to-one, and WordPress’s parent/child hierarchy carries your content tree. Multilingual cultures become multisite, Polylang, or WPML. The model you built in Kentico moves across without being forced into a shape it resents.

And what you drop is the expensive part:

• The .NET licensing. Gone. No annual seat math, no usage meter.
• The Windows/SQL Server ops burden. Traded for hosting your team can run in its sleep.
• The certified-specialist tax. Replaced by a hiring pool that is everywhere, not a narrow one you pay a premium to keep.

On top of that you gain what a DXP never handed you cheaply: WooCommerce, a real commerce engine, and a plugin economy — SEO, forms, memberships — you consume instead of rebuild.

Kentico is good software; I said so and I meant it. But “we need a structured content tree over an API” is not a reason to stay on .NET. It’s a reason to run WordPress. You keep the model, and put a much bigger toolbox behind it.