Support migrating KX13 page types to Reusable Content Types

[bluemodus-mwills]

Motivation

The Sitecore Migration Tool allows us to add configurations to specify which Page Types should be migrated as reusable content types instead of web channel content types. This capability would be great for the KX13 Migration Tool, because it would allow lots of non-page content to be migrated to the content hub. It would unclutter a customer’s web tree, and provide the great UX of the “content items” field, like the ability to create new items in the selector.

Proposed solution

Either allow configurations, like the Sitecore Migration Tool (reference)

Or, use a method similar to what is requested in #238. Allow custom code to be registered that allows extending how types are migrated from KX13 to XbyK.

[Sapphirress]

Hi Mike, we are considering how to solve this request. To help us, can you please clarify how this differs from your request #241?

[seangwright]

I think there are some conventions we could use for this request that would be simpler to deliver than #241 which requires a lot more flexibility.

We could map all Page Types where CMS_Class.ClassHasURL is false (0) to reusable content types.
These are "content-only page types" (page types with the URL feature disabled).

Since they aren't exposed as pages with URLs or impact the URLs of child pages, we could remove them from the page tree when migrated.

This would require we adjust the page tree if a content-only page has children pages with URLs by replacing them with folders.

---

As an example, in KX13 Dancing Goat the following Page Types could be converted to reusable content types in XbyK:

• About Us section
• Cafe
• Contact
• Footer navigation
• Home section
• Hot tips
• Reference
• Social link

SELECT classid
FROM CMS_Class
WHERE ClassName LIKE 'DancingGoat%' AND ClassHasURL = 0 AND ClassIsCoupledClass = 1

[bluemodus-mwills]

Hi @Sapphirress , regarding your question, this suggestion (#240) is much simpler than request #241. This request only requests being able to define a list of types that will be migrated as reusable content types instead of web channel types. It's just like this configuration option in the Sitecore Migration Tool kit.

In contrast, request #241 is for something much more powerful. Not only would it allow changing a page item to a web channel item, it would allow dramatic transformations of the content model during migration, including:

• Changing the name of a type during migration
• Mapping multiple source types to the same target type
• Mapping old fields to new fields (could be different field names, or even different field configurations)
• Omitting obsolete fields

Regarding @seangwright's suggestion, I agree that this request is for something much simpler, but I think configuration flexibility is needed if we want the option to be able to migrate customers as economically as possible. I often see legacy content models that use the tree hierarchy to define relationship, even for content that doesn't have URLs.

Although I'd love to optimize every content model, many customers need to feel like they could migrate to XbyK without a big investment. For some customers, we want to help them get through the migration without feeling burned.

A real-life example is a large Kentico customer who has lots of "Design Inspiration" content. The content provides summaries of inspirational design projects (clinic designs). Each design has a gallery of content items with images and is modeled in a tree like below. None of these content items are URL enabled.

• Design inspiration
  • Project
    • Gallery item
    • Gallery item
    • Gallery item
  • Project
    • Gallery item
    • Gallery item

There are different and even better ways to model this in XbyK, but there is a lot of this content, and for many customers it will be more important to get them migrated to XbyK without it hurting economically.

I can think of many other examples — even customers with a lot of accordions defined in a hierarchy.

[bluemodus-mwills]

This is solved by the new Migration Tool Extensions feature, which allows creating a custom class mapping extension, which allows mapping a source type and it's content to a target type. The target type can be a web channel type or a reusable content item type.

PR #257

Readme: https://github.com/Kentico/xperience-by-kentico-kentico-migration-tool/blob/feat/238_ability_to_extend_migration/Migration.Tool.Extensions/README.md