Can KentiCopilot Speed Up a KX13 to Xperience by Kentico Migration
Summarize the article:
ChatGPT
Perplexity
TL;DR
- Yes, in specific stages — content auditing, migration planning and configuration, custom content transformations, and repetitive code conversion.
- Not in others. Architecture, integrations, authentication, search, SEO, and cutover are not directly automated by the current KX13 migration tooling.
- Generated code can outpace safe review. Senior Kentico time moves toward review rather than disappearing.
- Engineering effort compresses more than the calendar does. Coding is often only one part of the critical path.
- Benefit is stage-dependent. An MVC 5 live site keeps the audit and data-migration gains but changes code-migration scope substantially.
Kentico released KentiCopilot — a suite of AI development tools for Xperience by Kentico — and extended it to Kentico Xperience 13 migrations through 2026. Kentico's own product glossary describes it as turning work that used to take weeks into work completed in hours.
That may be true of individual tasks. It is not a statement about migrations. If you are budgeting a KX13 → XbyK project, you need to know which categories of work actually got cheaper, which did not, and what that changes about your plan and your team. That is the question answered here — not how the migration works, which our full KX13 to Xperience by Kentico migration guide covers, and not whether you can postpone it past 2026, which is a separate decision entirely.
What KentiCopilot actually does during a KX13 migration
One distinction determines whether an estimate is realistic: KentiCopilot is not a migration engine.
Kentico's Migration Tool has handled the data side of KX13 migrations for years. KentiCopilot is a layer on top: AI skills that decide how to configure and extend that tool, and write the code to do it. It is open source, free at every license tier, and available to any Kentico partner.
That sets the baseline. Any honest claim about AI savings is measured against what the Migration Tool already did — and a good deal of "AI accelerates migration" messaging quietly takes credit for the older tool.
| Type of work | What the AI tooling adds | What stays with your team |
|---|---|---|
Understanding the source | Scans the KX13 database and exports a structured inventory of the content model | Deciding what the inventory means and what should survive |
Deciding the approach | Drafts a migration plan and a validated tool configuration | Every content-model decision — the skill is built to stop and ask |
Custom transformations | Generates the code for custom mappings, then confirms the project builds | Reviewing whether the transformation is semantically right |
Converting legacy code | Rewrites legacy retrieval and component patterns into modern equivalents | Behavior, caching, performance, editor experience |
Checking the result | Structural comparison against the plan, plus automated visual comparison | Content correctness, integrations, UAT, sign-off |
Where the time savings are real
The pattern is not "easy versus hard." It is whether something can prove the output wrong. Where a source of truth exists — the KX13 database, the running legacy site, the compiler — the tooling compresses effort substantially.
Content audit. The strongest part, and notably not a language model. A compiled tool queries the KX13 database and exports the content model in structured form. Run it twice, get the same answer. Kentico describes the output as deterministic input for everything downstream.
The value is timing. Linked pages are the clearest example: by default each one becomes a duplicate item on the other side. Teams have traditionally discovered that during a rehearsal run. The audit puts it on the table in week one, while it is still a planning decision rather than a rework ticket.
Custom content transformations. Reshaping content types, consolidating shared fields, resolving relationships, transforming widget properties — this has always required custom code written against the Migration Tool by hand, then run and debugged against the migration log.
In our internal testing, the useful part was not that the agent "understood the migration." It was that once an engineer had already defined the transformation, the agent could turn that definition into working code without anyone writing the boilerplate by hand.
The denominator matters. What is faster is generating the code. Whether the transformation is correct is a separate question.
"In August 2026, we evaluated the KentiCopilot migration plugin (v2.0.0) with Claude Code against a KX13 reference implementation. The test covered content auditing, migration planning, and custom class-mapping generation, with results reviewed by a senior Kentico engineer. We did not run a controlled time comparison, so our conclusions describe workflow changes rather than quantified savings." — Ostap Hetman, Tech Lead at Bits Orchestra
Repetitive code conversion. Content retrieval is the strongest candidate for automation in the codebase, because the same conversion typically appears dozens of times with small variations. Project scaffolding, shared components, and view migration behave similarly. Widget conversion works too, with the heaviest review load in this group.
Structural evaluation. After a migration run, the tooling compares the result against the plan across twelve categories and flags mismatches. It catches structural drift quickly.
The common thread is repetition against something checkable. Sites with many structurally similar page types and components see the largest gains; integration-heavy and commerce-heavy platforms see the least. That ratio is a property of your implementation, not of the tooling.
Where the savings stop
Two things end the acceleration: coverage, and verifiability.
The AI skills cover a defined slice of the codebase. They handle global code, page controllers and views, content retrieval, Page Builder components, shared components, and visual reconciliation. Outside that slice — commerce storefront, marketing automation, search, custom admin screens, member authentication, integration code, scheduled jobs, custom APIs — there is no migration workflow.
That is a statement about tooling coverage, not difficulty. An engineer can still point an AI assistant at integration code and get help. What does not exist is a workflow that takes the job on, so the effort lands on your team as it did before. On a heavily customized platform, that portion can be the majority of the project.
Compiling proves less than it appears to. The tooling builds generated code before handing it back, so it compiles by construction. That confirms syntax, not meaning.
The clearest example: if a field is renamed during migration without an explicit mapping, the code compiles, the migration runs, no error appears in any log — and the field arrives empty. Kentico documents several failure modes in this family, and they share one property: nothing in the output tells you something went wrong. Kentico's own guidance is that generated output must be reviewed and adjusted before use.
That is why senior Kentico review is not optional here. The problem is not detectable by reading the generated code — only by someone who already knows where these failures occur.
The automated evaluation is a gate, not a proof. It compares counts and structure, not content correctness. When a database or log is unreachable it marks those checks "not available" and still produces a report, so a result can look clean while several checks never ran. When everything passes, Kentico's guidance is to proceed to UAT and manual content review. A green report is a reason to start testing, not a reason to stop.
And the decisions were never delegable. Which content becomes reusable. Where shared field boundaries sit. How linked pages should be handled. Whether to restructure now or move like-for-like and restructure later. The planning tool asks at each of these points by design.
Faster code is not a faster or cheaper migration
These claims are different and should not be traded as equivalent:
Claim | Does the evidence support it? |
|---|---|
Code generated faster | Yes — for defined transformations |
Specific development stages faster | Yes — audit, transformations, code conversion |
Fewer total developer hours | Likely, concentrated in implementation |
Fewer senior developer hours | No — they move toward review |
Migration completed faster | Partially — bounded by uncovered work |
Whole project completed faster | Weakly — much of the critical path sits elsewhere |
Lower total project cost | Depends on project structure |
Lower migration risk | Not demonstrated — a new review risk is introduced |
Kentico's own upgrade guidance lists the common causes of migration delay: underestimating complexity, limits of the migration tool, resourcing, the learning curve, and not planning time to replace KX13 features with no XbyK equivalent. Implementation speed is not among them.
The reason is structural. A migration is paced by things that do not respond to typing speed: how long stakeholders take to decide what content survives, how long integration partners take to confirm their end, how much calendar the cutover window consumes, and how many times you rehearse the data move before you trust it. A SKU-heavy dealer portal we migrated needed several full rehearsal runs before cutover, and faster code generation would not have removed a single one of them.
On cost, we will be direct: we have observed meaningful development-time reduction in specific stages, and we do not yet have enough completed project data to translate that into a total migration percentage. We found no published, project-level KX13 → XbyK benchmark from Kentico either. If a vendor quotes a percentage off the whole project, they are extrapolating from a component-level result — which is why the honest version of this conversation starts with a scoped look at your implementation rather than a number.
Technical eligibility and stage-specific constraints
The tooling has dependencies, but they apply to different stages. Treating them as one blanket prerequisite produces the wrong estimate in both directions.
Universal requirement — KX13 on Refresh 5 (hotfix 13.0.64) or newer. Below that version the Migration Tool does not run, so nothing built on top of it has anything to work with.
Code migration — the live site framework matters. Kentico states that the Migration Tool and the KentiCopilot codebase migration skills are designed for .NET Core projects, and that its sample code, guidance, and agent skills assume it. If your live site is MVC 5 on .NET Framework, that does not remove the content-audit or data-migration benefits — those read the database and are unaffected. It changes code-migration scope substantially, and pairs the platform migration with a framework modernization effort. Confirm current plugin coverage against your specific MVC 5 implementation before applying an AI-assisted estimate.
Two things that sound alike are worth separating. Moving a Portal Engine site to MVC is a prerequisite for reaching Kentico Xperience 13 at all, which we cover in our Kentico 12 to Xperience 13 upgrade guide. This constraint is different and later.
Visual comparison — a running instance. The code migration and visual comparison steps drive a browser against the legacy site. Without a reachable running instance, those specific skills cannot operate. Audit and data migration do not need one.
Media — a limitation with a documented workaround. The Migration Tool reads media files from the local file system. Files in cloud storage can be synced locally first, or the database records can migrate with binaries transferred separately. Attachments behave normally, except those stored only on disk with no copy in the database.
Beyond eligibility, benefit tracks project shape:
Project characteristic | Acceleration potential | Why |
|---|---|---|
Many structurally similar page types and components | High | Repetition with a checkable source of truth |
Large but conventional content estate | High | Audit and code generation scale well |
Like-for-like move, restructuring deferred | High | Fewer architectural divergences to decide |
Heavy custom integrations | Low | No migration workflow covers it |
Commerce-heavy | Low | Storefront is rebuilt regardless |
Content model redesigned during migration | Low | Every divergence is a human decision |
MVC 5 live site | Mixed | Audit and data gains hold; code migration narrows |
What changes for your team
Kentico positions the tooling as lowering the seniority bar for complex upgrade work. What we see is more specific: it lowers the bar for producing migration work and raises the value of the expertise needed to approve it.
Mid-level developers and strong general .NET engineers are genuinely more productive on a migration than a year ago. They can run the audit, execute the migration against an approved plan, handle first-pass view and component work, and drive visual reconciliation. That is a real expansion of who can contribute.
Approval authority does not move with it. A capable .NET engineer looks at generated migration code and sees code that looks correct. Only someone who knows where Kentico migrations fail silently sees the empty field coming.
"The tooling writes code that only a Kentico specialist can safely approve. That is a real gain — but it is a gain in throughput, not a reduction in expertise. Our senior hours did not disappear. They moved earlier and turned into reviews." — Roman Hutnyk, CEO and co-founder of Bits Orchestra, former Kentico MVP
The practical consequence for estimates: review becomes a named line item rather than something hidden inside "development."
What we would and would not delegate
Work | AI-assisted? | Human review | Architect decision required? |
|---|---|---|---|
Content inventory and audit | Yes | Light — interpret the findings | No |
Content model and target architecture | No | — | Yes |
Migration plan and configuration | Yes | Full | Yes, on every divergence |
Custom content transformations | Yes | Full, line by line | Where the mapping is ambiguous |
Repetitive code conversion and components | Yes | Behavior, performance, editor testing | No |
Integrations, authentication, search | No | — | Yes |
Content correctness, UAT, cutover | No | — | Sign-off required |
One working rule: after the second failed generation attempt, stop and write it manually. By the third round of explaining the same transformation, the design work is already done — and it usually signals the plan is wrong rather than the code.
Answer the AI question before you accept an AI estimate
How much AI tooling can accelerate your migration is a property of your KX13 implementation. Two projects on the same platform, version, and content volume can sit at opposite ends of the range.
Four questions decide which end:
- Eligibility — where does your project sit against the stage-specific constraints above, particularly the framework one?
- Repetition — how much of your content model and component library is structurally similar?
- Coverage — what share of your platform sits in integrations, authentication, search, and commerce?
- Divergence — are you moving like-for-like, or reshaping the content model at the same time?
Any partner quoting you a faster migration should be able to answer all four about your platform specifically, and should be uncomfortable quoting a number before they can. If you would rather have those questions answered against your actual implementation than accept a generic percentage, that is what a Kentico migration assessment is for — it establishes where the repetitive work sits, what the tooling can genuinely take on, and what stays engineer-led.
For integrations, our Kentico team still treats target architecture as an engineering decision rather than a conversion task. Where the work extends past migration into broader Kentico platform engineering, that sits outside the migration workflow entirely.
FAQ
Does KentiCopilot cost extra?
No. It is open source and available on any Xperience by Kentico license tier. It is not a competitive advantage for any single partner — the relevant question is whether a partner has the Kentico depth to review what it produces.
Can AI reduce our Kentico migration cost?
It can reduce hours in specific stages — content auditing, custom transformations, repetitive code conversion. Those savings are partly offset by added review and do not extend to integrations, authentication, search, SEO, testing, or cutover.
Does AI-assisted migration mean we need fewer senior Kentico developers?
No. Senior time shifts from writing implementation code to reviewing generated code and making architectural decisions earlier. Mid-level engineers can carry more of the work; approval still requires Kentico-specific knowledge.
Our KX13 site runs on MVC 5. Does any of this apply?
Partly. The content audit and data migration read the database and are unaffected. Code migration is where the framework matters — Kentico's codebase migration skills assume ASP.NET Core, so an MVC 5 site pairs the platform migration with a framework modernization effort. Confirm current coverage against your specific implementation before relying on an AI-assisted estimate.
Can automated evaluation confirm the migration is correct?
No. It compares structure against the plan. It does not verify content correctness, integrations, business logic, or editor experience, and will still produce a report when some checks could not run. It is a gate before UAT, not a substitute.
Check other articles
Contact us
Before we proceed, please help us understand your needs better. We will review your application and schedule a free estimate call
You can also send us your request
CEO & Co-founder
