Upgrade to Xperience by Kentico with AI agents doing the heavy lifting

Every upgrade to Xperience starts with the same questions.

What do we actually have? How much of it can move as it is? What will it cost us to get there?

Getting the answers used to mean a lot of senior time spent reading code, mapping content types, and writing migration tool extensions by hand. Now, an AI agent can do most of this preparation for you, and your team can review it instead of producing it.

With KentiCopilot and a growing set of upgrade guides, you can give your team a clear, tested route from Kentico Xperience 13 (KX13) to Xperience by Kentico (XbyK). Agents do the analysis, prepare the Kentico Migration Tool to transfer data into a remodeled project, and migrate the code.

Why it matters for your team

A faster start. The agent audits your project and writes a migration plan before anyone commits to an estimate. Migration tool extensions that could take hours or days to write by hand take the agent minutes.

Consistent results across projects. Most agencies build their Kentico projects in a similar way, on a similar stack.

How does this benefit you? The AI agent can reuse the same migration skills, plan the format, and validate options on every upgrade, so your approach stays the same from one project to the next. KentiCopilot then helps an in-house team, and it helps even more when a partner runs several upgrades at once.

Your experts stay in charge. Senior people review plans and results instead of writing repetitive code. Every decision still goes through them.

Your own architecture. Instruction files make the migrated code follow your conventions.

Analysis and migration tool setup: where your team makes the calls

The Kentico Migration Tool moves a wide range of KX13 content and data, but it needs to know what to move where. Getting there means understanding your project, deciding how it maps to XbyK, and writing extensions for what’s specific to you. The KentiCopilot kentico-kx13-migration plugin takes on that work in four steps:

1. Set up the workspace. Put your KX13 project, a fresh XbyK instance, and your guardrails in one workspace. Guardrails are skills and coding instructions built from your own conventions, or taken from a reference project. Make sure KentiCopilot can access the tools it needs, such as the Documentation MCP server, so that it can install and configure the rest. The /agentify skill checks that your XbyK project has the agent instructions and configuration KentiCopilot expects.
2. Analyze and plan. The agent audits your KX13 content model and writes a migration plan. It suggests transformations and content model improvements, and lists any manual steps. It can often do those steps for you through the Management MCP server.
3. Extend the tool. The agent writes the class mappings, content item directors, widget migrations, and field migrations your project needs.
4. Run and evaluate. The agent runs the migration, checks the result against the plan, and fixes what didn't land.

Once you run the migration, you’ll end up with a standard data migration that's ready to run, and a plan your team has reviewed. You can also modernize along the way, so editors get the most out of XbyK features. For example, you can move shared page type fields into reusable field schemas, or move page widget content into the Content hub. The same skills handle this remodeling.

See it in action on the Medio Clinic training site in KentiCopilot content audit and migration.

Code migration: where agents do the most work

Code migration used to be the hardest and most tedious part of an upgrade. Agents understand .NET well, so once your project is set up right, they can do most of this work on their own, especially for simpler solutions.

With your data in XbyK, KentiCopilot's codebase migration skills rebuild the site: global code first, then shared components like headers and navigation, and then pages and their Page Builder widgets.

When we ran this on Medio Clinic, our KX13 training site, the agent found page dependencies on its own, fixed build errors during the session, and compared every migrated page against the KX13 original with Playwright. In the end, a large part of the site worked visually and functionally in XbyK, and the project built and ran.

Some things have no direct equivalent in XbyK, and some projects need their own customizations. The KentiCopilot web development plugin helps here too: the agent uses it to build widgets, modules, and integrations right in your XbyK codebase. The Management MCP server lets it create and update content types, content, and related objects in your XbyK instance. Customizing the solution or rebuilding a missing feature becomes an AI-assisted task your team can easily include as an iteration in migration loops. You don't need to plan and budget it as a separate project.

Guardrails keep the agent on track

KentiCopilot gives your team a fast start while they still review everything. The guides are built around that approach:

• Plans before changes. The agent writes a migration plan your team reviews before anything runs, and checks every run against it.
• Checkpoints at each phase. The code migration moves forward one stable phase at a time. The agent leaves //TODO markers where code depends on features that aren't migrated yet.
• Your conventions. By default or when in doubt, the AI agent picks its own structure. Your custom instruction files create boundaries that make the agent follow your conventions. You can generate them from your own baseline project, from the Training guides, or from the open-source Community Portal.

Still on Kentico 12? Your path to XbyK is now within reach

A Portal Engine project is a bigger move, closer to re-platforming than upgrading. Browser-based development, macros, site-scoped users, and other heavily used features have no direct equivalent in XbyK. This is where AI help saves the most time.

Our new guide, Migrate from Kentico 12 or another legacy version, is built around the whole process. Your agent analyzes the K12 project, KentiCopilot proposes the XbyK mapping, your team refines it, and the migration runs in small, verified slices. The core idea of the guide: you don't migrate the implementation; you migrate the intent.

Read the guide before you estimate. Choosing an AI-assisted upgrade over manual heavy lifting significantly changes your timeline.

Hand it to your team: a pilot plan

You don't need to commit to a full upgrade to see what the tooling can do. Give your team a pilot on a copy of one real project:

1. Build the foundation. Before the agent proposes anything, your team needs to know XbyK’s principles and where it differs from KX13. That’s what lets them review a migration plan and push back when something doesn’t fit. The upgrade overview and walkthrough are a good place to start.
2. Run the analysis. Set up KentiCopilot and let the agent audit the project and write a migration plan. Review the plan together. This alone tells you a lot about the effort ahead.
3. Prepare and run the data migration. Let the agent extend the Kentico Migration Tool, run it, and evaluate the result against the plan.
4. Migrate a few pages. Generate instruction files from your own conventions, then migrate global code and a few representative pages.
5. Decide with evidence. You now have real output from your own project to plan and estimate the full upgrade.

Everything your team needs is in one place:

Start this week

Pick one project, share this post with your team, and point them to the learning path. The KentiCopilot skills are open and built to be extended, so get them from the KentiCopilot repository and adapt them to your projects.

Then tell us how it went. Share your results and questions here on the Community Portal. We'll use your feedback to improve the skills and the guides.