I'm sure if you're reading this, then you're already familiar with the pain points in a Sitecore upgrade. If you know it'll be a big job but don't know why, I highly recommend checking out my post all about it. Once you know of the potential issues, it's a good idea to start looking for ways to minimize them before you even begin an upgrade process. Here are some ideas on how to do just that.

• Get your testing plan in place
• Clean your content house
• Prep your solution
• Take a hard look at your analytics data

Doing these things ahead of time can greatly cut down on the work necessary for an upgrade and will likely result in a cheaper, smoother project.

Get Your Testing Plan in Place

I'm sure since you're a professional with a sophisticated website that you've got a robust DevOps regime in place that includes thorough, automated regression testing at every phase. No? Well, you're far from alone. I've seen Sitecore implementations that do have these things, but for everyone one of those, I've also seen a solution where a deployment consists of "ask a sysadmin to copy some files to the server". The reality is that your implementation is likely somewhere between these two extremes.

A robust DevOps regime is important for a project team to ensure the quality and stability of a website, but it's also often viewed as a luxury. This goes double for proper regression testing, which often takes the form of a site owner pulling up the homepage and saying, "Looks Good, the site's up.". This level of testing isn't sufficient when performing an upgrade.

Because of the way upgrades are performed and because of the complex nature of Sitecore solutions, it's important that a site owner has the ability to verify that all of the important functionality of a site is indeed functional. Ideally, this would be automated through a tool like Selenium, but in the absence of an automated solution, there should at least be a collection of manual testing scripts to be followed.

The test scripts you create should include all critical aspects of a site's functionality, especially things that are not readily apparent. It's easy to know if a site's navigation isn't working properly, but it's far harder to tell if your analytics tagging is properly flowing correctly. You want to ensure your script includes testing for those "invisible" failures that wreak serious havoc that isn't immediately discovered.

We generally include creating thorough test scripts and the means to execute them in our upgrade projects. If you've already got them, then your upgrade process will be much quicker (and therefore cheaper), and they're easy enough to get started creating well before upgrade time.

[On Demand Webinar] Automate Away the Pain of a Sitecore Upgrade

Join 6x Sitecore MVP Ed Kapuscinski to learn what makes Sitecore upgrades so painful and how Sitecore Elevator leverages the power of automation to cut out 50% of the pain of a Sitecore upgrade.

Register now

Clean Your Content House

I'm a digital packrat. I don't know how much of my hard drive is full of notes I took from meetings from ten years ago, but I'm sure it's a significant portion. I know many Sitecore customers are too. After all, it's easy enough to keep old content floating around in your content tree by marking it as "Do not publish". This can go for individual pages, sections of a site that have been redone, or even entire websites that have been retired.

Having all of this old but unused content in the system can make doing upgrades tough. Why? Because anyone new to your solution won't know what's "real" and what's not. It also means that the automated discovery tools we use to determine what components are being used could turn up many false positives.

So, before beginning an upgrade, do everyone a favor, and clean out your content attic!

Prep Your Solution

If content cleanup is relatively easy, this one is the opposite but is even more important. There is great variability in the way that various partners have implemented Sitecore over the years. From people developing XSLT display components directly in the root of a production server to people creating super-helix solutions with dozens of sub-projects and everything in between. The odds are that your solution could include using some cleanup to speed up an upgrade. If you have developers around with some bandwidth, these are some significant prep tasks to fill up that time with.

First, you want to make sure that your solution is developed "outside the webroot". This means that developers have their code developed outside of the folder structure that Sitecore lives in and are deploying that code (usually through Visual Studio) to the folders that Sitecore lives in.

The reason this is helpful is that it separates the files that get updated by the Sitecore update process from the files that developers are tracking in source code. It also makes it much cleaner and easier to upgrade because it means that a new version of Sitecore can be installed from scratch, and all of your solutions will be portable enough to be deployed to that new instance. This is far easier than having everything intertwined.

Another good reason to follow this approach is that it ensures, or at least encourages, developers, to reference the Sitecore code libraries in their code using methods that make it easy to update those references. This is an important part of an upgrade, and having these setup well will definitely make that process much smoother.

While you're reviewing your solution, you also want to think about the modules you have installed. Did you install PXM because you wanted to try it out? Did you stop using Web Forms for Marketers four years ago? Now is the time to disable those things and clear them out. One of the major time eaters in upgrades is upgrading modules or migrating from one to another. The fewer modules you have to contend with, the better, and it'd be incredibly irritating to pay to upgrade something you don't need or want.

Take a Hard Look at Your Analytics Data

Are you capturing Sitecore Analytics data? And are you one of the many Sitecore customers who have XDB data and aren't doing anything with it? There's no shame in that, but you want to be realistic with yourself about that data.

Migrating XDB data from previous versions can be a time-consuming part of an upgrade project. If you've been capturing data but haven't been doing anything with it, determining that it's ok to lose that data during an upgrade can be a real-time (and, therefore, money) saver.

While you're preparing for your upgrade, think about your analytics data. If it's not bringing you joy, have the conversations and get everyone on board with letting it go.

These tips should hopefully get you ready for your Sitecore upgrade and help you streamline the process. If you want to learn how to speed up your upgrades further, often by up to 50%, make sure to check out our Sitecore Elevator tool. It takes the pain out of upgrades through automation.