Kentico Xperience 13 entered security-only support in January 2026, with full end-of-life coming on December 31, 2026. Since moving to Xperience by Kentico is a full replatform regardless, many teams are using the moment to evaluate WordPress instead. It gives you an infrastructure your organisation owns outright, without a vendor licensing tier and a mandatory upgrade cycle.
rtCamp has completed 300+ enterprise migrations to WordPress, including VinSolutions (Kentico → WordPress VIP multisite, all SEO ranks preserved) and Cox Automotive (AEM + Kentico → unified WordPress across 8 brands, with 2X Core Web Vitals improvement). We are a WordPress VIP Gold Agency Partner, SOC 2 compliant, and ISO 27001 certified.
Further, we cover every phase of an enterprise Kentico to WordPress migration, from the upgrade-vs-migrate decision through to post-launch training.
TL;DR
- Kentico Xperience 13 has been in security-only support since January 2026, with full end-of-life on December 31, 2026. Teams still on Portal Engine are running on a framework Kentico retired at the end of 2023.
- XP13 teams are now choosing between staying past EOL without patches, replatforming onto Xperience by Kentico, or leaving Kentico for another CMS.
- Moving to Xperience by Kentico is not an upgrade in any practical sense. Kentico’s own docs frame it as a rebuild. For example, the Migration Tool leaves data types behind, the admin is redone from scratch, and every customization and integration gets reworked by hand.
- Cost stacks up across four layers at enterprise scale. Licensing runs into the tens of thousands a year, upgrade cycles carry their own development bill, integration toolkits cost $5,000–$30,000+ each, and .NET/MSSQL specialists carry a talent premium. Five-year TCO comes in at $900K–$1.8M+.
- Reasons to stay on Kentico: your organization is a committed Microsoft/.NET shop with the in-house skills to match, your content architecture leans hard on Kentico’s page type inheritance, or the move to Xperience by Kentico is already underway.
- Where migrations lose traffic is in the execution. Kentico’s .aspx extensions, document aliases, and query-string URLs need a hand-built redirect map as generic plugins miss the long tail. VinSolutions kept every SEO page rank on the way out of Kentico and picked up 48% on Core Web Vitals.
- Plan for 3–6 months end to end at enterprise scale, from discovery through post-launch support.
Why enterprises are leaving Kentico XP13
With XP13 reaching EOL, Kentico is pushing teams to upgrade to Xperience by Kentico. But even their own documentation describes it as a replatform instead of an upgrade. The Migration Tool can’t transfer all data types, the admin interface is a complete rebuild, and code, customisations, and integrations need to be manually transferred and reworked.
But what forces teams to consider migrating off Kentico besides that? The trigger is usually something specific: a security audit, a budget review, or a senior developer handing in their notice who turned out to be the only person who understood the MSSQL configuration. Any of those makes the migration conversation and 5-year TCO calculation suddenly very concrete.
TCO: How to build a business case for migration
Your steering committee needs numbers. The Platform Tax framework built by rtCamp is how you build that case.
Most enterprises use 30–40% of the functionality in a platform like Kentico while paying for the full stack. For a Kentico migration, key things that make up your TCO are:
- Your current license tier: enterprise licensing starts in the tens of thousands annually,
- Each upgrade cycle that carries considerable development cost on top,
- Integrations that run $5,000–$30,000+ per toolkit, and
- Your annual spend on .NET/MSSQL specialists.
The Platform Tax puts that figure at $900K–$1.8M+ in total cost of ownership over 5 years.
Migration to WordPress isn’t always cheaper in year one. Let’s look at where the numbers tip and how to make that business case to the people who control the budget.
Kentico vs WordPress: Comparing the two at enterprise scale
WordPress covers editorial workflow, content scheduling, multisite governance, and role-based permissions natively. The broader plugin ecosystem fills the rest, e.g., multilingual (WPML), structured content (ACF), and form building (Gravity Forms, WPForms). Some integrations built on Kentico’s proprietary ASP.NET APIs will need a custom build rather than a direct swap, so those need to be inventoried during discovery.
Kentico’s content modelling is genuinely rigorous, and its page type system gives developers real structural control. Those capabilities don’t disappear in WordPress, but they need to be architected before migration rather than mapped across automatically. It’s also worth noting that if your implementation is still on Portal Engine (phased out at the end of 2023), you’re already two years behind on a framework that Kentico itself has abandoned.
Three key differences between Kentico and WordPress are worth calling out as well.
On the editorial side: the difference is less about features and more about who needs to be in the room. Kentico requires developer involvement for changes that WordPress editors handle independently.
On hosting and infrastructure: Kentico runs on a Windows/.NET stack, which constrains your options. WordPress runs on many infrastructures, including WordPress VIP with FedRAMP and SOC 2 certification for organisations with compliance requirements.
On the upgrade cycle: Kentico’s roadmap is vendor-controlled. WordPress gives you control of your own roadmap, a global pool of engineers rather than a narrow certified specialist market, and a platform you can extend toward AI without waiting for a vendor to productise it.
CapabilityKentico XP13WordPressContent management & editorial✓ Developer required for most changes✓ Editors work independentlyContent architecture (multilingual, structured content, forms)✓✓Multisite governance✓✓Headless / API delivery✓✓Proprietary API integrations✓Custom build requiredSecurity & compliance✓✓ WordPress VIP: FedRAMP, SOC 2Hosting flexibilityWindows / .NET stackAny infrastructureUpgrade cycleVendor-controlledYou control the roadmapSupport & specialist availabilityCertified .NET specialistsGlobal developer pool
Below you can find a gap analysis: which capabilities transfer cleanly, which need rebuilding, and which the committee has been paying for without using.
Discovery phase: Map what you have before you move it
A thorough Kentico discovery covers every dimension that affects migration risk: page types, custom modules, widget zones, form definitions, workflow states, third-party integrations, and your .aspx URL structure for SEO baseline. It also sets a performance benchmark (current page speed, traffic patterns, and mobile usability) so there’s a measurable before-and-after once the new WordPress stack is live.
One thing that surprises most teams is that Kentico and WordPress don’t share a vocabulary. Pages, page types, widget zones, macros don’t map directly to WordPress equivalents. Getting that nomenclature translation documented in discovery is essential to prevent content loss and rework during migration.
What also gets answered here: retain the current layout or redesign. That decision affects both scope and timeline, and leaving it until later is one of the more common reasons enterprise migrations run over budget.
So, what should you actually do during discovery?
Define your migration goals
We’re here to audit, but let’s start with what you want to get out of the migration. And how you’ll know you got there:
Migration goal****How to measure itReduce maintenance costsCompare annual spend before and after migration.Speed up publishingTrack the time from draft to live.Retain organic trafficCompare organic sessions in Google Analytics at 30 and 90 days post-launch against the same pre-migration periods.Improve page speedCompare Core Web Vitals before and after migration.Reduce developer dependencyTrack the number of editorial support tickets raised per month.
Assign KPIs to each goal. For example, if you’re migrating partly for SEO reasons, your current search visibility is the baseline. Capture it in discovery so you can compare it after launch.
Evaluate your existing Kentico setup
Kentico currently supports two versions of their Digital Experience Platform (DXP): Kentico Xperience 13 and Xperience by Kentico.
Identify the version you’re using and create a feature matrix that compares Kentico’s capabilities with those of WordPress. This matrix should document critical functionalities that must be retained in the migration, as well as features that can be dropped or replaced to optimize your WordPress setup.
Features****Required in WordPressHeadless architecture
Multilingual supportPersonalizationE-commerce capabilitiesContact forms, Lead magnet and Newsletter formContent schedulingAnalyticsWorkflow customisationSEO featuresCookie consent managementUser roles Plugins and integrations
Add features as you go based on your Kentico setup. When you get to the migration itself, you’ll use this list to check feature/function parity.
Map your third-party integrations
List every connected application and document what it does. Each integration either maps to a WordPress equivalent, requires a custom build, or gets replaced with a better-fit tool.
Third-party integrations/ functionsKenticoWordPressAnalytics integration (Google Analytics)Google Site KitGoogle Site KitContent Delivery Network (CDN)Built-in support for CDN to improve load timesIntegrate CDN services (e.g., Cloudflare) to optimize content delivery globallySalesforce Marketing CloudOffers built-in two-way integration with Salesforce, allowing synchronization of various data types, including contacts and leadsRequires third-party plugins (e.g., WP Fusion, Zapier) for Salesforce integration, which can vary in functionality and ease of useSEO managementBuilt-inMultiple plugin options like Yoast, Rank Math, AIOSEO, etc.Forms managementBuilt-in (via Kentico’s Form Builder application)WPforms or Gravity formsMultilingual supportBuilt inAvailable via WPML (a WordPress multilingual plugin)
Any integration that relies on Kentico’s proprietary ASP.NET API won’t have a direct WordPress equivalent. Those need a custom build, and they need to be scoped in discovery.
Audit your user roles
Kentico and WordPress handle user roles differently. Document every role currently in use, including any custom ones built on top of the defaults. During migration, it’s important to transfer all the roles along with the right permissions.
KenticoWordPressEditor
Has access to the administration interface, cannot give out permissions.Editor
Has full control over posts and pages, cannot access themes or plugins.Administrator
Has unrestricted access to non-global applications for all sites in the system.Administrator
Has complete access to all features of the website.Global Administrator
Has complete access to all parts of the website.Super Admin
Has complete access across all sites in a multisite network; does not exist on a single-site setup.—
No equivalent.Author
Can only control posts, not pages.—
No equivalent.Contributor
Can only edit and delete posts.—
No equivalent.Subscriber
Can only view content and manage their own profile.
Document the nomenclature gap
Kentico and WordPress don’t share a vocabulary. Here are the key translations to know before your team starts calling things by the wrong name.
KenticoWordPressWhat it’s forPagesPostsUsed for posting blogs, articles, etc.Page typePagesTo create and organize main pages like “service”, “product,” etc. ApplicationPluginTo bring additional features and functionalities for managing the site.Administration interfaceDashboardThe main control panel for managing Kentico and WordPress sites.Translation serviceMultilingual supportTo support regional languages by translating the content for your website. Page templatesThemesTo control and manage the site’s appearance and layout.MacrosShortcodesTo insert predefined text or codes.Page builderGutenberg editor, Elementor, etc.To simplify content creation and layout management.NavigationMenusTo organize the site’s menus and handle navigation within the website.VersioningRevisionsTo track post and page changes.
Audit your content
A content audit at the discovery stage does two things. It tells you what exists, and it tells you what’s worth moving.
- Map your page types to WordPress structures
Every Kentico page type needs a WordPress destination. Document your site’s content architecture and decide where each page type belongs in WordPress. For each page type, record what it’s called, what fields it contains, and what WordPress structure it maps to.
- Sort your content before you move it
Review every page in Kentico and decide if to migrate it as-is, update it, or delete it, so outdated and duplicate pages don’t become technical debt on the new platform.
- Document your taxonomy
Kentico’s taxonomy system relies on hierarchical trees with parent-child category relationships. WordPress has a simpler system built around categories and tags, with custom taxonomies available for more complex needs.
Kentico provides three category types: personal categories, global categories, and site-specific categories.
For each category tree, decide whether it maps to WordPress categories (for hierarchical structures) or tags (for flat structures). Custom taxonomies and plugins like ACF or Custom Post Type UI handle more complex configurations.
For example, if your Kentico site has a “Product” custom post type with subcategories like “Software” and “Hardware,” WordPress replicates this using a custom post type for “Product” and custom taxonomies for “Software” and “Hardware.”
Document your editorial workflows
Audit the editorial workflows in your Kentico setup and document how content moves from draft to publication. For example, an author may submit a draft to an editor for review, followed by final approval from a department head.
For each workflow, record the people involved and their responsibilities. You’ll use this later to recreate the workflow in WordPress and assign the right roles and permissions.
Map your URLs
Your Kentico site uses .aspx extensions, document aliases, and query-string URL patterns. They don’t carry over to WordPress automatically. That’s why you need to build a URL audit spreadsheet covering every indexed page:
**Content assetKentico URLRedirect, if applicable****Multilingual URL (if applicable)**Home pagewebsite.com/about-us Yeswebsite.com/about-us/Blog posts (Number of assets)/content/blog/article-title Yes/fr/content/blog/article-title/Service pages/content/service/service-pages-abcYes/fr/content/service/service-pages-abc/
Note: This format is an example and can be customized based on your specific requirements and site structure.
Set your SEO baseline
Assess your current SEO position. It becomes the benchmark that confirms the migration preserved, or improved, your rankings. At a minimum, capture:
- Current keyword rankings for high-value pages (Google Search Console)
- Organic traffic by page (Google Analytics)
- Meta titles, meta descriptions, alt text, canonical tags, OG tags, field by field
- Existing schema markup types and which pages carry them
- Backlinks pointing to high-value URLs (Ahrefs or SEMrush)
Schema markup needs its own audit step. Use Google Search Console to catalogue which schema types are implemented, validate them with a schema validator, and flag any conflicting schema types.
Audit user behavior
Capture a baseline of how users interact with your Kentico site. Track:
- Where users click
- How far they scroll
- How long they stay
- Where users drop off
- Issues affecting the user experience
It gives you something to compare against after launch and helps identify areas that need improvement.
Audit your site performance
Capture the key metrics from your Kentico site to set a baseline for the new WordPress setup and measure the impact of the migration. Here’s a brief table of what to check:
Check****What to doTraffic analysisUse Google Analytics to identify highest-traffic and lowest-traffic pages.Page speedRun key pages through Google PageSpeed Insights and record scores.Mobile usabilityCheck for mobile friendliness, if the website is configured for mobile devices.Load testingRun spike testing to see how Kentico handles traffic surges.
rtCamp’s 20-hour free discovery covers all of this. We provide you a phased migration roadmap, confirmed risks, and budget as the output before any contract is signed.
Planning phase: Build a migration plan that actually holds
As a typical enterprise migration is running 3–6 months while Kentico XP13 reaches full end-of-life on January 1, 2027, the planning phase should already be underway.
Start by assembling the cross-functional team of IT, marketing, legal, and finance. Decisions they’ll make here about hosting, single site vs multisite, and whether to retain or redesign the frontend set the scope for everything that follows.
Hosting is one of the first decisions to make. And one of the hardest to reverse.
How to plan your WordPress hosting
Your hosting setup needs to support the site you’re migrating today and the one you’ll have tomorrow. Think through these practical points before you commit to a hosting environment:
- Choose the right hosting type. Compare shared, VPS, dedicated, and managed WordPress hosting based on your site’s needs. If you have an enterprise website, WordPress VIP will be a good fit.
- Check performance and scalability. Review server speed, uptime, response times, CDN support, and the ability to scale as traffic changes after migration.
- Review security requirements. Look for SSL, firewalls, DDoS protection, automatic backups, and any certifications your organization requires. Again, we recommend WordPress VIP if an enterprise needs FedRAMP-certified hosting.
- Confirm the infrastructure. Check CPU, RAM, storage, MySQL/MariaDB support, and compatibility with the WordPress plugins you plan to use.
- Plan for backups and recovery. Choose a provider with sufficient storage and reliable backup options to protect your data during and after migration.
- Check the support you’ll get. Review technical support availability and whether the provider offers tools or assistance for the migration itself.
Turn the migration into a phased plan
Translate the EOL deadline into phased milestones. Frontend build, backend migration, and content migration can run simultaneously in a staging environment, which compresses the overall timeline. They’re not fully independent, though. For example, content migration can’t be completed until the backend architecture it depends on is in place.
Kentico migrations need their own risk register. The failure modes are specific: widget zone content without a Gutenberg equivalent, MSSQL to MySQL conversion edge cases, and .aspx redirect complexity at scale. Each needs an owner and a mitigation plan before migration begins.
This is also where you pick your migration partner. Look for demonstrated experience with Kentico’s specific architecture, a track record of .aspx URL mapping, and a phased delivery model that keeps the live site running throughout. They should be able to commit to specific deliverables at each phase.
Module****Deliverables from the migration teamFrontend development– Design analysis – WordPress themeCMS feature development – WordPress multisite instance – Custom WordPress pluginsContent migrationA default WordPress setup with migrated contentInternal UATTesting of the entire WordPress setupTraining & documentation– X number of offline/virtual/online editorial & WordPress dashboard training sessions – Admin/Editor manualsFixes based on client UATResolve issues reported during UAT by the Customer’s teamDelta import & deploymentLive site deployed on production hosting environment setupPost-go-live supportX number of days for observation and support for patches or bug fixes
Backups and environment setup: The phase that determines what’s recoverable
Before any migration work begins, you need a complete backup of your Kentico environment and a staging setup that mirrors your live server. Problems discovered mid-migration without a clean restore point are significantly harder to fix than problems caught before it.
Create a complete Kentico backup
Kentico stores all site content, user data, and metadata in a Microsoft SQL Server database. It gives you several ways to protect that data during migration:
- Automatic backups
Kentico can automate full backups for production environments. These include daily backups with a retention policy based on your service plan and weekly backups retained for up to 30 days.
- Manual backups
You can also create manual backups for both production and non-production environments using the Backups application in Kentico. During this process, you can choose between a full backup, which includes all components (application, database, and storage files), or a partial backup where you can select specific components. At this stage, you may choose/filter the data you want to back up.
- Content and media backups
Back up published content separately and export your media assets using Kentico’s built-in tools. You may also transfer files manually via FTP or a similar method.
Go through the various site elements you backed up, such as posts, pages, product listings, media files, and form submissions, and confirm they are complete and accurate.
Note: Store the backup on an external hard drive or a cloud storage service.
As a safety measure, once the backup files are uploaded, conduct a thorough test to verify that all critical components have been successfully backed up.
Set up your migration environments
On the environment side, you’re setting up three parallel environments:
- Development (where you set up WordPress, build themes and plugins, migrate content in batches, and make code changes),
- Staging (which matches the live server configuration and is where everything is tested),
- And live.
The staging environment has to mirror production, which includes server settings, database configuration, and hosting setup. Otherwise you’re testing against conditions that don’t reflect what go-live will look like. As migration work is completed in development, move it to staging for testing and only push it live once it’s approved.
Teams that compress this phase tend to find data integrity problems during the technical migration rather than before it, when they’re harder and more expensive to resolve.
The technical migration: What moves and how
The technical migration runs on two parallel tracks, backend data and frontend rebuild.
Migrate the backend
On the backend, the critical step is the extract, transform, load (ETL):
- Extracting data from Kentico’s MSSQL database,
- Transforming it to fit WordPress’s schema,
- And ingesting it into WordPress’s MySQL schema.
Extraction methods vary depending on what’s being moved. Structured content typically comes out via the Kentico API or direct MSSQL query patterns, while the Kentico Migration Toolkit handles broader data transfers. WordPress ingestion runs via WP-CLI and custom importer scripts built around the specific data shapes Kentico exports.
You also need to recreate the functionality your site depends on:
What to migrate****What to do in WordPressWorkflowsRecreate the workflows from your Kentico setup on your new WordPress stack. Some may require custom development.Third-party integrationsReconnect CRMs, payment gateways, analytics tools, and other external services or APIs.PluginsAdd the plugins from the WordPress library or create custom plugins to achieve features/functionality parity between your Kentico and WordPress setups.
Before anything goes live, a reconciliation pass checks that every content object arrived intact and nothing was lost or corrupted in the schema conversion.
Rebuild the frontend
You can retain your current Kentico design or use the migration as an opportunity to redesign it. Either way, you’ll need a WordPress theme to implement the design.
Choose and build your WordPress theme
You can build a custom WordPress theme from scratch or customize an existing one to match your chosen design. Many clients we have worked with prefer custom themes with intuitive page editors like Gutenberg, Elementor, and similar.
Create the main navigation, header, and footer
When creating your custom theme, build the elements that give the site its structure. Use WordPress’s menu system for navigation, and set up the header and footer so they can be adjusted through WordPress or with custom blocks.
Build custom blocks and layouts
Kentico’s widget zones and page builder layouts need to be rebuilt as Gutenberg blocks or custom block patterns. Refer back to the Kentico components you documented during discovery and recreate them as Gutenberg blocks where needed. These can include text, images, galleries, testimonials, and other reusable elements.
Then combine those blocks into common page layouts, such as multi-column sections, CTAs, and image grids. Done well, this gives editors the freedom to handle routine page changes themselves rather than depend on developers as they did in Kentico.
Content migration: Mapping Kentico to WordPress
As mentioned, Kentico and WordPress don’t share the same vocabulary. For example, what Kentico calls a Page Type, WordPress calls a Custom Post Type, and the like:
Kentico****WordPressPage TypesCustom Post TypesWidget ZonesGutenberg blocksTaxonomyTaxonomyLanguage VersionsMultilingual setupForm definitionsRecreated on WordPress sidePersonalisation rulesNo direct equivalent — rebuild or deprecate
The mapping itself may look straightforward, but applying it across an enterprise site without losing content or relationships adds complexity. That’s why it helps to have an experienced migration team behind you.
As you prepare to put the mapping into action, confirm what still needs to move.
Re-audit and freeze your content
Before the final migration, re-audit the content you reviewed during discovery. New pages may have been published since then, while other content may now be outdated or no longer worth moving.
Set a content freeze at least a week ahead of the migration and notify everyone who publishes to the site. Clear the content pipeline so the source stays stable while the final migration runs.
SEO migration: Preserving rankings from Kentico to WordPress
Ranking loss is the fear that comes up most often. It’s preventable with the right methodology. Yet, no generic redirect tool will do as Kentico’s URL architecture requires a purpose-built approach.
Kentico uses .aspx extensions, document aliases, query-string URLs, and language prefix patterns. None of these translate automatically to WordPress’s permalink structure. The work is:
Recheck your SEO baseline
You already established an SEO baseline during discovery. Recheck it before the final migration to capture any changes that happened in the meantime.
Record current organic traffic, keyword rankings, and high-value URLs. Pay particular attention to pages that rank for important keywords or bring in significant traffic, as these should take priority during migration.
Map and test your redirects
If a URL changes, map the old Kentico URL to its new WordPress destination with a 301 redirect. Keep a redirect map that records both URLs:
Old URL****New URL/blogs/old-blog-post/blogs/old-blog-post//services/web-development/services/website-development/
Here’s how WordPress treats URLs:
If the URL stays the same, a redirect may not be necessary. For URLs that do change, you can manage 301 redirects with WordPress plugins such as Redirection or Yoast SEO. Test them before launch to confirm visitors and search engines reach the right pages.
Transfer your SEO metadata
Move the SEO data attached to your Kentico content along with the content itself, including:
- Meta titles and descriptions
- Image alt text
- Canonical tags
- OG tags
You can import this data into an SEO plugin, like Yoast SEO or All in One SEO, or use database queries for a manual migration.
Update your links
Check hard-coded internal URLs and update any that still point to the old Kentico structure. Review outgoing links for broken destinations and monitor backlinks to important pages so they continue to resolve correctly after migration.
Switch your DNS to WordPress
When you’ve validated the migrated content, update your DNS settings to direct visitors away from Kentico and to WordPress:
- Log in to your domain registrar and open the DNS settings.
- Update the relevant DNS records, such as A or CNAME records, to point to your new WordPress site.
- Follow your registrar or hosting provider’s instructions for any provider-specific configuration.
DNS changes can take up to 48 hours to propagate, depending on your hosting and DNS setup.
Notify search engines
Submit your new sitemap to Google Search Console. WordPress generates one automatically from version 5.5. You can access it by adding /wp-sitemap.xml at the end of your domain. For example, https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.yourdomain.com%2Fwp-sitemap.xml.
To submit: Google Search Console → Sitemaps → Enter your sitemap URL → Submit.
Note: Search Console takes time to validate the sitemap after submission.
VinSolutions went through this process and preserved all SEO page ranks through permalink mapping and legacy URL redirects. Cox Automotive saw 2X Core Web Vitals improvement post-migration.
Migration risks: What goes wrong in Kentico migrations specifically
Not on generic checklists, the risks that sink Kentico migrations are specific to how Kentico structures content, handles URLs, and stores data. Other key risks are:
- Widget zone content with no Gutenberg block equivalent: content that doesn’t map cleanly needs a rebuild decision before migration.
- Kentico page type inheritance: the parent-child hierarchy doesn’t translate to WordPress CPT structure automatically.
- MSSQL to MySQL type conversion: edge cases in data types that cause silent data corruption if not caught in reconciliation.
- Personalisation rules: no direct WordPress equivalent. Each rule needs an explicit rebuild or deprecate decision.
- Form submission history: loss of historical submissions is a compliance risk for regulated industries.
- Document aliases: Kentico’s alias system creates redirect conflicts at scale if not mapped in advance.
- Multilingual content structure: Kentico Language Versions and WordPress’s multilingual approach are structurally different and need deliberate remapping.
This is the chapter to bring to your steering committee that needs to understand what the risks are and how they’re being managed.
Post-migration checklist: What to verify after launch
Going live is not the finish line. The first 30 days post-launch are when issues with redirects, content mapping, and integrations show themselves. Catch them early while the migration team is still close to the project.
Work through these areas after launch:
Content validation
Compare the migrated site against your Kentico backup and content mapping audit from discovery.
Confirm all content types are fully transferred: blog posts, pages, custom post types.
Check all internal and external links redirect correctly.
Verify formatting, word count, and page structure are consistent on the migrated site.
Spot-check custom post type mapping against source Kentico page types.
Verify widget zone content rendered correctly as Gutenberg blocks.
Test form submissions end-to-end, including form submission history for any compliance-sensitive forms.
Media library review
Review the WordPress media library to confirm that assets transferred correctly and display as expected.
Confirm all images, videos, and assets are present and in the correct folders in the WordPress media library.
Check that alt text, titles, and captions transferred intact.
Test media files on content pages to confirm they load correctly.
Check videos for load errors and wait times.
Design validation
Don’t assume that because a page looks right in Chrome, it works everywhere. Test the design on browsers and devices before you call it done:
Test type****What to checkCross-browserOpen the site in Chrome, Firefox, Safari, and Edge, confirm layouts, fonts, and colours render consistently on all four.Device testingTest on desktop, tablet, and mobile, include both iOS and Android to confirm the site works on platforms.Screen resolutionVerify the layout adapts correctly from 4K displays down to small mobile screens, resize browser windows or use responsive design tools.AccessibilityValidate against WCAG 2.1 standards, use Lighthouse or Axe to check screen reader support, keyboard navigation, and colour contrast.Automated UIRun Playwright or Selenium scripts to catch visual or functional inconsistencies in different environments.UATHave real users test the site before launch. If something doesn’t work the way they expect, fix it here.RegressionAfter any fix or update, retest to confirm the change hasn’t broken something that was working before.
Learn more on testing types we use
Functional testing
Now, test the parts of the site users interact with:
Validate forms, buttons, and navigation menus behave as expected.
Test every form submission, button click, and navigation link.
Verify WordPress user roles and permissions are correctly configured.
Confirm users can access appropriate content and admin controls based on their role.
Performance testing
Run key pages through Google PageSpeed Insights and GTmetrix. Compare scores against the pre-migration baseline set in discovery.
If scores are below baseline, work through these:
- Optimise CSS and JavaScript to reduce server requests
- Implement a CDN (Cloudflare or equivalent)
- Compress images without quality loss
- Enable lazy loading for images and videos
- Enable browser and server-side caching
- Confirm hosting environment is configured for optimal performance
Security testing
Here are a few recommendations for your WordPress security setup:
Install Wordfence or Sucuri to monitor for malware, spam, and brute force attacks.
Run a vulnerability scan using WPScan to identify outdated plugins, themes, or misconfigured settings.
Confirm all plugins, themes, and WordPress core are up to date.
Verify two-factor authentication is enabled.
Audit file and folder permissions to prevent unauthorised access.
Confirm role-based access controls are correctly configured for all user roles.
Confirm backup strategy is active and storing copies securely.
For enterprise sites with compliance requirements, WordPress VIP provides FedRAMP-certified hosting with security monitoring built in.
Post-launch SEO checks
Search engines need time to process a migration. While they do, watch for these:
Submit change-of-address in Google Search Console.
Crawl every legacy Kentico URL and confirm it redirects to the correct WordPress destination without broken chains or loops.
Monitor crawl errors for the first 30 days.
Review keyword rankings and organic traffic against the pre-migration SEO baseline.
Check for 404 errors, 5xx errors, noindex tags, and canonical tag issues in GSC.
Run HTML validation via W3C Validator. Fix errors that affect accessibility or SEO.
Address any metadata gaps, like missing titles, descriptions, or schema markup identified post-migration.
Post-migration user experience
Compare against the user behavior baseline documented during discovery:
- Click maps: confirm navigation and CTAs are performing as expected.
- Scroll maps: validate content placement decisions held in the new layout.
- Conversion funnels: identify any new drop-offs that didn’t exist pre-migration.
- Time on page: compare engagement levels against pre-migration data.
- Error tracking: surface any technical issues affecting user experience.
As your migration is almost done, turn back to the goals you set at the start and check whether the new WordPress setup delivers on them.
Post-migration training: The phase most underestimate
Your team has years of Kentico habits. WordPress works differently enough that without structured onboarding, editors end up just as dependent on developers as they were before, which, of course, defeats the point of migrating.
The training program covers the UI differences that catch Kentico users out. We’re talking things like:
- The content tree becoming a WordPress admin,
- The page builder becoming Gutenberg,
- Kentico’s workflow states mapping to WordPress’s publishing model.
Each has a learning curve that’s specific to what Kentico users already know and need to unlearn.
Start with the core WordPress concepts:
- Dashboard navigation
Run sessions on standard practices for using the WordPress dashboard, including menu navigation, managing posts, pages, and accessing media. Tailor the overview to each stakeholder group so training is relevant to what they actually use.
- Creating and editing content
Train the team on how to create and edit pages, posts, and custom post types. Cover templates, theme selection, and content patterns.
- User roles and permissions
Explain each WordPress role, what it can and cannot do, and assign permissions that align with each team member’s responsibilities.
- Themes and plugins
Provide an overview of the active theme, its customisation options, and all installed plugins. Flag any plugins that are critical to the site’s operation.
- Gutenberg block editor
Walk through the basic concepts and common blocks. Teams coming from Kentico’s page builder will need hands-on time here before they feel comfortable.
- Media library
Show how to upload images and videos, edit media details like alt text and titles, and organise files by folder.
- Documentation and manuals
Create training manuals for all customised sections of the WordPress solution. This way, knowledge doesn’t walk out the door with the implementation team.
For everyone involved in publishing, training should cover the full journey from first draft to a live page.
- Content creation and review
Train the team on how to draft, edit, review, and publish content. Cover version controls and autosave so editors can track changes.
- Scheduling and publishing
Teach the team how to schedule posts, manage categories and tags for consistent content organization. Set up guidelines for reviewing drafts and approvals if multiple contributors are involved.
- SEO best practices
Add plugins like Yoast SEO and teach team members how to optimize meta titles, descriptions, and content readability to improve search rankings.
Alternatives to WordPress for Kentico migration
Enterprise committees evaluating Kentico alternatives usually look at the same shortlist. Most popular tools to consider are:
- Drupal has stronger content modelling for complex hierarchical structures, genuinely stronger than WordPress out of the box. Developer cost is higher as a result, and while Drupal CMS 2.0 (released January 2026) has narrowed the editorial usability gap with a visual editor, the specialist dependency remains.
- Contentful and other headless CMS architectures give you decoupled flexibility and clean separation between content and presentation. The catch is API licensing costs and ongoing infrastructure complexity that teams consistently underestimate at the outset.
- Sitecore, now rebranded as SitecoreAI, has repositioned as an AI-first DXP. XP customers migrating to it still face a full replatform, with vendor licensing that can run $500K+ annually. The upgrade-cycle problem that created this decision doesn’t go away.
Headless WordPress is a viable middle path for teams with existing API infrastructure who want WordPress’s editorial layer without the coupled front end.
PlatformStrengthWatch out forDrupalContent modelling depthHigher developer cost, specialist dependencyContentful / headlessDecoupled flexibilityAPI licensing, infrastructure complexitySitecoreAIAI-first DXP capabilitiesFull replatform cost, $500K+ annual licensingHeadless WordPressEditorial layer + API flexibilityRequires existing API infrastructure
WordPress is the recommendation for most Kentico teams. It’s an open-source infrastructure you own, a PHP ecosystem most enterprise teams are already familiar with, and it powers 43% of the web, including whitehouse.gov, the BBC, Reuters, and Time Magazine.
Kentico migrations at enterprise scale: Two examples
VinSolutions came to rtCamp on Kentico CMS with one goal: consolidate its business and CRM properties under one platform without losing the SEO equity built up across legacy URLs. rtCamp migrated to WordPress VIP multisite, rebuilt the site with Gutenberg and Elementor, and mapped every legacy URL through the redirect process. With all SEO page ranks preserved, core Web Vitals improved by 48%, and the marketing team now publishes independently without developer involvement.
Read the VinSolutions case study
Cox Automotive was running several brand sites across AEM and Kentico. Each has its own codebase, own maintenance overhead, but no shared design system. rtCamp migrated all 8 to a unified WordPress architecture using the proprietary OnePress multisite framework, reusing 80% of design components across brands. Redesigned websites were 21% faster and more user-friendly.
Read the Cox Automotive case study
Get the 20-hour free discovery
We’ll map your Kentico architecture, tell you what needs rebuilding, and help you put together the internal case.
Book your free discovery session
Top Partner Innovator Award
WPVIP 2022
Frequently asked questions
How long does a Kentico to WordPress migration take?
For enterprise sites, 3–6 months is typical for a phased migration. It depends on your content volume, integration complexity, and number of page types. rtCamp’s 20-hour free discovery gives you a phased roadmap and timeline.
Will we lose SEO rankings when migrating from Kentico?
Not with the right redirect strategy. Kentico’s .aspx URL structure requires a purpose-built redirect map. Generic redirect approaches don’t account for document aliases and query-string patterns. VinSolutions preserved all SEO page ranks through permalink mapping and legacy URL redirects.
Can WordPress handle Kentico’s content complexity: page types, widget zones?
Yes, with deliberate architecture. Kentico Page Types become WordPress Custom Post Types. Widget Zones translate to Gutenberg blocks. The work is in the mapping.
What happens to Kentico’s .aspx URLs?
Before the DNS switch, every Kentico URL gets mapped to its WordPress equivalent, and a full crawl simulation runs to catch any broken redirects at scale. After launch, you submit a change-of-address in Google Search Console to signal the move to Google and speed up re-indexing.
Is WordPress as capable as Kentico for enterprise editorial workflows?
For most enterprise use cases, yes. WordPress covers role-based permissions, content scheduling, editorial workflow, and multisite governance, either natively or through the plugin ecosystem. The practical difference most teams notice is that WordPress editors can handle routine publishing and content updates without pulling in a developer. With Kentico, that’s rarely the case.
How much does a Kentico to WordPress migration cost?
There’s no single number for an enterprise migration. A 500-page site with two integrations costs very differently from a 50,000-page multisite with a CRM, DAM, and custom workflows. rtCamp’s 20-hour free discovery exists specifically to scope that: you get a phased budget with no obligation before any work begins.
Can our team maintain WordPress after migration?
Yes, WordPress’s admin interface requires no developer involvement for routine publishing. rtCamp’s post-migration training is structured by role: editors, managers, and developers each get a program mapped to their Kentico muscle memory and what needs to change.
TL;DR
Why enterprises are leaving Kentico XP13
TCO: How to build a business case for migration
Kentico vs WordPress: Comparing the two at enterprise scale
Discovery phase: Map what you have before you move it
Define your migration goals
Evaluate your existing Kentico setup
Map your third-party integrations
Audit your user roles
Document the nomenclature gap
Audit your content
Map your URLs
Set your SEO baseline
Audit user behavior
Audit your site performance
Planning phase: Build a migration plan that actually holds
How to plan your WordPress hosting
Turn the migration into a phased plan
Backups and environment setup: The phase that determines what's recoverable
Create a complete Kentico backup
Set up your migration environments
The technical migration: What moves and how
Migrate the backend
Rebuild the frontend
Content migration: Mapping Kentico to WordPress
Re-audit and freeze your content
SEO migration: Preserving rankings from Kentico to WordPress
Recheck your SEO baseline
Map and test your redirects
Transfer your SEO metadata
Update your links
Switch your DNS to WordPress
Notify search engines
Migration risks: What goes wrong in Kentico migrations specifically
Post-migration checklist: What to verify after launch
Content validation
Media library review
Design validation
Functional testing
Performance testing
Security testing
Post-launch SEO checks
Post-migration user experience
Post-migration training: The phase most underestimate
Alternatives to WordPress for Kentico migration
Kentico migrations at enterprise scale: Two examples
Get the 20-hour free discovery
Frequently asked questions
How long does a Kentico to WordPress migration take?
Will we lose SEO rankings when migrating from Kentico?
Can WordPress handle Kentico's content complexity: page types, widget zones?
What happens to Kentico's .aspx URLs?
Is WordPress as capable as Kentico for enterprise editorial workflows?
How much does a Kentico to WordPress migration cost?
Can our team maintain WordPress after migration?
On this page
kentico to wordpress migration, Migration
Credits
Aviral Mittal
Author
Aviral Mittal
Author
Aviral Mittal is the Chief Marketing Officer at rtCamp, where he established and leads the marketing function, building and growing a team of 20+ specialists across content, SEO, design, and growth…
Contributions and Updates: Abhijit 
Related articles
-
Why CMOs and CTOs are moving away from Kentico
Articles
-
The best Kentico alternatives for enterprise: When upgrading costs as much as leaving
Articles
Comments
Leave a Reply Cancel reply
Name*
Email*
Comment*
Submit
Δ