Why are Sitecore upgrades such a pain?


We’ve just tried and failen when upgrading a Sitecore solution to 8.1 update 1.
The promise from Sitecore is that it is no biggy upgrading their product. I have never experienced delivery on that promise, yet. 

Patches uppon patches

In our solution we have 10 support patches to errors in the product that could not be ignored. We have tons of other bits and pieces that we luckily don’t use.

To make sure that these patches are still applicable we’re contacted Sitecore support. Even Sitecore support are having a hard time figuring out which bugs have been fixed and which haven’t, and of a given patch can be used in later versions of the product.
I’m glad I am not in their shoes.

Upgrade paths

As most people that have ever tried to upgrade a Sitecore solution knows there are some upgrade paths that you need to follow to make sure the upgrade is done correctly and the solution works afterwards.
Sometimes, however, there are some paths that just don’t lead to the same end goal, thereby leading to digital rot. 

Digital rot

When having a Sitecore solution that has undergone a few upgrades a substantial amount of digital rot starts to appear. 
Older upgrades did not clean up the database very well. That means that there may be older items that is not used anymore but still are stored in the Sitecore databases.

Breaking changes

When upgrading a Sitecore solution there are always the possibility of breaking changes.

In our case we upgraded Webforms for Marketers to the new version and suddenly our custom actions did not work. Someone broke the interface, by adding some new objects that needed to be added as well. Was it documented somewhere what data should hold and be used for? Of course not. 
The natural response was yet another ticket at Sitecore Support. The response was a little wierd. A link to a blog post about making WffM actions the old way. At Pentia we know how to make custom action for WffM, thank you very much. 

Also Sitecore moved almost EVERY setting ever made into Sitecore.config. But not one-to-one. Some items were moved or renamed, which was a bit of a hazzle. 


Upgrading a Sitecore solution with real data is no easy task. Maybe upgrading in Sitecores Labs is easy enough, but in the real world it is a totally different ball game.
Sometimes I wish that Sitecore would ask their implementation partners to give them real data they could try to make the upgrade on. 

Maybe it is time that Sitecore thought about splitting the product up into smaller pieces (Modules) with fewer moving parts. Thereby making upgrades easier.

And Sitecore, please start documenting all changes.