Welcome to Part 2 of my Mini-Series on Sitecore Upgrades. This blog post is entirely dedicated to tips surrounding what you need to do to upgrade your databases to account for all the new modifications that come with a newer version of Sitecore. Heed these tips carefully. They may save you a lifetime of stress and agony.
Where to find the upgrade steps
Sitecore provides documentation on how to upgrade to each version. Simply navigate to the Sitecore Downloads page for the version you are upgrading to. For example, the instructions for upgrading to Sitecore 9.3 can be found here.
It is important to note that you do not go to the Sitecore Downloads page for the current version of Sitecore you are on to find the right database upgrade instructions.
Jumping multiple versions
The more versions of Sitecore you upgrade past, the more likely you’ll have to perform multiple database upgrades. Sometimes you will not. It’s highly dependent upon which version you are coming from and which version you are going to. For example, if you are upgrading from Sitecore 8.1.3 to Sitecore 9.2, you’ll only have to jump through one hoop to upgrade your databases. One set of instructions. It’s a straight shot.
Upgrading from Sitecore 7.1 to Sitecore 10? You won’t be so lucky. You will have to upgrade to some intermediate version between the two versions to get all the way to Sitecore 10. This means following one set of instructions to get to the intermediate version, and then following another set of instructions to get to 10. The database upgrade steps provided by Sitecore will tell you at the very beginning what versions you can upgrade from in a single shot to the version whose instructions you downloaded.
Do a dry run
I do not recommend trying to walk through the upgrade steps on databases that contain custom Sitecore data. I recommend installing a fresh Sitecore instance on the version you are currently on. Then run through all of the upgrade steps to see that you are following all the necessary steps. Having no custom data in your fresh instance will eliminate the possibility that some piece of custom content is interfering with the upgrade instead of you missing a step.
I like to write down the exact steps I take in a separate word doc to keep track of what I do on this dry run. The upgrade instructions are well-written and easy to digest. However, they have to provide instructions for upgrading databases in multiple environments instead of just on your local machine. This makes the instructions have branching paths much like a choose-your-own-adventure novel. Writing down your steps makes it so you do not have to think about which branching path to take the second time through.
The custom data problem
Do not do in-place upgrades. I cannot stress this enough. If you are going to ignore this wisdom, at least do not do in-place upgrades in your production environment. If you mess up an in-place upgrade in your production environment, your site will be down. The longer your site is down, the longer you lose revenue and become more likely to lose loyal customers. I recommend standing up separate servers and databases specifically for upgrading. After the upgrade is complete, flip the switch and point all internet traffic to your new servers. This begs the question. How do you get your custom-curated content onto the upgraded databases. I recommend two routes you can take to solving this problem depending on your situation.
In both routes, you do not need to worry about upgrading the CD database(s). We will be concerned with getting the content to the CM database. After that, you can simply publish to a fresh instance(s) of your CD database(s).
Route 1 – Moving content via packages and Sitecore Sidekick
I only recommend route 1 if major development for the site has been completed for quite sometime. In your currently live production CM database, create packages of custom template, system, and layout items using Sitecore’s Package Designer. Then install this data onto a fresh CM database for the version you are upgrading to. After that, install Sitecore Sidekick on both CMs. If you are unfamiliar with this tool, it allows you to move Sitecore items found under the content, media library, and marketing control panel nodes in the content tree easily between different environments.
When the time comes to do the official switch over to the upgraded version, you will need to enforce a content freeze for your content authors. You will then use Sitecore Sidekick to migrate over all the custom content. After that, you will perform a publish to get all this custom data over to CD database(s). Fair warning: this could take a while depending on how much content has been created.
Route 2 – Upgrading a back-up fully in a separate instance
I recommend route 2 if you are performing an upgrade on a site mid-development. Essentially, you will create a database back-up and run through all of the upgrade instructions on a separate server from the currently active server. During this time, you will need to enforce a content freeze. This will prevent any new templates being created by developers mid-upgrade from getting lost post-upgrade. If you do not enforce a content freeze for whatever reason, you will need to use Sitecore Sidekick or Sitecore Package Designer to get content author content over from the old server.
The advantage this route has over the other is that the upgrade is done in one fell swoop. You are not moving over templates, layouts, etc in a piecemeal fashion. The first route is more prone to human error if someone forgot to package up some piece of custom content that is in use.
Miscellaneous Tips
- SQL Server is backwards compatible. When performing your dry run, do not use the SQL Server version that is compatible with the old version you are upgrading from. You need to be using the SQL Server version that is compatible with the version you are upgrading to! The update package will not successfully install if you fail to do this.
- You need SSMS version 18 or newer to work with pulling and deploying Azure databases. Older versions do not support deploying Azure databases.
- Install Sitecore to a VERY short file path. For example, install it to C:\S. I am talking very short. The update package will need to get through all of the content in your Sitecore instance and if the file path has too many characters, it will error out.
