I made no secret that I’m a die-hard advocate for upgrading to latest EPiServer CMS/Commerce version. There are several reasons for that, mostly from new shiny features that your businesses dearly need, new big performance improvements that your customers firmly demand.

But there is another, not so obvious reason: support.

Let me tell you a story.

This morning we received a support case from support team. A customer recently upgraded from Commerce 7.5 (Eww) to 11.7 (Yay!), things went well except they had a small problem with data displaying in Catalog UI. Some of the properties were not properly displayed, but they are still showing correct in Commerce Manager.

Of course that would prevent them from launching their big deploy. Luckily for all of us, this reminded us of something we encountered and fixed recently – so we had a very good guess on what is wrong and how to fix it. It took me just 15 minutes to confirm that it is indeed the problem I thought it to be, develop a fix, test it, make sure it work, and write an explanation so our guys in support team can forward the information to the customer.

15 minutes.

If it was in an older version, say, 10.x, or even worse, 9.x, how long do you think it would take us to setup an environment to debug, actually debug it to find out what is wrong, and develop a fix? And how many hairs would be lost in the progress?

The truth is simple – the more recent version you are using, the easier it is for us to help, and therefore, the faster answer/solution you will get. It’s a win-win situation. You lose nothing, yet you gain everything.

Even if the problem was (very unlikely), a bug in our side, we can quickly fix it in a newer version – yet we don’t backport it. Say in the case above, if it was a bug, we can simply  introduce a fix in Commerce 11.8.3, and upgrading from 11.7 to 11.8.3 would be easy enough. It might not be so, if you have to upgrade from 10.x, or an older version, to get that bug fix.

Upgrading to a major version is not an easy or trivial task, especially when it usually comes with API breaking changes and database migration. But trust me, my friend, it’s worth it. Your time and effort in upgrading will be paid several times later!

So keep up-to-date please. And the partner developers in the story above will simple get beers – I’m buying.


Scott Reed · February 28, 2018 at 11:43 am

Nice, I think the key from my experience is for partner to understand exactly what the business benefits area from the upgrade. Our usual practice during a build is to mirror Episerver updates for non major releases during a build, e.g. we start on Episerver 10 and we will upgrade to any version 10 update.

As a major version can cause issues and take a longer time we usually need to break down the release notes and updates and work out the business related features a client will understand, quote the time and they advise the client to upgrade. As an agency despite the benefit it’s difficult to absorb the cost of upgrades outside of a planned feature delivery.

What would be good is on the docs such as https://world.episerver.com/documentation/upgrading/Episerver-CMS/cms-11/ if there was a breakdown of key editor/admin/business features and what they mean in a real work for each major release so we can more easily sell it.

    vimvq1987 · February 28, 2018 at 11:52 am

    Good point. However for Episerver the major releases are more of “breaking changes release” (as we follow Semantic version rules), more than of a “big features release” like in the past. So the new features are constantly added in minor releases, which you can get from the weekly release notes. The point is if you want to have a new feature in Commerce 11.7 then you’ll inevitably have to upgrade to 11 (first, even thought that would be included in 11.7).
    Performance improvements and stability are always good argument to upgrade.

Scott Reed · February 28, 2018 at 12:03 pm

Yes I use the features view regularly and I agree performance and stability is a big win but it’s not always easy to purely sell that to get the cost in to cover the upgrade. One thing that was good for example on the Episerver 10-11 was that we were using commerce and quite a few minor versions needed Episerver 11 and we were able to pull out features such as the new commerce appoval features.

Thereforce esentially not only did the 10-11 upgrade give us those features but any that were blocks from commerce needing the upgrade. For this I had to go through every update and pull together a list of all these features from the one we were limited to up to the latest version.

I guess it’s difficult to pull all this together, maybe we need something like the content version comparison feature of Episerver between 2 versions of cms/commerce that should give us all the added features? Nice to have maybe lol

Leave a Reply

%d bloggers like this: