So, you find yourself in a need of a Sitecore Upgrade and don’t know what to start with or how to approach it? This series of blog posts will cover the whole process from zero to hero, or in upgrade terms – from planning to going live. It comes in the form of a guide that will save you at least 2 times of cumulative effort, due to avoiding hidden traps and unobvious issues on your way to a shiny upgraded solution. Over time I have struggled and documented most of these issues and now want to share them all in one place.
Content
- Part 1: Scope Planning
- Part 2: Upgrade Tactics
- Part 3: Content Migration
- Part 4: Upgrading the Codebase
- Part 5: Changes in Sitecore 10.x
- Part 6: Testing and Going Live
Upgrade Tactics
Next, let’s talk through some upgrade tactics that can significantly help your upgrade process.
1. Switching Between States
Affixing the states and being able to switch between them as quickly as possible is crucial for productivity when working on instance upgrades. Small mistakes are inevitable and we actually need some sort of Undo button for the whole process.
We already have this approach implemented for codebase – git, with its ability to switch between the branches.
But what about the published sites, indexes, certificates, and the rest of the minors that matter? Even database backups are not that fast and straightforward.
Affixing the state is crucial:
- There will be small but time costly mistakes
- We need an “Undo” button at each stage of the process
- It should undo everything in one shot
- Can virtualization help us with that?
The one and only solution that comes into mind is fixing the whole state of a working machine. Something that one could have with a Virtual machine. Luckily, we have at least one suitable technology:
2. Hyper-V
Actually, this virtualization technology from Microsoft ticks all the boxes:
- free and included in Win Pro
- extremely fast with SSD
- maximum OS integration
- move backups between hosts
- perfect networking options
- remote management
- universal virtual drives
![Hyper V[1]](https://blogs.perficient.com/files/Hyper-V1-1024x745.png)
However, you will need a relatively fast SSD and you should mind the disk space – it easily gets eaten out by multiple snapshots as you progress. Having a 1TB drive is probably the minimum you’d need to have for productive work on and upgrade.
3. Leverage PowerShell
Now we are confident with reverting bad things quickly. But how about redoing successful steps? With a lot of monotonous and repetitive actions, one could lose very much valuable time for things they will re-do again and again.
Let’s think about the case when someone spent the last 2 hours upgrading NuGet references for a Helix solution with 100 projects in it. Unfortunately, at the last minute, something went totally wrong – restoring to the latest Hyper-V checkpoint will take less than a minute, but should one repeat these monotonous steps again and again?
You would probably suggest – why not make restore point more often. Well, creating a restore point for every minor step seems to be an overkill solution, as Hyper-V will quickly eat out all of your disk drive space.
It is fairly difficult to perform an upgrade of everything from the first attempt. We will have to repeat the successful steps, again and again, so the only approach would be to automate them. PowerShell is already built into the OS, and is the best and most natural fit for such activities.
You can leverage PowerShell for:
- Any sort of automation, system tasks, and jobs
- Mass replacing configuration and code with Regular Expressions
- Backup and restore databases and web application
- Managing your infrastructure: either local or cloud
- Leveraging SPE Remote to operate your instance:
- Managing content, security, publishing, and indexing
I wrote a good long article about PowerShell best practices and all the aspects of leveraging this built-in scripting language. It is a long read, but highly valuable.
4. Quick Proof-of-Concept
In some cases, when you are performing a jump to the next version (or maybe a few versions past that) and if your solution is relatively simple, staying close to a vanilla Sitecore install, it makes sense to try a quick proof of concept (PoC). That will either give you a quick win or if not – then at least will identify most of the traps and things to improve. Having PoCs opens up better opportunities for planning the real upgrade.
Ideally, it should fit into a one-day scope of work for a single professional.
5. Try to Get a Recent Backup of a Master Database
It’s a highly desirable thing to obtain a relatively recent backup of the master database. I do realize, it is not always possible to do: sometimes due to the large size or more often because of the organization’s security policy, especially when you’re working for a partner agency or being an external contractor.
But why would you need that?
First of all, you restore it along with the existing solution to verify the codebase you’ve obtained performs exactly the same on the published website(s). Of course, if you work for a given organization and were standing in charge of the project under upgrade from day one – this step could be dismissed, as you fairly know the codebase, infrastructure, the history of decisions taken over the project lifetime, and most of the potential traps.
But what is more important, you will need to upgrade and use this database with a new solution instance to ensure that also looks and works as it functioned before. That would help you eliminate most of the unobvious bugs and errors just before regression testing starts, which will save lots of time.
A good example from my own experience: I committed an upgrade from 8.2.7 to 10.0.1 and everything went pretty successfully. I used an upgraded full master database. I was visually comparing old sites running on the existing production instance with those that I have locally upgraded to the latest version of Sitecore. Accidentally I spotted that some small SVG icons were missing from an upgraded site. Investigating this issue brought me to one of the breaking changes that would be difficult to spot – the codebase builds, no runtime errors, and no obvious log issues.
6. What if a Newer Sitecore Release Comes While you’re Upgrading?
The upgrade process takes a decent amount of time and it may be a case when a new Sitecore version is released during your upgrade project. My advice would be to stick to the newer version however it also depends on when in the upgrade process you are. If you’re already regression testing, it would be costly to add another version and realign resources.
However, newer platform releases are predictable and tend to gravitate around Symposium time. Starting an Upgrade project in that timeline you should closely monitor announcements so that can plan accordingly. In addition, if you’re working with any of the existing Sitecore MVPs, try luck asking them as MVPs are typically well-informed and they may give some hints about whether there is something on a roadmap.
First of all, it may not be an easy task from an organizational point of view, especially if you are working for a partner rather than an end client and the version has been signed off. It will take lots of effort to persuade stakeholders to consider the latest version instead, and you have to motivate your argument pretty well.
Upgrading the solution to the newer build when you a halfway done upgrading to a previous one adds some time but will cost times less than upgrading once you go live. It will be a good idea in most cases with some exclusions, however, like when a previously utilized component gets deprecated in the newer version. For example, once I was upgrading to 9.0.2 and then 9.1 has been released, but due to the large usage of WFFM, it was not possible to easily jump to 9.1 as WFFM was deprecated in 9.1. Otherwise, we should have chosen a newer version.
Choosing a newer version in fact could cost you even less. Another example from my career happened while upgrading to 10.0.1 when the newer 10.1 got released. Switching to 10.1 from 10.0.1 would cost me very little effort, and also would reduce operational efforts due to the specific advantages of Sitecore 10.1 – but unfortunately, the decision chain to the stakeholders was too long (I was subcontracted by an implementing partner), and that never happened.
7. Take Comprehensive Notes
Last but not least, this advice may seem to be obvious, but please take it seriously. Please document even minor steps, decisions, and successful solutions. You will likely go through them again, and maybe several times. Save your scripts as well.
An even better job would be if you could wrap all your findings into a blog post and share the challenge and solution with the rest of the world. Because our blogs are indexed by search engines, you’ll help many other professionals. Several times in my career I googled and found my own blog posts with the solution while facing a challenge for the second time or more.
Tip: thanks to the previously taken notes this series of posts became possible.
These were 7 tactics I advise you to use in order to speed up your Sitecore upgrade project. The next post will be about migrating the content.
