ReadyXRM

Previously on ReadyXRM Blog…

This is the forth post in a series of posts about migrating from Dynamics 365 on-premise to Dynamics 365 Online.  The content and topics are based on my 2017 sessions at D365UG Summit and Extreme365.

I will also be presenting this topic on Thursday, March 29th at the Ottawa IT Community Meetup.

In Part 1, I blogged about the various reasons of why to move from an on-premise version of Dynamics 365 to Online.

In Part 2, I provided some consideration of when to make the move.

In Part 3, I talked about taking an inventory of all your Dynamics 365 assets and putting a plan in place for each of these components.

Entities, Forms, Views and Fields

This post we finally get into some heavy lifting and talk about updating the Dynamics CRM/365 solution components (Entities, Forms, Views, Fields, etc) from your current Dynamics CRM version to the latest Dynamics 365 version.

The latest version of Dynamics 365 CE (v9) has taken some huge leaps in working towards providing modern user interfaces with the Unified Client Interface.  The recent consolidation with the Common Data Service has introduced the concept of Canvas (PowerApps) and Model Driven (Traditional Views and Forms) Apps.  However, you don’t necessarily need to start from scratch.

Chances are that you have invested a lot of time and resources into creating the entities, fields, views and forms in your current CRM system and would like to be able to leverage those investments.

This post outlines a process to update your existing custom on-premise CRM schema defined in your solutions to the latest version of Dynamics 365 Online where you can then use that foundation to update to more modern user experiences.

• Prepare current version solutions
• Step update them to each version of Dynamics CRM/365 to the most recent using on-premise test environments
• Update the solutions as appropriate with new methods and interfaces

There are a couple of important items to note while we update our CRM schema;

• Ideally all your customizations are stored in CRM unmanaged solutions
• You will need to update your CRM database to each major version released, you cannot “skip” versions while upgrading
• Your custom JavaScript/Reports/Plug-Ins will NOT be updated to latest SDK or syntax.  You will need to update this manually

Development/Test Environment for your Current Dynamics CRM System

In order to prepare your existing solutions for updates, we may need to make some modifications to the solutions in order for them to upgrade/migrate.  Ideally these will be done on an isolated development/test on-premise environment.  DO NOT MODIFY YOUR CURRENT PRODUCTION SYSTEM.

I recently posted an article on using Azure DevTest Labs for isolated developer/test environments, but you could also setup a dedicated server or use tools like Hyper-V or VMware.  Another possible solution is to deploy a copy of your system specifically for this task in your existing environment.  The goal would be to have a duplicate (or close to it) of your current production environment.  At this point for migrating to Dynamics 365 online we don’t need to worry about users or data, we are just concerned with the schema customizations.  (We will deal with users and data at a later step).

For example, if you current production environment is CRM 2011, then you would setup a CRM 2011 Test environment and import a backup/copy of your CRM 2011 database to the environment.  Same if you have a CRM 2013 environment.  The process to import a organization database is outlined in this technet article.  As mentioned above, we are not concerned with users so they don’t need to be mapped (with the exception of System Administrator).

I prefer to take a copy of the production environment as it will have all the solutions that end users would be using, however, if you use managed solutions and have a test/dev org with the unmanaged solutions it may be more applicable to use that instead.

If you only have managed solutions and don’t have the original unmanaged, this will be an issue as we will need to export the solution from the step environment to import it to online.  Please refer to this article as a potential method to get an unmanaged version of your solutions.

Note that you could import a CRM 2011 database to a CRM 2013 system (it will upgrade) however I found that the process may fail if you have deprecated JavaScript syntax.  The goal is just upgrade your schema changes.  Updating JavaScript will come as a later step.

Custom JavaScript

Once your test environment setup, what I personally like to do is comment out the content of the custom JavaScript code but leave the function names intact.  As stated above, the upgrade process will not update custom code.

This also would not be a bad time to make a separate backup of your custom JavaScript web resources.

There are different tools that you could use, I find that the Web Resources manager in the XrmToolBox works well, but you could also use Visual Studio.

If you are 100% confident that your code is compatible with the latest SDK methods, you could skip this step, but I find that a lot of code written in CRM 4.0 or CRM 2011 will need some level of refactoring and it also may reference libraries no longer available.

The reason for doing this is that the upgrade process will fail if there are outdated JavaScript functions as we move our solutions up through the CRM versions.  Leaving the function names intact means the trigger events from forms, tabs and fields will remain intact so we can fix those up later.

When we reach our target version (v9) we will then go back and either update our JavaScript functions or replace them with more modern methods (business rules, workflows, etc).  This is the subject of a later post.

In some cases you will also need to remove custom plug-ins from the database and refactor them on the target system.

Upgrading Through Each Dynamics 365/CRM Version

 

Once you have cleaned up your “source” CRM database, you will need to set up a series of “step” environments for each version of Dynamics CRM.  Again, setup isolated environments based on your preference.  Again, I would recommend using Azure DevTest Labs as a quick, inexpensive and easy way to create each environment.  You should be able to use the trial keys provided with the CRM server downloads to install each CRM version.

While you could perform an “in place upgrade” on this one environment, I would instead recommend a separate environment for each D365/CRM version.  You may at some point need to back track your update process as well as reference some other information.  Having a separate instance of each step would be beneficial.  Using Azure DevTest labs you can turn off these environments to preserve your Azure credits and spin them up when needed.

The idea is that you will take your existing CRM organization database, and import it to the next version up.  This will not only import it but update the solution schema to that next particular version.

• CRM 4.0 database can be imported CRM 2011
• CRM 2011 can be imported to CRM 2013
• CRM 2013 can be imported to CRM 2015
• CRM 2015 can be imported to CRM 2016 (or Dynamics 365 v8.1, v8.2)
• Export the solution(s) from the step environment and import to Dynamics 365 Online.

The following is the official chart from Microsoft that details export and import versions for solutions.

Once you have reached a target version of Dynamics 365, you can then take your solution(s) and import them into Dynamics 365 Online.  All your custom entities, forms, fields and views that were created in your original on-premise Dynamics CRM environment will now exist in Dynamics 365 Online.

In Dynamics 365 online, you can then now go and begin to refactor the forms and views to Dynamics 365 formats or even create new forms and interfaces based off these custom entities (Model driven or Canvas based).  Having the entities and fields (and existing forms and views) already defined should make the work much more efficient.

In upcoming Posts I will dive deeper into the following topics;

• Update JavaScript and Custom Code
• Updating Reports
• Migrating Legacy Users
• Migrating Data

Summary

As I mentioned before, there is no “easy button” to move from on-premise to the cloud.  Updating a older CRM system to the modern Dynamics 365 is a lot like renovating an old kitchen, a lot of work but the results could be amazing.

I hope this post provided you with the information and steps required to be able to maintain and leverage your work and investment in a lot of your existing customization and configuration work.

Nick Doelman is a Microsoft Business Applications MVP.  While not working with Dynamics 365 and related technologies he can be found at the gym picking up heavy stuff as he trains for upcoming Powerlifting events.