Upgrading Customised CRM Systems

John Eccles, 16 October 2013

We all want our CRM system to be up-to-date and have all the features we need to stay competitive.  So when Microsoft releases a new version of Dynamics CRM we naturally want to upgrade as soon as possible.  But what if our CRM system has been customised?  Might it break?  If so, the consequences could be dire!  In this blog I will discuss the risks, the remedies and the costs associated with upgrading a customised Dynamics CRM system. 

(Picture from: http://www.coatssql.com/version-4-0-of-coatssql-is-available-today/)

Types of Customisation:

In this blog, I am referring to Customisation in a broad sense – any development of the CRM software or any integration of CRM to other software.  It includes:

  •  Customisations using the customisation tools in CRM
  •  Workflows using the workflow engine in CRM
  •  Custom reports, charts and dashboards
  •  Javascript development coding
  •  .NET development coding
  •  Integrations

Upgrade risks

The risks are that, when upgraded, the system may

1.  Not work at all – the unlikely worst-case scenario. 
2.  Mostly work but some parts not work. This is a common scenario.
3.  Work but with a different User Interface (UI) which confuses users.  An upgraded (different) UI is the norm for upgrades even for un-customised systems.
4.  Work as before but the new features introduced with the upgrade not work properly.  This also is the norm for upgrades with customisations.

Risks 1 and 2 are unacceptable and must be avoided.  Risk 3 can be easily assessed in advance and risk 4 may not be an issue.


To avoid risks 1 and 2 completely, the system should be upgraded in a test environment, fully tested and any breaks fixed. 

We recommend this approach for customised systems except when the following are true:

1.  A CRM failure would not be a serious problem and could be managed and fixed via the support process.

2.  The system has been customised but with minimal or no development coding.


It is important to note that major failures and therefore major upgrade costs are avoidable.  Microsoft has specified “supported development standards” and if development is done in a supported way, then it can be expected to upgrade without causing problems.  And if not, then Microsoft will identify the issues in advance and recommend remedial action.  Also if developers follow “best practice” software development, the system will be robust.  In our experience, significant upgrade costs have resulted from failure of the original developers to use supported development standards and best practice.

Here are some real examples of upgrade costs: 

Example 1: Initial development cost in excess of $2 million in CRM4. (Not done by Magnetism.)  Upgraded to CRM2011 by Magnetism in 2011 at a cost of $300,000. 75% of the upgrade cost was a direct result of un-supported and non-best-practice development.  We estimate a cost of $150,000 to upgrade to CRM2013 and of this cost, 50% is due to unsupported CRM4 development code left in the system.

Example 2: Initial development cost in excess of $1 million in CRM4. (Magnetism developed a portion of the system.)  An upgrade to CRM2011 in 2012 cost $80,000 of which 50% was a consequence of unsupported and non-best-practice development.

Example 3: Initial system built in CRM4 by Magnetism at a cost of $100,000. After 3 years it was upgraded to CRM2011 at a cost of $15,000.

Example 4: We have estimated the cost for upgrade of a number of CRM2011 systems developed by Magnetism in the $50,000 to $100,000 range.  They can be upgraded to CRM 2013 for between $1,000 and $3,000.


The upgrade risks are real, but the remedies are effective and provided the original system’s development was “best practice”, the upgrade costs should not blow the budget.