Installing Sitecore 9 on your local dev machine took some work, but you managed to do it. Now it's time to upgrade your actual servers and solution. Here are some common issues you can run into when upgrading to Sitecore 9:
Upgrading the Code Base
Your origin version of Sitecore will determine the amount of work you need to do. The earlier the version, the harder it is. For this blog, we'll cover an 8.0 to 9.0 upgrade as an example.
- From 8.0 to 8.1, Sitecore added their own dependency injection framework. Make sure the one you are using is compatible with this, especially if you were relying on Controller Factory
- From 8.2 to 9.0, Sitecore totally reworked analytics with xConnect. This means if you had any custom analytics code, whole namespaces and pipelines have changed.
- Beyond the large items, as long as you update the references to Sitecore 9, the compiler will catch most changes you need to make
Adding New Infrastructure
- Sitecore 9 will likely introduce 2 infrastructure requirements, especially in production environments: xConnect, and SOLR, if you are not already using it
- xConnect is separate web service that handles everything xDB did in Sitecore 8. In can be split into 5 components, with many roles similar to what came before (e.g. Aggregation, Marketing Automation)
- SOLR is now required for xConnect (or Azure search if you're on Sitecore PaaS). In addition, SOLR needs to be set up with SSL. If you are already using SOLR, you will have to upgrade it to the exact version that Sitecore 9 supports. As of Sitecore 9.0.1, this is SOLR 6.6.2 or 6.6.3
- Sitecore also requires SQL Server 2016 now, as xConnect now uses SQL instead of MongoDB for analytics data
- The Sitecore 9 Installation Guide will have a list of prerequisites you need for their powershell install script to work (Powershell 5.1, SIF, etc.)
- However, there are also other prerequisites not listed that are needed. SQLCMD is used by the installation, but not installed by default on most servers. You will need to install it and the ODBC driver, as outlined here: https://sitecore.stackexchange.com/questions/10216/sqlcmd-is-not-recognized-at-createshardapplicationdatabaseserverloginsqlcmd-st
SSL Certificates and Connectivity
- A big requirements of Sitecore is that both SOLR and xConnect require SSL. Make sure you are either using real certificates, or adding self-signed certificates to trust for every server that needs to talk to each other. All Sitecore servers (CD, CM, xConnect) will need to talk to SOLR. CD and CM will need to access xConnect.
- Sitecore's installation script uses a powershell command called MakeCert with parameters that only work on Windows Server 2016 and up. If you are installing SC9 on a Server 2012 R2 environment, you will have to create these certs on a different machine (Windows 10 also works), and then import them to the server.
Upgrading the Actual Sitecore Instances
Depending on your origin version and environment, you have a few options
- If you are on Sitecore 8.2, the normal UpdateInstallationWizard is a good option to update your CM instance after you install all the prerequisities. You can then do a WinMerge on your CD instance compared to basic Sitecore configs, and then rebuild the CD instance from there.
- If you are on 8.0 and older, or even 8.1, a lift and shift might be the best option. This is accomplished by installing a clean instance of Sitecore 9 in parallel, and then migrating the data and analytics over.
- In a lift and shift, you can use Sitecore's Express Migration Tool to move over data from your old instance to your new one. If your solution is simple enough, you can even create a Sitecore package.
Migrating Analytics Data
- xConnect has replaced xDB, and SQL has replaced MongoDB. This requires that data from xDB be migrated to the new infrastructure.
- If you are coming from Sitecore 8.0, you will need to run the HashStoredIPs tool first (part of the upgrade form 8.0 to 8.1). You can then run the xDB migration tool for 8.1 and up data
- Keep in mind if you have years of data on production, you can be looking at gigabytes of data migration. Be sure to take the appropriate precautions, like preventing regular app pool recycles, as the process can take days. If possible, discuss trimming the MongoDB data, or not importing it at all if it's not used