The Truth About Sitecore Upgrades
This blog post gives some insight from what I’ve learnt about the Sitecore Upgrade process, and my beliefs about how you should approach an upgrade. Many people have their own opinions on upgrades, and many have voiced them, either through user groups, blog posts, or forum replies.
While I agree with some, and disagree with others, we’re all still learning…. so nothing should be taken as gospel from anyone…
The posts (including this one) are opinions, mainly based off the author’s own experiences… and so, if there are things here that I’ve missed in this post, or something you disagree with, please let me know in the comments.
At one stage or another, every client will want to upgrade their Sitecore instance.
This may be for bug fixes, or for some of the new features that come with the latest versions of Sitecore. And with the plethora of new marketing features in Sitecore 8, the push to be up-to-date has never been greater.
At Hedgehog Development, we’ve worked on numerous Sitecore upgrades over the years.
Every one of them we’ve learned something new. No two upgrades have been the same, and some have been far more complicated than others. We’ve even written custom applications that allow an upgrade to take place over a couple of weeks, to allow for full testing and a slow, controlled roll-out of new features.
With this experience, we’ve learnt the steps involved in the upgrade, and the importance of all the intricate processes that occur during the upgrade.
My number 1 tip for upgrading Sitecore is
DO NOT CUT CORNERS, FOLLOW THE INSTRUCTIONS
I often hear people trying to reduce the time it takes to upgrade.
This is obviously appealing to the client. Less time = less money spent.
And while it’s tempting to upgrade your Sitecore instance quickly, be aware that these methods are not officially endorsed by Sitecore, and you may struggle to get help from Sitecore Support.
If you cut corners, you are prone to being bitten in the long run.
When people cut out upgrade steps that, to them, don’t seem to matter….. you miss the possibility that they are actually needed. Eventually hidden issues may pop up that won’t be discovered until someone finds features aren’t working in production months later, or the site is acting differently than before…
Anders Laub and I had this discussion in the comments on one of his posts. We agreed that you can opt to speed it up and skip steps if you know for certain it won’t affect your site, but do so at your own peril.
If steps were skipped, it can be painful trying to figure out what the problem is…..even with the help of Sitecore Support.
IS STARTING FRESH A BAD IDEA
I would recommend not ‘just starting with a fresh install and copying everything over’.
This method has been a talking point for a while, but I’ve learnt it can produce very dangerous results.
I admit, I’ve done this in my early days of upgrades, and I understand that others still opt to use this in their upgrade solutions.
Granted, it will work for some clients….but the success of it really depends on the items you have in your Sitecore instance.
If you want to take this different road to upgrading Sitecore, you may be risking more than you know, which is why I personally would not go down this route as I find it a very risky choice.
Why?
In the normal upgrade process each upgrade package can potentially modify the existing Sitecore items so that they work with new or improved systems.
Take Rules items (Actions/Conditions) for example.
The process for how a Rules field knows what Actions and Conditions can be selected (i.e what the Rules Context is) was completely overhauled in Sitecore 7.1.
Along with this came some tagging logic, and a restructuring of items in the Sitecore tree.
Now, the upgrade package for 7.1 had a Post Step that upgraded the source on your previous Rules items to work with the new system. Structures were changed, tags added, items made obsolete, and replaced by new ones…
Therefore, simply serializing them out of your old instance, and into a fresh instance, would make this source empty, and the field becomes unusable to an editor. No custom conditions or actions can be added to the field anymore. This same issue affected the Mobile Device Detector module when 7.1 was released.
The same goes with the upgrade of Placeholder Key Settings items in Sitecore 6.5.
This is only one thing that ‘quick and easy upgrades’ will miss…. What else might be lost by upgrading this way?!?!?
Not even Sitecore always gets this right…. There was a bug in the Sitecore 7.1 upgrade script, which can be repaired using this fix… but the problem emphasizes the fact that things can be silently broken if you ‘just start fresh’.
If you still want to risk all, and start fresh then copy everything over, then I would highly suggest using Razl (shameless self promotion)…. Here you can compare and copy everything over….but keep in mind that we recommend not doing this for an upgrade, because of the issues mentioned above.
WHY SHOULD I WASTE MY TIME?!?
I know…. it can be painfully slow.
But in all honesty, the learning you get from stepping through upgrades can prepare you more for the version you’re going to.
Take the Web.config changes for example. When you update them in your upgrade process you will learn new settings, options, and tweaks that you can utilize and expose with future development.
By doing this step, you learn more about the platform, and the version you’re upgrading to.
BUT I REALLY WANT A FASTER UPGRADE!
OK, ok…. so this is obviously something that people have requested for a while.
Apparently Sitecore are looking into this to see if there’s something they can do to help out. As Mike Robbins pointed out to me recently, the keynote at SUGCON NL mentioned some experimenting with ‘Express Upgrades’. This doesn’t sound like it’ll be here any time soon…. but it’s very exciting news.
LEARN FROM YOUR EXPERIENCE, AND THE EXPERIENCE OF OTHERS
Many people have posts about their upgrading methods.
One of the best (and most entertaining) that I have read is Sitecore Upgrade – The Art of War by Mark Stiles.
His post goes through removing default Sitecore files from your solution, and having your config changes in patch include files.
These two points are huge, and massively improve the ease of the upgrade process.
There is so much that you need to be concerned about with a Sitecore upgrade. Maybe you have to upgrade your Advanced Database Crawler code, your Coveo Sitecore Connector, or your Nuget package versions.
I WANT THE TRUTH!
As I mentioned at the start, we are all still learning. With so many features, add-ons and modules, every Sitecore upgrade will be different.
So what is ‘the truth’ about Sitecore upgrades?
Really, there isn’t one single truth that covers everything. Everyone has their own opinions on upgrades….everyone has learnt something different from their own experiences.
Take every opinion with a grain of salt, collect the thoughts and experiences and make your own decision.
Then post about it…. post about the pros, cons, and the reasons for your decisions so we can continue to learn from each other’s upgrade stories.
What upgrade methods or steps do you have? Please let me know in the comments below.
I’ve definitely seen more articles on upgrading Sitecore in the last few months than ever before.
It’s probably due to the interest in Sitecore 8 and partially because the process is so painful. Luckily there’s a lot of people ready to help.
This is great advice. Most sitecore developers have come across some problem when upgrading version due to database changes, or config file changes. Using a tool like beyond compare to compare your current config files against the default ones is a great way to make sure you don’t miss something or something isn’t screwed up with your current configs.
Thank you for this post, Sean. I totally agree. I also prefer the “step by step” way. It takes time but you will have total control of the upgrading process.
Over the past few years I’ve done a bunch of upgrades across two different instances. I have gone 6.2 -> 6.5 -> 6.6 -> 7.0 -> 7.1 -> 7.2. I’m now in the position where my BO’s are looking to upgrade to the latest Sitecore 8. I have played around with doing the upgrade, but it is failing miserably to get to 7.5, mostly around the analytics updates. We use the analytics API and many DMS features, but we aren’t writing to the (current) MSSQL analytics reporting database. Where I’m failing is always in the mongo/analytics/reporting update.
We have made a decision to not use the xDB in our 8 installation – but upgrading without it seems to be extremely troublesome.
The sites have always been pushed down the standard upgrade path, so there are some 6.x (and even 5.x) features in this 7.x instance. Like many sitecore installations, this one has seen different teams of developers and it’s a bit of a mess. The allure of having a fresh install without some of the old config and items that are unused should probably be a factor in the “do I start from scratch” decision. In my current situation, I can see alot of benefit in going to a fresh Sitecore 8 and then de-serializing content into it. We have a few custom pipelines and rules – and to your point I’d hate to have them be non functional when they’re living in a 8.x environment.
Any thoughts?
Hey Robin,
It’s a very interesting problem you have. By the sounds of it, the issue you’re facing is more about the mess of the project, both with code and items. It’s definitely a common issue, especially with long-running projects.
It sounds like you’d like to trim down the legacy code and items from the solution more than anything. It’s great to do this before an upgrade, but I don’t think it adds to the ‘start fresh’ approach argument.
The ‘start from scratch’ approach I mention more refers to the items in the database…which, as you mentioned, would mean your rules items won’t be compatible. If you really want to go that way, you could figure out the before and after structures of those items, then just re-do those changes when you go with the start fresh approach.
Again, it’s not ideal, and very open to human error, and you might miss some other things as well, but it could be the alternative you need.
By the way, by not using the xDB in Sitecore 8, you also lose all of the DMS features (i.e the Personalize button is disabled). Previously you could have DMS turned on without tracking analytics, but in 8.0, you can’t continue to have DMS but with Analytics turned off. I believe this is something Sitecore will bring back with a future version.
I totally agree with everything you’ve written but one thing I’d worry about is assuming the proper upgrade process can not be error prone – after doing tonnes of upgrades I’ve regularly found it can cause unpredictable/hidden errors especially if you are doing a huge chain of upgrades. Maybe it is just me that has found this? In which case ignore me 🙂
Choosing the way you upgrade is really about the situation, I don’t believe there is one best solution for every scenario. It is for you as a developer to decide and blog posts like this can only help you guys make an informed choice.
Hey Dave, thanks for reading the post.
I agree with you, the proper upgrade process can also be error prone. I even found a bug in the 7.1 upgrade and created a fix for it… It just goes to show that even the Sitecore developers who write the upgrade steps and scripts, are human after all! hahaha.
Despite this, you will have a better chance at getting help from Sitecore support if something goes wrong, than if something fails while doing a different process.
It’s definitely situation specific though.
Hey Sean,
You can check out more explanation for the approach I’m proposing here: http://marksaad.net/2015/07/19/how-sitecore-upgrades-work/
I hope it eases your concerns a bit 🙂 anyway, I will be waiting for more comments from you!
Nice post Mark. It’s great to see developers discuss the upgrades more and more. Together we’re building a more complete understanding of the process, and learning from each other’s experiences.
I’ve added some comments on your post as well, but thanks for taking the time to share this knowledge and experience with me.
I’m thinking of upgrading from 8.0 to 8.1 – do you think it is worth it? It seems to me that sitecore 8.0 was launched before it was ready and thus investors in the platform (version 8.0) are paying the price. Will 8.1 solve the problems found in 8.0 or will I be in the same boat (does 8.1 come with it’s own issues)?
Thanks
Hi Danni,
I definitely think it’s worth it.
8.0 introduced a lot of new concepts and marketing features, and each of the various updates gave fixes and improvements to those features.
8.1 added only a couple of new big features, but it massively fine-tuned the ones that were added in 8.0, and greatly improved performance and usability of those features.
8.1 probably isn’t without bugs (what software is?)…. but it’s a lot stronger than 8.0. For anything that is found, Sitecore Support and the Sitecore Community are fairly quick to find and fix such problems.
If you’d like, feel free to send me an email at [email protected] so I can let you know more about the 8.0-8.1 differences, and hopefully I can find out more about the particular problems you’ve encountered or concerns you have about the platform.
Thanks,
Sean
My first problem is that even the official upgrade instructions are confusing and hard to follow at times. There are some instructions that spell everything about nicely and others that are vague. My second problem is how the heck am I supposed to upgrade production servers when the upgrade process takes so long. I am trying to upgrade 1 CM and 2 CD servers from v7.5 to v8.1 Update 3. I can’t figure out any sort of strategy to get this to work. It feels like it will take me a full week to upgrade those servers. That means we would have to have a content freeze for a week. And we would need to cut off all user registrations and order placements on our site for a week too! There’s got to be a better way.
The production servers issue is definitely a problem for a lot of people. At Hedgehog we’ve even been tasked with doing a sliding upgrade, over a 2 week period, with absolutely no content freeze.
It was complex, but achievable.
Interesting perspective, especially avoiding the start-fresh technique. It’s 2.5 years later–has your thinking evolved, or do you still stand by this as is? I’ve seen some start-fresh techniques described at Symposiums and other places.
Yep, absolutely.
I’ve found that starting fresh might be an option only for the newer versions of Sitecore, where there aren’t any Post Install steps run by the installer. In that case, you may as well use the supported Express Migration tool anyway…
But for older versions, if people choose to start fresh they either trust that nothing will change their items in the DB, or they are completely unaware of the consequences mentioned in this post.
I always recommend people extensively know what they’re getting themselves into with either approach…. and for me, that means I go with this method instead.
You could also confirm your upgrade once done with Razl, the database comparison tool, to make sure everything is in order.