Migrate your code with KentiCopilot

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 plugin is built to handle that work. Watch our quick demo of what’s possible, then read about what happened at each phase.

Before watching, we recommend you look over the Upgrade from KX13: overview. Code migration is one phase of a larger process; content migration happens separately, beforehand.

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 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 will cover this in an upcoming guide.

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, we’ll talk about some best practices to follow during the KentiCopilot-powered code migration, including enforcing certain project architecture.