In our demo, you can see how KentiCopilot speeds up codebase migration from Kentico Xperience 13 (KX13) to Xperience by Kentico (XbyK). This guide is a practical next step.
It builds on the KentiCopilot GitHub documentation (opens in a new tab) and focuses on tips, best practices, and common pitfalls. You will learn what to expect in each migration phase and how to shape the workflow to fit your architecture.
mcp.json, remove or disable that entry. Then open your IDE's or CLI's MCP servers list and confirm that only one entry is running. A single active registration guarantees no duplicate instances or unnecessary token usage, regardless of which AI host you use.To avoid any human-error-related oversight, ask your AI assistant to review your project structure and overall setup according to the docs for you.
Migrate your database to Xperience by Kentico before you start migrating your code. The agent reads the target XbyK database for essential tasks, such as generating content type classes, so the code migration depends on it.
See how KentiCopilot can help you with content audit and migration, including remodeling scenarios.
There are three main parts to code migration:
This page is intentionally not a full command walkthrough. Our GitHub documentation (opens in a new tab) provides the complete command flow and prompt syntax.
At a high level, you need to run the global migration first to seed the target project. Then migrate your pages and shared components in the order that suits your project. For pages that use Page Builder, migrate widgets and sections before page logic.
Before you start the code migration, ask the agent to examine your project and produce an overview:
App_Data/CIRepository, if Continuous Integration is enabled): which specific pages actually use Page Builder and which widget and section types they render. If CI isn't available, this per-page usage comes from the database instead (the KentiCopilot content-model audit skill (opens in a new tab) can export it).This overview helps you decide the order in which to migrate your pages and components.
We recommend you only move forward once the current phase is stable:
After global migration: the project compiles, startup runs without errors, and content type classes exist for every content type in your solution.
After each page migration: the page renders correctly and the Page Builder tab appears on pages that need it.
Consider enabling Page Builder for almost all migrated page content types, even if the KX13 original didn't use it. This keeps the option of using page templates open later. If a page is migrated without a Page Builder template registration, it can be difficult to convert afterward.
After component migration: shared components render correctly across all pages that use them and have been migrated. The agent visually compares each component against the KX13 original using Playwright, and it skips components it has already migrated, so you can re-run /migrate-shared-component safely.
The agent attempts to resolve build errors during migration, so most issues are handled for you. If something still does not build or render correctly, ask the agent to identify the root cause and fix it before you continue. If you're unsure what to do next, ask the agent to propose the next best migration step based on your current project state.
If a migrated page's look and feel doesn't match the KX13 original, run /migrate-page-visual. This skill uses Playwright to compare the migrated page against the original and realign the styling.
The default run (lift-and-shift) produces working code with no upfront configuration, but it also lets the agent make structural decisions for you: content retrieval logic lands in controllers, components go into flat directories, and naming follows agent defaults. For production projects, you usually want your own conventions, such as feature folders, shared services, and consistent naming. The skills are architecture-agnostic by design, so you can shape the output by giving the agent project-specific instruction files (opens in a new tab).
To quickly create instructions, point the agent at a well-structured XbyK project and have it generate your instruction files from that project's patterns. Suitable reference projects, in order of preference:
An example prompt to generate the files:
Review the structure and patterns in [reference project]. Generate instruction files that guide code generation for my project, covering: solution and project structure and dependencies; feature organization; content retrieval; the layering from content types to domain models, repositories, services, controllers, and view models; naming conventions; service registration; C# style; and the docs the agent should consult. Where it helps, split the guidance into focused files scoped with applyTo, each covering a single concern.Based on your needs and the complexity of your project, the result can be a small set of focused files or a single document. For example, a project-structure instruction file might spell out the folder layout you want the agent to follow:
src/
├── DemoProject.Entities/ # Interfaces and generated content type classes
├── DemoProject.Core/ # Domain models and business logic, no infrastructure
├── DemoProject.Web/ # ASP.NET Core app: UI + infrastructure
└── DemoProject.Admin/ # Admin customizations
Web/Features/Blog/
├── BlogPostPageController.cs # Thin: injects a service, returns a view
├── Repositories/ # Data access, returns domain models
├── Services/ # Orchestrates repositories + domain logic
├── ViewModels/
└── Views/Whether you keep everything in one file or split it across several, aim to cover:
You reshape your content model during the content migration, before you migrate code. The content migration skills (opens in a new tab) handle this and support transformations such as:
Because code migration reads your migrated XbyK database, it works from the remodeled structure instead of just the original KX13 codebase.
Simple remaps are usually reliable. More involved remodeling can work well too. However, the more your target model diverges from the source, the more important review discipline becomes.
The quality of the migration output depends on the model you use. A more capable LLM makes better architectural decisions and handles edge cases more reliably.
The skills are a starting point:
The migration skills are intentionally general-purpose. They're meant to be extended for your specific project: add context, adjust prompts, and introduce project-specific patterns. The KentiCopilot repository (opens in a new tab) is the right place to start.
Useful links:
Some of these resources are referenced above; others are additional material for deeper context and practical guidance: