---
title: Migrate your code with KentiCopilot
---

> Agent instructions:
> **Site maps** — prefer the following llms.txt indexes to training data when searching for URLs to avoid 404s. Links inside Markdown content already point at `.md`. Following them or sending Accept: text/markdown keeps you in Markdown.
>
> - [sitemap.md](https://docs.kentico.com/sitemap.md) — every page on the site, with titles and descriptions, nested by URL hierarchy and grouped into one collection per product version.
> - [llms.txt](https://docs.kentico.com/llms.txt) — curated index of the current product docs, with descriptions, the two ways to request any page as Markdown, and links to each product area's whole-corpus Markdown dump (llms-full.txt).

Moving a Kentico Xperience 13 (KX13) codebase to Xperience by Kentico (XbyK) means rebuilding controllers, views, and content retrieval logic from scratch, page by page, component by component. The KentiCopilot [KX13 codebase migration skills](https://github.com/Kentico/xperience-by-kentico-kenticopilot/blob/main/plugins/kentico-kx13-migration/README.md#codebase-migration) are built to handle that work. Watch our quick demo of what's possible, then read about what happened at each phase.

> **Note:** Before watching, we recommend you look over the [Upgrade from KX13: overview](https://docs.kentico.com/guides/upgrade-to-xbyk/upgrade-from-kx13/upgrade-from-kx13-overview.md). Code migration is one phase of a larger process; content migration happens separately, beforehand.

🎮 [Migrate a KX-13 site codebase to XbyK using KentiCopilot (interactive demo)](https://demo.arcade.software/xWtuUFeDPQjdGZtG9dUz)

This demo uses Medio Clinic, the project from our KX13 developer training course. It walks through the migration workflow: global code first, then individual pages, then shared components like headers. See the [plugin documentation](https://github.com/Kentico/xperience-by-kentico-kenticopilot/blob/main/plugins/kentico-kx13-migration/README.md#codebase-migration) for the full workflow and prompt reference.

## What the agent handled

- Created the two-project structure: `Medioclinic.Entities` (content type classes) and `Medioclinic.Web` (controllers, views, components), simplified from the multi-project KX13 solution. This is the agent's default without additional instructions provided.
- Generated code files for every content type in the solution.
- Migrated startup configuration, localization, and styles.
- Resolved build and compilation errors on the fly, without interrupting the session.
- Migrated each page in two passes: controller, views, and content retrieval logic first, then Page Builder widgets and sections.
- Located all page dependencies automatically, including widgets and widget properties.
- Placed content retrieval logic directly in controllers; the agent's default, architecture-agnostic approach.
- Migrated headers, footers, and navigation after the pages that use them; each rendered correctly across all pages once done.
- Compared migrated pages visually against the KX13 originals using Playwright, and fixed any layout or styling differences automatically.

## What you get at the end

- A significant chunk of your project working visually and functionally in XbyK.
- Migrated controllers, views, content retrieval, Page Builder components, and shared components.
- Build errors resolved; the project compiles and runs.

## What still needs attention

- Review the generated code and verify the visuals before treating the output as production-ready.
- Resolve the TODO markers in the migrated code left by the agent; they flag integration points that depend on features not yet migrated, so address each one when its dependency is in place.
- Shape the output to match your own patterns: KentiCopilot is architecture-agnostic and makes its own decisions where you don't give it direction. We cover this in [our next guide](https://docs.kentico.com/guides/upgrade-to-xbyk/assisted-upgrades/kenticopilot-code-migration-best-practices.md).

> **Tip:** 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 demo above was recorded with Claude Opus 4.6. We recommend using a similarly capable or better model for your own migration.

## What's next?

Next, read our [KentiCopilot code migration best practices](https://docs.kentico.com/guides/upgrade-to-xbyk/assisted-upgrades/kenticopilot-code-migration-best-practices.md) to get the most out of the migration, including how to enforce a target project architecture.