Experience with the Kentico Migration Tool
I'm interested in hearing from others who have used the Kentico Migration Tool on their projects, particularly regarding the migration of content (page types, pages, widgets, media). I'd appreciate insights on your experiences, challenges faced, and strategies employed.
To give you my background quickly, I've been working with Kentico since version 5.5 and in recent months I obtained Xperience by Kentico certifications in Content Modeling and as a Certified Developer. While I'm a full-stack developer rather than a dedicated .NET or C# specialist, I have substantial experience with the platform but may be missing some knowledge and context especially regarding the Migration tool.
My first encounter with the migration tool was about a year ago on a project where I evaluated it and discovered a blocker bug, which raised an initial red flag. After reviewing the documentation, I anticipated some challenges ahead. For that project, I decided to implement my own migration approach, which proved straightforward and resulted in a successful delivery that followed XbyK's best practices. For reference, I documented the project development on my blog.
Since then, I've been peripherally involved with two other projects that utilized the Migration Tool, where the feedback wasn't particularly positive, though I didn't have access to detailed information.
Now, a year later, I'm re-evaluating the Migration Tool on a KX13 project. After investing 10+ hours, I'm leaning toward my previous custom approach rather than using the official tool. While the tool works well for straightforward 1:1 migrations, attempting to customize the content model quickly became challenging, even with only basic customizations.
One of the more interesting observations is the gap between Kentico's current content modeling best practices and what's practically achievable through the migration tool. While XbyK advocates specific modeling approaches, the migration tool doesn't fully support transforming legacy content models to align with these recommendations.
Another observation is that it doesn't seem possible to migrate only a specific page subtree (such as a blog section with many post pages that need to be migrated automatically), while rebuilding the rest of the pages manually or using results from previous runs of the migration tool. As a result, you're forced to apply migration tool customizations across the entire site structure, rather than isolating or limiting them to specific sections.
Has anyone else encountered similar situations? Have you found effective strategies to overcome these challenges? Or is my experience different from others using the migration tool? Also, feel free to share your experience going beyond content migration.
Answers
It is complicated but so powerful. Part of the reason it’s complicated is that migrations and content model transformations are complicated.
We’ve done a few migrations using the K13 Migration Tool, and the result was an XbyK-optimized content model, *but* there are cases where we chose to do something more custom and used the Universal Migration Tool.
The K13 Migration tool works great when the K13 project has a decent content model because it needs to migrate everything, to manage parent-child relationships and other content linking. However, we transform the model *every time* using mapping classes and other extension points.
It allows us to do things like:
Redefining types to use shared reusable schemas
Mapping multiple types to one type
Mapping custom selector fields to native XbyK selectors
Controlling what’s migrated as reusable content
Migrating categories to taxonomy
Transforming page builder configurations (This even allowed us to map configurations from a huge set of K13 widgets to a consolidated set of XbyK widgets.)
Transforming tree hierarchies into linked content
It would take a lot of work to handle all of this from scratch, but it is still not easy.
Some of the things that make it easier is having a few people become well-practiced experts at using the tool, and auto-generating mapping classes based on definitions in a spreadsheet.
Sometimes it isn’t the right tool. For example, we're migrating content for a site that looks like it originated as a Portal Engine site. Each page is made up of deep hierarchies of nodes, where there is a node representing every container and element on a page (e.g. Page content, section, column, content block, etc). Even the blogs are constructed this way.
For that project, we're going to query the K13 database directly for all the blog nodes, with titles, URLs, and metadata, and then create ContentItemSimplifiedModel objects for each blog. Before feeding each object into the UMT, we’ll scrape the legacy blog body and add it to the simplified model.
The UMT works really well. We used it with the Sitecore Migration Tool and before feeding each exported content item, we were able to map each item to a new model *before* feeding it to the UMT. We ignored all the types exported from Sitecore and were able to migrate all the content into an XbyK-optimized content model using taxonomy, reusable schemas, and reusable content.
So, I agree it’s complicated—I’m still getting used to delegate-based extensions—but the payoff is pretty good. It’s powerful and handles a lot of challenging things for us.
To answer this question, you have to login first.