Upgrading SageCRM with Inbound email customizations? Read this first.

By | May 19, 2014

Nothing is permanent but change is! Same applies to business software’s too. They have to be upgraded over the time in order to take an advantage of new technological advancements.
The New Stuff: Have a look at Greytrix bulk Merge utility to merge your duplicate Customer, contact details: http://www.greytrix.com/product.php?prodid=115
Many people find the process of applying software updates to be highly annoying and disruptive. When it comes to SageCRM our view is, nothing CAN and SHOULD stop you from upgrading to latest versions. Obliviously you don’t want to end up in situation where your manager gets new laptop with Windows 8.1 or MAC OS, but SageCRM version 6.2 does not support both of them! Huhh!
Hence throughout this blog we discuss lot of precautions/steps to be taken care of while upgrading SageCRM, be it customized to any extent. I came across one such scenario recently which I would like to share.
As you all are aware of, SageCRM provides features like Email to Case, Email to communication etc. These features can be extensively customized by modifying Support.js, Communication.js files under Services folder of SageCRM installation path. Lot of people do change it and write very nice logic for processing inbound emails.

1

I upgraded one such customized instance with version 7.2 recently from patch “B” to patch “C” and then “D”.  Everything looked normal, but suddenly my inbound email customizations stopped working. Looking at above directory I came to know that my customized file is gone and has been replaced by standard file again. Now what do we do now in order to avoid such situation in future?

  1. Most important thing is you not only backup WWWRoot folder while upgrading, but backup entire Sage instance folder.
  2. Always first have a look at the Patch notes/what are new guides in order to understand what all changes will be added that may affect your existing implementation.
  3. Always do upgrade dry runs on Test machine first and then on production instance.