Rethinking Sitecore Upgrades: The Art and Science of Content Migration

Content migration between the environments and versions can be a challenge for every Sitecore upgrade, a challenge that requires a creative approach. This blog post describes our strategy to migrate content from Sitecore 9 to Sitecore 10.1. 

When it comes to the migration of Sitecore’s items, the most popular strategies are: 

• Restore of the database 
• Migration with the packages 
• Usage of tools like RAZL 

It is easy when we are only on-site to migrate, but what happens when we have to migrate 150 sites with different language versions, and you can’t have a content freeze?  

Toolset choice 

As you may know, Sitecore, since version 10.1 supports item resource files with the items required by Sitecore now stored on disk.  Our Sitecore 9 instance had all the items stored in the databases, with the additional risk that some were modified.   

We could not start migration without brainstorming the available options and their pros and cons, as we knew we could not just use one of the well-known tools. Considering there is no content freeze and 150 sites, we had to be more agile. 

Finally, we decided that to keep control, we would have to migrate sites individually. We can start with a clean database to tidy up unused data. To migrate each site, we would use serialization for templates, renders, etc., and then use Sitecore PowerShell to sync the data.  

The Process 

This is what the standard migration process using Sitecore packages looks like: 

 
It would be the perfect solution for a single website, but with 150 sites that can be changed by content editors at any time, we had to add something to the process.  

Our solution was a PowerShell script connecting to the Sitecore 9 production database. This would compare and update the data in Sitecore 10 database. Thanks to PowerShell, we could quickly compare parts of the content tree for changes and migrate those. 

 
Unfortunately, we had to disable the ‘migration’ script after some time as we found a bug inside Sitecore PowerShell Extensions that is still unresolved (1st August 2023). SPE’s Get-Item method has an issue with correctly resolving the checkbox fields when the value is inherited from other items. Even when the script could no longer migrate items, it was still a very important tool for us as we could verify if the content we installed with the packages was still valid or outdated.   

At this point, it is worth mentioning the security steps we have taken to be sure that our PowerShell script will not influence the data stored on the Sitecore 9 production servers.  

SPE is an immensely powerful tool and, within seconds, can make many changes that could affect the data integrity of your solution. For this reason, we: 

• Defined Sitecore 9 master database as an additional Sitecore 10 database (to avoid a direct connection to the database and to use Sitecore libraries to run the data operations) 
• Created a new “read-only” database user on the Sitecore 9 SQL Server that could connect only to the Sitecore 9 master database. This ensured that we could not change any of the values on the Sitecore 9 database. NB: This creates many error messages in the Sitecore logs because Sitecore can’t write to this database. 

We also had to deal with environment-specific configurations stored at the item level during the content migration. For example, we had to migrate forms that were using different identifiers to integrate with third-party software, which was dependent on the environment, e.g., production, stage, QA. 

Because the old test environments very often were outdated or even were not working correctly, we had to build a process that helped us to go as fast as possible through all the forms without involving too many people in the communication – at the end of the day, all the steps were very repeatable. 

From the time perspective, the most crucial part was the customer’s team verification at the second step. As Konabos was not the data owner, it would be impossible to quickly identify issues and fix them without involving many people, drastically increasing needed time and resources.  

With a process like the one presented – everyone after the discovery phase had a list of identified places that must be checked before migration and could work independently. In this case, we also had to handle people working in different time zones – a lack of process would lead us to delays because we would be waiting for answers from people unavailable until the next day. 

As you can see, something as simple as migrating items with Sitecore packages may become a complex process involving many people when we add a scale as a factor. 

Thanks to the processes we built and great cooperation with the customer, we could migrate so many sites without any content freeze. We hope that the ideas we share in this article will also help you in the future.