Reading time: 8 min read
Start typing to search...
At Fishtank we've done a lot of Sitecore upgrades and have learned a lot of lessons. There are obviously things like updating .NET versions, updating your Sitecore libraries with new versions and getting everything the build. But when you're doing a Sitecore Upgrade, there are some many things to be aware to plan your project successfully. And we've done many upgrades for large enterprise instances with hundreds-of-thousands of items, and they teach you things.
This obviously isn't a definitive list but it's a chunk of things you should consider when planning your Sitecore upgrade.
For the real list, just work with us. 😇
In Sitecore there are language cultures installed at the OS level that underpin and languages cultures in Sitecore. These are leveraged for translation and more specifically localization in Sitecore.
Canada is officially a bi-lingual country speaking French and English with the language culture codes of en-ca and fr-ca commonly used. If we wanted a localized version of Spanish in Canada, we would duplicate, modify and install an existing language culture and create es-ca.
This can be quite common in Sitecore instances, especially when creating English versions of content in non-English speaking countries. You may have en-br for English language content for a site in Brazil.
While this is generally something to be aware, of the problem here is that Azure App Services (which are the backbone of Sitecore Azure PaaS) do not support custom language cultures. As your friend, please don't even try.🙂
If you're leveraging containers, you'll need to customize your dockerfile to install the appropriate custom cultures.
If you're doing a Sitecore IaaS install, the custom cultures must be re-installed. If you're using XM Cloud, I would suggest contacting Sitecore Support for some help with the customization.
Be sure to itemize and track all integrations points from existing Sitecore environment. If you upgrade into new infrastructure, you'll likely have to whitelist and grant exceptions to integration points across your Sitecore instance. Especially if the network or infrastructure team is separate from Sitecore team, you're bound to hit a snag.
Across Sitecore 8.x to 9.x you could use Lucene, Solr or Azure Search to handle Sitecore's indexing. When using Sitecore 10.x your instance will need to migrated to use Solr.
This migration includes:
If you're migrating from Azure Search to Solr, you can expect some challenges as the format of the configurations and even how the indexing technologies work are different.
You will also want to decide how you want to manage your Solr indexing:
If you're upgrading from Sitecore 8, you should be aware of the change in config management in Sitecore - Role Configurations.
In Sitecore 8 and before, solution builds would typically transforms configuration per destination / environment to account for settings that are different.
In Sitecore 9.x, environments and custom variables are supported which allow you have a single config file, where Sitecore dynamically includes only the configuration elements specified.
The supported configuration environments are:
You can also use custom variables to further control which configs and rendered where.
Coveo for Sitecore 5 only supports search pages developed using the Coveo for Sitecore Hive Framework. This framework still leverages Coveo's famous JSUI, but it does not leverage MVC or WebForm components in creating the new pages. Your old renderings are no good here.
If your current Sitecore instance uses Coveo for Sitecore 3 you'll have to re-develop your search pages. If you are using Coveo for Sitecore 4 you may already be using the Hive Framework. If you are not, your search pages will need to be re-developed.
On older versions of Sitecore, user had their accounts and roles synced into Sitecore from Active Directory. As of Sitecore 10 (and even 9), the Identity Server was introduced that acts as a single point of authentication for multiple sources.
There is out of the box support for Azure AD integration which replaces the legacy LDAP-based Active Directory sync with a federated Azure AD SSO.
Be careful of untracked changes in the Core database. Every Sitecore customization stored in the Core database should be itemized prior to migration.
Typically during an upgrade, you can follow the steps provided by Sitecore and upgrade the Core database. This is ideal because all customizations will be kept in place. While you can assume they're still in place, itemizing is still helpful to verify that everything still works post-upgrade.
If you're upgrading to a Sitecore XM Cloud instance, you'll need to re-apply your changes as you won't be able to upgrade your existing database and simply restore it (I don't think!).
Sitecore provides tools for upgrading and migrating analytics data. But realistically, you should evaluate if this should be included as part of your upgrade project. Consider the following:
If your Sitecore instance does not have a workflow in place, it can be very problematic when migrating content into your new Sitecore environment.
Without workflow, content that is in progress will inevitably get published during the upgrade process. With enough code and clever thought, there are potential ways around this but no solutions are as good as getting a proper workflow in place prior to the upgrade.
During the upgrade process, you'll need to refresh your databases with content that has changed in production since the upgrade process began. Depending on the complexity of the project and the amount of changed content, multiple content syncs may need to be performed. This sync process should not be an issue unless you have massive amounts of content and / or have no workflow (as mentioned elsewhere).
All media needs to be converted to blob-based storage to be migrated into Sitecore 9.3, 10.x and up. Having media stored on the file system does not make much sense, frankly. You can use a Sitecore PowerShell script to target the offending images, download them and reattached them as blobs to existing media items.
When upgrading from Sitecore 8, you'll need to run a Sitecore PowerShell script against your presentation details to update the placeholder values in your renderings. The format produced by the dynamic placeholders have changed from the community-driven effort used in Sitecore 8 to the version officially supported by Sitecore in version 9, 10 and up.
If by any chance Web Forms for Marketers was used in your Sitecore 8 (or earlier) instance, those forms will need to be replaced. There is no upgrade path for them as WFFM is deprecated. If you're moving to Sitecore 9 or Sitecore 10 you can use the native / out-of-the-box Sitecore Forms functionality.
You may also want to use the opportunity to replace existing custom forms on your site with Sitecore Forms.
Life is a party, but your Sitecore instance should not be. When it was created, by definition, the development team either used modules that were compatible or really dug their heels in and forced them to work together. Just because they worked together then, does not mean they work together now.
Say if you are using a random sampling of:
They may not all support the same Sitecore versions at the same time. Or have the same recommended methodology when upgrading (one wants you to upgrade the module, then Sitecore. Another wants you to upgrade Sitecore then install the latest version).
On truly massive amounts of content - when languages-times-content is getting you in the high 100,000s of items - Sitecore PowerShell scripts that churn through the content will eventually, quietly, fail. Like-wise, using packages or other conventional means to move massive amounts of content will also fail. You really must think smart and plan your migration / update scripts to run as a series of tracked, targeted processes vs a single process against the root.
This will take more time, more oversight and more discipline but its the only way to have predictable results.
To take advantage of Sitecore XM Cloud, your Sitecore website needs to built using Sitecore's Headless Services. If you're on Sitecore 8 - you'll be out of luck. If you're using Sitecore 9.x or Sitecore 10.x your dev team will be able to tell you if you're using Headless Services (Formerly JSS).
By percentages, most Sitecore sites will not be leveraging Headless Services and you'll need to rework your existing components as step 1 before moving to Sitecore XM Cloud. This type of project has lots of long term value, but will be more involved than a traditional Sitecore Upgrade so be sure to plan accordingly.
Forgive me - but the easiest way to get your Sitecore upgraded to the latest version is just to give Fishtank a call. We've nearly seen it all and have incredibly deep experience at handling Sitecore Upgrades. It's also worth considering if you really need a Sitecore upgrade or there is more of a roadmap to put in place that can get you more value with less long-term spend. With Sitecore's new products like Content Hub, Personalize & CDP - there are a lot of compelling things we can accomplish without upgrading.
Regardless, I hope you found this article useful. The best of luck with your Sitecore upgrade. Feel free to reach out via our contact page or email us at [email protected].
