Skip to main content

Upgrading Dynamics CRM, Part 2

This is adapted from the InfoStrat White Paper "Upgrading Dynamics CRM." Download the full whitepaper here:!upgrading-dynamics-crm/c15ht

On-Premise Upgrade Steps

Upgrading from CRM 4.0 to CRM 2011
There are two different types of upgrades:

1. In Place – use existing servers and upgrade the existing live system in place.

2. Migration – Set up a new server environment and migrate the CRM organizations from CRM 4.0. We recommend the Migration Upgrade approach as it provides the ability to test the upgrade multiple times, allows for performance benchmark testing and leaves your existing CRM 4.0 environment in tact in case a rollback is necessary.

Here is a step by step guide to migrating using the recommended Migration approach[1]

1.   Perform a fresh install of Microsoft CRM 2011 on a new server(s).   You can have one server that hosts both the web application and the SQL databases or you can have two servers, one to host the web application and one to host the SQL databases.

2.   Make a backup of your existing CRM 4.0 SQL organization database using SQL Server Management Studio (it will have a name like OrganizationName_MSCRM).
3.   Physically copy the backup from step 2 to your new server that will be hosting the SQL Server databases behind your CRM 2011 install.
4.   Create a new SQL Server database on your new server hosting the SQL Server databases for CRM 2011 using SQL Server Management Studio.

5.   Restore the backup from step 2 over your new SQL Server database from step 4.

 6.   Open the CRM 2011 Deployment Manager software that is running on your new server that is running the CRM 2011 web application.   Click on the Import Organization Wizard. 

 When migrating from CRM 4.0 to Dynamics CRM 2011, there are no changes in customizations required, as CRM 2011 supports all CRM 4.0 JavaScript, plugins and DLLs. However, Dynamics CRM 2013 does not support some CRM 4.0 DLLs, SDKs, JavaScript and plugins.  The Legacy feature check tool from Microsoft helps to check all customizations which are unsupported by Dynamics CRM 2013.

Upgrading CRM 2011 to CRM 2013

In all cases you will want to run the legacy feature check tool and address any plugins and JavaScript issues reported. This is particularly true if the application you are upgrading was originally developed in CRM 4.0 or earlier. Now the migration process to Dynamics CRM 2013 from CRM 2011 can be started. The customizations from CRM 2011 are supported by Dynamics CRM 2013, so only the CRM 4.0 plugins need to be re-written for CRM 2011. The other option is to remove all CRM 4.0 customizations, migrate it to CRM 2011, and then to Dynamics CRM 2013, after which the customizations can be implemented in Dynamics CRM 2013.

 There are multiple approaches available to upgrade CRM 2011 to CRM 2013.  In all cases the process begins with installing a new instance of CRM 2013.  Once the new instance is created, the options generally consist of:

1.    Install a new CRM Application Server using another instance of SQL (different from the instance used for CRM 2011).

2.    Install a new CRM Application Server and upgrade the CRM 2011 instance in place using the same SQL Server in place.

3.    Upgrade the entire application in place

We believe only Option 1 presents an appropriate level of risk, assuming that the application can be “frozen” for the time it takes to perform the final iteration of the upgrade.

Data Migration Design

As with the application upgrade, there are multiple options for migrating data in an upgrade from CRM 2011 to CRM 2013

1.  Back up the CRM 2011 SQL Server database and restore to the CRM 2013 SQL Server database, then import the CRM 2011 Organization using the CRM 2013 Deployment Tool. This will migrate all data without a separate data import.

 2.  Export data from CRM 2011 and import into CRM 2013 using the CRM Import Tool, SQL Server Integration Services (SSIS) or a third party tool such as Scribe.

We strongly recommend Option 1 because Option 2 is very high effort and is error prone.  Option 2 gives the most control and might possibly reduce rework if functional upgrades are being accomplished with the version upgrade, but the effort and risk generally outweigh any advantage.

Multiple Iteration Upgrade Approach

The only way to reduce the risk and schedule impact of the upgrade is to try to anticipate the issues that will be found in the upgraded application.  This can be accomplished by a combination of manual inspection and automated code checking. 

A manual inspection and analysis of the CRM 2011 application will be performed and will compare the implementation techniques used to the list of changes in CRM 2013.  For the automated code checking, there is a tool provided by Microsoft called Microsoft Dynamics CRM 2013 Custom Code Validation Tool which can check JavaScript customizations.  It is important to note that both the manual inspection and the automated tool will only produce a list of what might need to be technically replicated in CRM 2013 from CRM 2011.  These processes do not address the issue of what is the least effort and best practice to accomplish the same goal functionally in CRM 2013 that was accomplished in CRM 2011. 


The Custom Code Validation Tool in particular tends to produce large numbers of false positives in situations where code that is actually supported and not a problem is marked as potentially needing to be fixed.   These can be very extensive and include:

·         JavaScript code which supports an HTML web resource and interacts with the DOM of that web resource.
·         Code in JavaScript libraries to test for browser compatibility.

It can be highly inefficient to walk through validation results finding every place that needs attention only to discover either that there is no problem or that fixing the problem just replicates approaches that may be obsolete.  We suggest instead a multiple iteration approach which may be both more efficient and more effective.  In this approach for the first iteration the validation is run and then the application is upgraded and tested and test results are recorded.  These results of testing are then reviewed together with the results of inspection and automated code validation to produce a Mitigation Plan.  The Mitigation Plan documents areas that need attention and the decision whether to fix or replace with a more effective use of CRM 2013 features.  Based on the Mitigation Plan, one or more iterations of the upgrade process are performed.

Sample Step-by-Step Plan:

1.  Perform the inspection and code validation on CRM 2011.

2.  Install CRM 2013 in a new environment.

3.  Back up the CRM Application database from CRM 2011.  By default this is _MSCRM.

4.  Restore the CRM Application database from CRM 2011 on to the new SQL Server database supporting CRM 2013.

5.  Using the CRM 2013 Deployment Manager, import the Organization.

6.  Perform regression testing on the upgraded application and record issues discovered.

7.  Perform and record any immediate fixes to make the application usable for testing.

8.  Review test results, inspection results and code validation results and create a Mitigation Plan which defines what is to be fixed and what is to be replaced.

9.  Estimate time needed for the upgrade and determine feasibility of freezing the application long enough to complete the upgrade.  If feasible, proceed, otherwise develop an in place mitigation approach for CRM 2011.

10.  Freeze the application.

11.  Re-do steps 3 and 4 and use the Mitigation Plan to complete the upgrade


Upgrading CRM 2013 to CRM 2015[2]

CRM 2015 requires the following system products:
·         Windows Server 2012/2012R
·         SQL Server 2012
·         Windows client – Windows 7 and Windows 8
·         Internet Explorer 10/11
·         Exchange Server 2010/2013
·         Outlook 2010/2013

The Server Upgrade Process is a one-way process (CRM 2015 cannot be uninstalled).

Two Methods to Upgrade:

·         In-place (Install media on current servers)

·         Migration Upgrade (preferred): Deploying a new CRM instance and separate database and then migrating your organizations from one database to the other.  This approach is recommended so that you have the ability to fall back to the CRM 2013 system if you need to.

Note that CRM 2013 must be at SP1 or higher

One of the important things about upgrading from 2013 to 2015 is the mandatory change in the database structures of CRM.   Prior to actually upgrading your organization, Microsoft applies a set of diagnostics to that organization to determine if it is safe to upgrade the organization.  If it isn’t you will be told what is wrong and how to correct.  If there is an issue, click on the “More Info” button that will link to an article explaining the issue and how to correct.

Issues that can be taken care of for you will be presented as warnings.  Warnings inform the user of necessary changes to the organization in order to upgrade.

When 2013 was introduced, Microsoft modified the core database structure and collapsed a series of tables to optimize for efficiency.  To enable existing customers to run their old CRM systems, Microsoft enabled customers to run in the old database state Microsoft calls the expanded state.  For 2015, the merge process is mandatory for the upgrade.  This enables a higher performing CRM system.

f your database is not in the merged state, Microsoft will merge it during the upgrade.  If the database cannot be merged, the upgrade will cease and the owner notified and told of what is wrong.  You will need to correct the issue prior to upgrading.

The Solutions Framework is the means by which you move customizations from one CRM organization to another.  With CRM 2013 Service Pack 1, Microsoft has added the ability to export a solution to a specific version of CRM.  CRM 2015 solutions will integrate with CRM 2015 deployments but will not be importable into CRM 2013 deployments. Microsoft does not support CRM 2011 solutions coming directly into CRM 2015. 

For customers who upgrade to CRM 2015 who have not upgraded to use CRM 2013 “V6” forms, the older V5 forms (“Information forms”) will be imported into CRM 2015 and will continue to work as they did in CRM 2013. The CRM form designer will retain the ability to migrate forms to V6 forms.  As Microsoft adds new capabilities and features to CRM 2015, however, these will be added only to the new forms and not to the old forms.

Popular posts from this blog

Key Concepts for Microsoft Dynamics 365: Tenant, Instance, App and Solution

Updated 8/15/2022 To understand Microsoft Dynamics 365 (formerly Dynamics CRM) and Power Apps, you need to learn some new terms and concepts that may be a bit different from what you know from databases and solutions that are hosted on premises.  These concepts also apply to Power Apps.  The main difference is that with Power Apps you are not starting with a Microsoft app but more of a blank canvas for your custom apps.  This post introduces some key terms and how these concepts are important for planning your implementation. While Dynamics 365 is still available on premises, it is most commonly deployed on the Microsoft cloud.  This blog post discusses only cloud implementations. Microsoft has multiple clouds such as commercial and government community clouds in several countries. We start with a Microsoft tenant .  A tenant is the account you create in the Microsoft Online Services environment (such as Office 365) when you sign up for a subscription. A tenant contains uni

Understanding Dynamics 365 and Office 365 Admin Roles

Managing Dynamics 365 instances If you run Microsoft Dynamics 365 (formerly Dynamics CRM) in the Microsoft cloud, you need to understand how your Dynamics instances relate to Office 365 and choose which of your administrators receives which roles and permissions to manage Dynamics 365. In on premises deployments, your network administrator would create and delete user accounts.  The Dynamics 365 admin would then assign permissions to users in Dynamics 365. This post explains three administrator roles: Office 365 Global Administrator Dynamics 365 System Administrator Dynamics 365 Service Administrator You may think that the Dynamics 365 system administrator would have power to do all the actions needed to manage Dynamics 365, but this is not the case. What's different in Microsoft cloud deployments is that licenses and user accounts are managed in Office 365 by an Office 365 Global Administrator.  This role is analogous to a network administrator for an on premises

My Favorite Microsoft Power Apps Bloggers and their Blogs

  by James Townsend Updated 7/5/2022 Microsoft Power Apps is one of my favorite subjects, and I enjoy reading blog posts from members of this thriving technical community.  Here are some of my favorite bloggers and their blogs: The Official Microsoft Power Apps Blog   I have to start with the official Microsoft Power Apps blog.  It has many contributors, largely Microsoft program manager, including frequent posters Denise Moran ,  Greg Lindhorst , Kartik Kanakasabesan , and  Adrian Orth .  This is the place to go for product announcements, updates and technical how-to for a broad range of Power Apps topics.  April Dunnam April Dunnam was formerly focused on SharePoint and now devoting herself to Power Platform.  April offers highly understandable explanations of Power Platform, Dataverse and other top Power Apps topics. She joined Microsoft in late 2019 and has a thriving YouTube channel .  Carl De Souza Power Apps Blog and eBook This is one of the most extensive and best organized blo