Upgrade vs Rebuild, Interest vs Responsibility

Apparently blog writing software worldwide has been knocked out by Google’s recent turning off of an old authentication method. If, like me, you use Blogger, the good news is Microsoft and Google are coming up with a joint solution to the problem. If that is not good enough, you can create a WordPress blog site and import all of your blogs. I will give them a week or two before making the jump.

This week’s blog is inspired by a piece of work we just completed and the follow-on work which may result from it.

The Proof of Concept

Within their industry, the client checks the compliance of service providers through regular visits and tracks what measures need to be applied to meet the legal standards required. In some ways they are similar to restaurant health inspectors. They were managing this process through Microsoft CRM v3 (yes, this was before it was called Dynamics CRM). Understanding it was time to move on, they wanted to do a trial upgrade to see what could be preserved and plan out the actual upgrade.

Microsoft CRM v3 was the second version of CRM after v1.0/1.2 (there was no version 2). This was the early days of CRM and introduced the Marketing and Service modules of the product. It also introduced the extension tables for the entities, allowing many more custom fields than was possible in v1 and allowed for the creation of custom entities.

Despite making the product ‘practical’ and propelling it past Sage ACT! which had, in my opinion, been Microsoft CRM v1’s closest competitor, it still had significant shortcomings. The predecessor of plugins, “callouts”, had significant limitations, as did the API, so it was no surprise that the client had been very creative in their customisations of the solution.

It was common for consultants to embrace ‘unsupported customizations’ in v3 because of the limitations. Unsupported customizations are changes made to Dynamics CRM which Microsoft do not support i.e. they cannot guarantee they will survive updates and Microsoft reserves the right not to support a system where they have been employed.

In this specific case, the client had added stored procedures to the SQL Database (a CRM no-no), and renamed CRM tables and replaced them with SQL views (a really big no-no). They had avoided the use of callouts and done practically everything with JavaScript, web pages, and windows services.

To upgrade to Dynamics CRM 2015, it is necessary to take the system through every version. So the upgrade went from Microsoft CRM v3 –> Dynamics CRM v4 –> Dynamics CRM v2011 –> Dynamics CRM v2013 –> Dynamics CRM v2015. Practically every part of the CRM architecture was revised and tweaked over these versions. For example, between v3 and v4, Dynamics CRM went from a pure on-premise solution to a deployment-independent solution i.e. CRM Online and, more recently, the product went from only supporting Internet Explorer for its web client to supporting all major browsers.

Not surprisingly, very little of the customizations survived the process, with most having to be removed just so the upgrade worked at all. Our own l33t CRM developer, Colin Slack, brought one of the major pieces of customizations all the way through so the client could see how the product looked in Dynamics CRM 2015.

The client was happy with what they saw and we set about putting a proposal together for the actual upgrade.

Three Options

It became clear there were three options available to us to get a working Dynamics CRM 2015 system:

• Upgrade Lite: Literally get the current system and make it work in Dynamics CRM 2015
• Upgrade “Proper”: Upgrade the code where needed but, with the significant advances in the configuration capabilities of Dynamics CRM, where possible replace what was JavaScript in CRM v3 with configuration in CRM 2015
• Rebuild: Start with a fresh implementation of Dynamics CRM 2015 and determine what the business needs (as opposed to what was possible with CRM v3) and configure/customize as required

Costing the options it also became clear that the effort to rebuild was significantly less than the upgrade options and much less risky in terms of nasty surprises in the many years of code applied to the old system. It also allowed a more robust design. For example, JavaScript, the tool of choice in the existing design, relies on the user opening a form to trigger the code. This means the JavaScript will not fire on the import of records, if a web form is used, or if mobility options are used. While not part of the business processes today, it is inevitable that this will become a problem some time in the future.

The problem was the client was fixed on their path. All along they had assumed that the way to go was to upgrade and for us to convince them of a different approach was difficult. To complicate matters, the decision makers were reluctant to get the business involved in the intensive workshops necessary to understand the business processes for the rebuild but largely unnecessary for the most expensive Upgrade Lite option.

This discussion is still not resolved and it may be the business prefers to go for the more expensive option to avoid disruption to ‘business-as-usual’, discounting the ‘best practice’ option. Ultimately it is their business and they must choose the best path for them.

Conclusions

The reason I wrote this was to highlight that while upgrading is normally the obvious choice, it does not always mean it is the best choice and, under certain circumstances, rebuilding the system can make sense.

In this case, the most cost-effective, risk-averse option was rebuilding but, with the consultant having incomplete information, this did not mean it is the best option for the business. While, as consultant, we may get frustrated with clients who pay us money to hear our advice and then not heed it, it is ultimately the business executives’ responsibility if the business succeeds or fails, not ours, and we must respect that.