21 enero, 2021
If you are looking for a quick answer for the article title you are either a manager or in a wrong place. This article is set to help you understand what a Sitecore upgrade looks like, why should you do it, and how to go about it. If you are still reading; I suggest you grab a beverage and read this with an open mind.
Why should you (or not) upgrade?
The list below is not exhaustive, but it’s ordered in the most important reasons first
- Your solution is filled with a million Sitecore Patches and hotfixes.
If you are there, means you have not chosen the right version of Sitecore. Sitecore just like any other software product has good and bad releases and you should be able to tell that by the number of patches you have been given. Sitecore patches are developed by Sitecore Support engineers and released to you with absolutely 0 QA time (hotfixes are not patches and they go through a full cycle). So, don’t be surprised if they break on production. if you see most of the bugs in your solution is fixed in the new release, just go for it.
- Your support is entering extended phase https://kb.sitecore.net/articles/641167
As you may already know, Sitecore exits the main stream support 3 years after the version release date. That basically means you will have no more support for development. You might say “I am not developing anymore” but if you do, you might have to plan a big budget way before the due date.
- You are having continuous development
If you are having releases every now and then, shipping new features constantly, you might want to spare a sprint only for Sitecore upgrade. This will keep your stack up to date and your team happy. In short; it will pay off in long term.
- You have decided to enhance your product.
Say you have a website which have been developed a few years ago and now you wish to extend/enhance it. An upgrade makes sense here for two reasons. One: you will not enter Sitecore extended support phase and two your team will get a better understanding of the solution before starting to add into it.
- The new release has the feature you have been waiting for.
Yes, you need the new feature and you want it as soon as possible. I think you should do it but bear in mind that every new feature can be buggy or not exactly meet your expectations.
What are the upgrade methods?
Sitecore officially has two upgrade methods:
- Sitecore Upgrade wizard
If you are the unluckiest person in this small world, this option is for you my poor friend. You should go with this method if you can’t really delete your old environment and create new one. It could be because you don’t have proper CI Stack, and everything would be ruined if you delete the existing environment; or you have been horribly modifying items in your productions without serializing the changes (shame). During my years of experience with Sitecore, I have seen so many unfinished upgrades and guzilian number of Godzilla bugs that appeared after such an upgrade. Of course, Sitecore has Improved the wizard through years but still there are many reasons that some items might not get updated and when that happens, any issues arises from that unfortunate incident can’t be easily identified.
- Destroy and start fresh.
This is probably the easiest and the safest way of doing a Sitecore upgraded. In this method, you delete your old environment (including databases, Site IIS settings, Files, etc) and spin up a fresh Sitecore instance with the target Sitecore version. Later you will deploy the upgraded version of your solution + the content on top of this fresh new environment.
What to expect from a Sitecore Upgrade?
Sitecore upgrade might or might not bring benefit to your solution. Firstly, your intention for an upgrade must be justified. If you possess an old solution which works perfectly but you want to make it better, you are right. Upgrade is the best way to keep a working solution in the train of helping your business. Of course, the task will introduce new bugs and there will be hiccups after the go live, but if you look at the big picture, it will pay off in the long run. Your now working solution will be tomorrow’s worst nightmare should you leave it untouched for years. Technology grows too fast and if you miss the train, there will be penalties to pay. To name some, it’s hard to find developers who are willing to work with an old technology. Your service provider will stop supporting your dinosaur website, and finally there might be a dangerous security hole discovered in your infrastructure that might bring your online business to a full halt or worst.
On the other hand, if your business needs have changed over the years and the vision is no more matches the website initial design, upgrade might not be the best way to go. It is important to know new business logics should not be added to an upgrade scope. No new feature should be built or even an alteration in the logic can raise the complexity of an already complex process. The deprecation of old Sitecore APIs or other dependencies (such as glassmapper) might requires major refactoring in the code. The cost and effort associated with such change might even exceed a brand-new solution. A Sitecore audit with a team of experts can shade some light on it.
Where to Start?
Sitecore upgrade involves lots of different activity. The first and the most annoying part is to upgrade the Sitecore nuget packages and all the dependencies to what matches your solution as well as Sitecore dlls. This is not an easy task as not all the required assemblies and their versions are written somewhere (as far as I know). Your best chance is to decompile Sitecore.kernel.dll to find most of the compatible references. You may use a higher version of the references, but it might introduce other issues and hard to find runtime errors.
Once you have upgraded all the packages, you need to press ctr+shift+b and sit tight and brace yourself for the impact 😊. When you build the solution, you will realize how incompatible your solution is with the new references. This is probably the longest task of the process and after a few weeks of hard work you can only build the solution just to find out all your unit tests have stopped working and FakeDb is no more supported. That’s the real fun pat if you know what I mean.
Building the solution is not the end. Once the solution is published, you will realize some great developers have thought, it is a great idea to write most of the business logic in a view where you don’t get proper build error. You will constantly visit the lovely YSOD until you finally load the home page. There, you deserve a cold beer. The hard part is over and now you can rely on your QAs (hopefully) to list out all the component that are not working anymore.
Once all this is over, the final step will be content migration. This is where you might invest in a tool such as Sitecore Razl (formerly known as hedgehog Razl) to move content between the two databases or rely on the good old Sitecore packaging to bring the content over. If your media items are stored in DB, Sitecore package manager will not work perfectly as the Package size can get really large. Otherwise, moving items can be easily done using Sitecore package. Of course, there are some twitching to be done in order to speed up the package installation but need to be careful not to miss anything behind.
What could go wrong?
It’s mostly depends on the quality of the legacy solution. If it is well written and it is free of bugs, you can be sure that the new carefully upgraded code will perform just as good (regardless, a full QA cycle is recommended). However, garbage in equals garbage out. A Sitecore upgrade can coincide with technical consolidation. Means, with little more investment in the task, you can hire the right person who can revamp the code during the upgrade. It is worth noting that, such a change might introduce new bugs and loads of broken unit tests that should also be taken into consideration when estimating QA and developer effort.
Conclusion
A Sitecore upgrade will be a good investment should you make an informed decision. Latest Sitecore version does not necessarily means a more stable solution but it is certainly a step toward success.
