The more mature Xperience by Kentico product becomes, the more often I hear "How can we migrate there?”. Why do I think I know the answer?
- I have moved flats or houses 8 times in my life
- And 3 times I’ve even changed countries to live
Which makes me... A migration expert! Or maybe because I’m one of the authors of Sitecore Migration Tool for Xperience by Kentico? It's up to you to decide!
Anyway, let's return to our topic. Why do we call this a migration? When everyone knows it’s going to be a rebuild, right?
Look at this picture: is this a rebuild? Or is this a migration?
There is no right or wrong answer here. It all depends on how we define “the thing on the left”, and “the thing on the right”.
A long time ago, “the thing on the left” was nothing but a bunch of printed materials, Excel spreadsheets, and documents. We were creating new sites on Kentico from zero digital history - it was just a build with nothing to migrate.
In recent times, most of the clients approached us with ugly websites already and asked us to rebuild them nice and shiny on the Kentico platform. This was a good “rebuild everything” era, where in the worst-case scenario we had to migrate only some pieces of content from the previous site.
But now the situation has changed and businesses already have good enough websites that they simply want to improve. And since “that thing on the left” could be a more sophisticated DXP, there are more things to consider while migrating.
When we know that DXP is not as simple as CMS, then DXP migration is more than just a content migration.
Of course, content and website code are still the biggest parts to migrate. But there are also things like users, tracking, personalization, email marketing, automation, A/B tests, and e-commerce that should not be missed.
Content migration
Every content migration guide (and Kentico documentation is not an exception here) tells you to run a content audit first. But what does that mean exactly? It could be as simple as putting your content in one of these 4 buckets with the idea of migrating only important and easy bits.
- Not so important or relevant, but easy to migrate. It could be outdated news or events stored in a structured format.
- Not important and hard to migrate. Usually, these would be landing pages built heavily using widgets and components and not utilizing structured content at all.
- Important and relevant, but hard to migrate. These are your most popular and most important landing pages that were built using components. This is going to be your headache for migration.
- Important, relevant, and structured. Easy to migrate. The thing we like the most and should be focusing on. Most commonly are product, category, service, or article details pages.
And actually, this was exactly what I did before migrating to another country! There is always something easy to pack – documents, money, pets, and… your partner, of course. Cars and furniture are important but hard to take with you. Clothes, books and board games are still kind of important and if you have some spare room in your bag, you can take them. And finally something like heavy equipment you just ignore and forget. It’s easier to buy new.
One other thing I learned along the way - it doesn’t have to be all in one go, and my board games met me a few months later via the post. The same can be done with content migration - you can prioritize and phase it in batches.
There is another exercise helping you identify the content worth automatic migration. Let’s build a funnel! Marketing people like funnels, aren’t they?
- list all content in all languages
- then quickly check the amount of it – a rule of thumb it is worth automating migration if there are at least a hundred pages of a particular type
- next, check whether this content is still relevant and important. Maybe now is the time to forget it and let it rest in peace with the old site
- finally, even if it is important, the previous implementation could contain some major mistakes in the content model that you wouldn’t want to bring to Xperience by Kentico
When you finally have a list of content to migrate, Kentico gives you a few options for tools:
- Kentico Migration Tool
- Sitecore Migration Tool
- Sitefinity Migration Tool
- For everything else that doesn’t fit the three options above - Universal Migration Tool.
Website code migration
Code is the next important part of the migration journey. Make sure you have enough space in your migration “bag” for it.
In terms of the backend code, domain logic, integrations, and scheduled tasks are things that are not so hard to migrate. Usually, this code would not wildly change, even if you migrate it from an old .NET Framework version to .NET Core. Migrating from other languages than C# though may be much more challenging and wouldn’t make much sense.
Harder bits are the backend code supporting rendering of layouts, templates, and components – mainly because different platforms have wildly different APIs for accessing this data from the database storage.
For the frontend code migration, we can choose between these three paths:
- Migrate ‘as is’ when we are dealing with an extremely tight budget
- Allow some extra time for addressing the existing technical dept, refactoring, and solving some issues
- Or the option that we all like the most - a full re-design and frontend rebuild.
Members migration
Moving on to the next topic – frontend users, or members, migration. Very often I see this part missing in the migration plan. However, if you don’t have members on your website – doing nothing IS your plan!
But if you do have them, the worst thing would be implementing a new registration process and not migrating the existing users. Trust me, the day when you release a new site and ask all your customers to re-register again will be the unhappiest day of your life! So, at the very least make sure to migrate user profiles. If you are limited on budget you can simplify this and ask users to reset their passwords in the mass-email. Customers would still not be very happy, but this option provides at least acceptable UX. Unless you ask for the password reset every other week ;)
The best-in-class solution here would be to implement a seamless migration without asking for a password reset. this is doable but has some technical complications and therefore is more expensive. Make sure to consult with your technical team on this topic!
Usually, member profiles have a variety of information stored:
Basic information as simple data fields like:
Name
Email
Birthdate, etc.Complex profile data like:
Favorites
Collections
Order history
Preferences, notifications, etc.
Make sure to figure out how these things are stored in the existing system to allow for smooth migration.
I also recommend considering SSO integration at this stage. This is a perfect time to introduce it during the migration project because you are going to migrate member profiles anyway. In this case, you can move basic profile info into an SSO system like Azure Active Directory B2C, Auth0, or Okta. And the extended profile information can go into Xperience by Kentico storage. Then you can simply connect your XbyK to SSO following the documentation - and the job is done!
Tracking and personalization migration
The next step is tracking and personalization. In what cases should you consider migrating it? Basically, when you have a large known contacts base and the interaction history is important in your website UX.
For example, when you submit a form, this should change your further user journey based on your activity. This is also important for returning visitors to provide consistent UX for them.
How to migrate this data? Most of the systems allow some sort of exporting it. At this stage I would recommend focusing on important domain activities, like form submissions, searches, specific downloads and so on. But you can skip migrating page visits because mapping page visits from the previous platform onto the new one especially when your URLs might not match will be a nightmare to manage.
Hopefully, migrating tracking and contacts data will also be supported by migration tools in the short future.
For example, this is how migrating tracking data from Sitecore can be approached. In Sitecore world, this data storage is called xDB and it contains contacts, sessions, and interactions. This information can be exposed by xConnect service which talks to xDB and it also has a public API to query the data in JSON format and then it can be imported into XbyK by SQL script.
Marketing automation migration
Now let’s talk about Marketing automation. If you haven’t heard of this yet – XbyK comes with simple automation out of the box already. If your requirements are as simple as sending emails upon form submission or user registration – go ahead and use it. But bear in mind that it is not possible to migrate this automatically and I don’t think it will ever be. Most of the time the marketing automation “migration” processes would look like simply implementing it in XbyK from scratch.
In case you require more sophisticated scenarios please integrate with Zapier. XbyK has a native integration package that will give you custom triggers, but the automation process itself you would need to configure in Zapier.
A/B and MV tests migration
Next. A/B tests. Oops, this is where our plan may fail a little bit as XbyK doesn’t have native A/B testing as of yet. The easiest recommendation would be to integrate a third-party tool like VWO. Check the documentation to learn more about how to integrate it.
However, in general, you should not be migrating any running tests. It would be a strange idea. Please finish and conclude the existing tests, migrate the code and content only for winning variants, and start creating new tests in VWO directly.
E-commerce migration
And last but not the least – e-commerce. When you are migrating existing Kentico Xperience 13 solutions to Xperience by Kentico you can integrate it as a headless shop. But for all other cases, it is better to integrate with Shopify until we have a native e-commerce in XbyK.
Just looking at Sitecore example again. The product in their ecosystem is called Sitecore Commerce, and it contains product pages and SKUs. Also, many other aspects of e-shops like discounts, taxes, delivery and more, but those things will be hard to migrate.
What’s possible to migrate is product information. Pages can be migrated via the migration tool like any other content, then SKUs can be exported in a format compatible with Shopify. If we did everything right, after installing the integration SKUs and product pages should be matching by identifiers.
Conclusion
Hopefully, this top-level guide provides some useful thoughts for your future migrations to Xperience by Kentico. As a conclusion, I want to mention it one more time - DXP migration is not going to be as simple as just content migration. But don’t panic! Remember the key building blocks and happy migrations everyone!
Author: Dmitry Bastron
Top comments (0)