Dealing with 'page links' during migration

Hey there,

We are working on a couple of e-commerce websites migration from KX13 to XbyK and found one interesting challenge worth asking about: how do you deal with page links in the CMS tree? Very often KX13 sites with e-comm have this approach explained in this doc - Linking existing products.

Linked pages do not exist in XbyK so how do you go around this? We have tried a couple of options like modeling products mostly in content hub and keeping product page just a shell so that for the very same product you can have multiple pages linking it. But that requires customizing the way pages get indexed in search, appear in sitemap, canonical URL - all these typical SEO challenges. I wonder if someone had a better way of approaching this?

Tags:
Digital commerce Migration / upgrade

Answers

This is what I did because we had links going back to the migration BEFORE the migration to deal with.

Create a Migration_Pages table that contain 1 row for each ACTUAL page (like the NodeGuid type of thing), with info on the cannon URL and any new Url. Also create a linking table Migration_PageAlias that has the PageID and the alias. Then load all of this up from the old Kentico tables. You optionally can do the same for Files and Attachments.

As you migrate, start filling in the NEW urls, so you have a record of what pages have or haven't been migrated.

In your 404 handler controller, grab these pages (with aliases) into a dictionary of Old url to New Url, and if you find it, then redirect. I added this to a Cache method with a shared Cache Name that was in an early pipeline (where the early version would return nothing and NOT cache, where was the 404 would return something AND cache if found). This allowed me to offload the lookup logic to the 404 handler, but still be able to get an instant 'find' early on to redirect.

Let me know if you want to do a deeper dive! It worked out VERY well.

To response this discussion, you have to login first.