In my first post, Dynamics CRM Upgrade: 2011 to 2016, Part 1, we looked at some general considerations with a CRM 2011 to CRM 2016 On Premise migration.  This touched on resource planning, assessing new features, test and release planning, and the final roll out. We began discussing my current customer experience with an enterprise system migration of a very complex, xRM heavy CRM 2011 on premise system to CRM 2016 on premise. The next step in the migration focuses on bringing the database through the upgrade steps.

Migrating the Database

As outlined in Part 1, my customer decided to take a staged approach and migrate to a new instance of SQL Server.  This approach is outlined in Microsoft’s documentation at Technet: Upgrade a Microsoft Dynamics CRM Server ( https://technet.microsoft.com/en-us/library/hh699716.aspx#BKMK_Upgradeoptions ).

Fortunately, upgrading the database is relatively easy. The Microsoft Dynamics CRM Deployment Manager will apply all of the database upgrade scripts for the you. Simply point the Deployment Manager to your database and away we go!

Ok, as I am sure you guessed, it’s not that simple. Almost all of the work on the database is still going to be done for you, but you still need to jump through a few hoops.  As mentioned, we are not going to upgrade the database in place, which is good since we actually CAN’T do an in place migration. This is because we are upgrading across several versions of Dynamics CRM and the Deployment Manager can only handle one version upgrade at a time. Meaning, we can’t just install Dynamics CRM 2016 and use the Deployment Manager to upgrade our database.  We have a few steps to take first.  This limitation has a big impact on resource and schedule planning as well as your detailed migration steps.

Database Migration Steps

Steps for upgrading a Dynamics CRM database by one version are relatively straightforward.  Assuming we are in the same domain, the steps are essentially as follows:

1. Install new CRM version on target system
2. Perform a Full DB backup of current system
3. Restore DB to target system database server
4. Import Organization using Deployment Manager Organization Import Wizard on target system

Rather than duplicate the Deployment Manager Organization Import Wizard steps in this post, I will just refer you to the Microsoft documentation. This Microsoft Technet article offers detailed instructions for using the Deployment Manager Organization Import Wizard: Import and organization ( https://technet.microsoft.com/en-us/library/dn905200.aspx ).  This additional article provides a few more details on upgrading your organization using the Deployment Manager, including some of the caveats: Upgrade an organization ( https://technet.microsoft.com/en-us/library/dn920271(v=crm.8).aspx ).

Once the Organization Import Wizard completes, you should have a functioning system on your target environment, upgraded to the new version of Dynamics CRM.  All instance database data should be migrated, such as system user records, Accounts, Contacts, custom entity records, etc. Users on your current system should be able to login to this new instance with the same credentials and see the same data as they saw just before the full database backup. You may see some issues with your system depending on the customizations made, such as some JavaScript or plugin errors.  This will all depend on your current solution. But the general idea is that if we were to take a baseline CRM instance and upgrade from one version to the next, the system should be fully functional post Organization Import Wizard.

Since we are moving from CRM 2011 to CRM 2016, we will need to repeat these steps for each version through which we are upgrading:

1. CRM 2011 production -> CRM 2013 staging
2. CRM 2013 staging -> CRM 2015 staging
3. CRM 2015 staging -> CRM 2016 staging
4. CRM 2016 staging -> CRM 2016 production

These steps are a bit simplified because there is a lot of work to be done before finally deploying to the CRM 2016 production instance.  But I think it illustrates the steps required and the impact on your upgrade planning.

Migration planning (again!)

As you can see from the Technet articles, the steps for the Import Wizard are relatively straightforward. But your organization will need an environment for each interim version of CRM listed above.  This can require significant time and resources depending on your organization’s current capabilities. My customer’s infrastructure team set up virtual environments for the development team to accomplish each of these steps. Each virtual environment is self contained with full installations, meaning they ran SQL Server, SQL Server Reporting Services, and Dynamics CRM with all of the server roles. This allows the dev team to handle resources as needed, such as beefing up memory for the migration or shutting down the entire virtual machine when not in use. Fortunately, my customer has an excellent infrastructure team in place. They set up the environments, provided access and managed resources to each, and provided the correct roles and accounts required for the migration steps. This work saves the development team a big chunk of time during our migration stages.

Once you have the infrastructure in place, this process can also take a lot of time!  Your team will need to schedule accordingly for this stage and the time required depends on the size of your organization’s database and the complexity of your customizations. My customer’s database is approximately 50GB and includes a large number of attachments, significant record sharing, and a complex set of entity customizations to accommodate their xRM system. Running this database through the Organization Import wizard from CRM 2011 to CRM 2013 can take a few hours depending on the resources assigned to the server performing the upgrade. With the steps outlined above, you can see that we need to perform this Organization Import wizard three times. This ALSO includes performing the database backup, copy from one system to the next, and a full database restore on the target system before running the Organization Import Wizard.  Assuming all goes smoothly, this process can take up an entire day for our team.

So your team should plan accordingly:

• Do you have the sufficient infrastructure in place to upgrade?
• Do you have people on your team to manage the infrastructure?
• Do you have the time required to upgrade the database included in your overall project plan?

Answers to each of these questions will entirely depend on your organization’s situation but asking and answering them before diving in can be critical to keeping your migration on track.

In following posts, I think we have a few more things to discuss around the database migration.  I will discuss some detailed issues we encountered during the database migration steps and how we addressed them, and a few things we did to streamline our development process. I will also discuss what actually happens to your database once you upgrade and how that can impact subsequent stages of the upgrade process.

As always, comments, suggestions and corrections are always welcome!