Upgrading to Sitecore 8? Thar be dragons!
By: Sitecore MVP Jason St-Cyr
Thinking of making the foray into Sitecore 8 upgrade territory? We’ll help you identify seven lurking dangers so you don’t fall into their traps on your journey forward:
In the days of yore, if you ventured off without a good map to your destination, you could encounter all manner of peril. Dangerous waters would be marked with some fearsome beast or a chilling script warning of impending doom. Were you to venture into the dark alone, you may have even been eaten by a grue! Sitecore MVP (and Upgrade Cartographer) Jason St-Cyr guides you to safety by mapping out 7 lurkers to steer clear of during your Sitecore 8 upgrade journey.
Lurker #1:
Web.config so big it may eat you
IIS has a default limit of 250KB for any config file it loads, including the Web.config file. The new Sitecore 8 Web.config file ships out of the box at a massive 241KB. Most solutions will start encountering the “Cannot read configuration file because it exceeds the maximum file size” error from IIS after an upgrade — especially if you have RewriteRules in your Web.config, as these tend to eat up disk space quickly.
To avoid this error, try breaking your custom sections out into separate configuration files and leaving the Sitecore 8 Web.config as clean as possible. 9KB gets eaten up pretty quickly!
Sitecore is aware of the issue and support tickets exist, so we should see this addressed in a future release.
Lurker #2:
Attack of the clones
Most everybody knows that Sitecore 8 introduced the concept of a new Final Renderings field to support versioned layouts. This is awesome and helps in many ways, unless you import clones to Sitecore 8 from an older version.
By default, since the field didn’t exist in older versions, the clone will have a null value. On a normal item, that’s great because all the layout is on the shared field and things work as normal. With clones, null means using the original value from the clone source. If you edit the clone source item, its final renderings will replace the presentation on your clone.
Lurker #3:
Deprecated rules and actions devouring the unwary
If you are upgrading from Sitecore 6.x, some system folders that used to exist in a “common” folder (/sitecore/system/Settings/Rules/Common) are now moved to an “Obsolete” location in the tree (/sitecore/system/Settings/Rules/Definitions/Obsolete/Common). This actually happened in Sitecore 7, along with a fairly large restructuring of this area of the tree. Some solutions have their customized rules in this deprecated location, so you need to be wary when importing from an older database, especially when deserializing is your migration method.
The folders do have the same GUIDs, so if you placed some of your own custom rules in those folders you should be able to locate the mapped folder location easily enough. If you are importing that content make sure you push to the correct location, or find a new location for your rules.
Lurker #4:
Encoded media URLs from outer space
This is another fun one that was introduced in Sitecore 7, so only affects you if you are upgrading from version 6.x. The way that media items are resolved from a URL has been corrected in Sitecore 7 and up to work the same way as regular content item resolving. Unfortunately, this may break some of your media links if you are encoding spaces in URLs to hyphens.
The issue is that if you are encoding spaces to hyphens, your solution may depend on the old resolving method in which parent items could have spaces or hyphens in the same path.
For example: /Files/Media Folder/Media-Item. This no longer works! The paths must be consistent (spaces, or hyphens, not a mix).
See here for details and fixes.
Lurker #5:
The roles that sank ships
Importing roles using serialization from another database needs to be done with care. Between Sitecore 6.6 and Sitecore 8, several new roles were introduced into the system. Existing role definitions have also changed in that they may inherit from new parent roles.
If you do plan on migrating your roles definitions, I advise serializing both the clean Sitecore 8 roles and your solution role definitions to the file system using the Role Manager tool. At this point, use a file comparison tool such as Beyond Compare, KDiff, WinDIFF, DiffMerge, etc. to create a merged set of role definitions. Then import the merged set using the Role Manager.
Lurker #6:
The creature from the IQueryable lagoon
For those making the jump from Sitecore 6.x up to Sitecore 8 you will encounter the same hurdle faced by those who made the jump to Sitecore 7: the new Sitecore.ContentSearch namespace. The way that indexing and content search works now is very different and much better than the predecessor, but it does mean that you will need to update your code to work with the new model. You will need to plan for changing this code and adding new configurations to re-create your indexes. This article is great for getting started with the new search namespace.
Lurker #7:
Rise of the Modules
With any version upgrade you should be checking your modules to ensure compatibility, but Sitecore 8 in particular will make this a necessity. Many marketplace modules have not been updated for Sitecore 8 and some modules are now replaced by OOTB functionality (for example, Experience Explorer and FXM). Before upgrading, determine if you are actually using a module. If not, just remove it. If you are using it, determine what functionality the module is providing for you and consult with your Sitecore partner to see if Sitecore 8 or an alternate module can bring you the same functionality.
