Upgrading large Microsoft Dynamics 365 Customer Engagement on-prem deployments to online

Despite the fact that most of the communication that Microsoft does regarding Dynamics 365 Customer Engagement focuses on the Online version, there is still quite a large share of customers still using on-premises versions of Dynamics CRM or D365CE. The reasons for this may vary. In some cases, it may be tied to regulatory compliance. Others perceive the security of the online service as less than that of a system hosted in your own data center (a notion that definitely could and should be challenged). However, something also holding many customers back is the fact that they have large complex implementations and they fear that upgrading will be too complicated, take too much time, cost too much money, and be too risky.

I was the solution architect behind an upgrade for a large CRM 2011 system directly to D365CE Online. It had a database of over 300 GB, more than 50 custom entities, some tables containing more 30 million records, more than 10 integrations, and over 100 reports. We started on May 1, 2017 and the organization was up and running in the online version by December 15, 2017. This article will briefly describe some of the takeaways from this project.

Do not assume – know

We started this project by being handed a pre-study recommending an upgrade to on-prem for three reasons:

• The database was very large—over 300 GB
• Over 100 reports
• Many integrations

I do not scare easily, so I started by asking some technically savvy people at Microsoft about the 300 GB database. It turned out that there were quite a few customers in D365CE Online with databases of this size. Yes, you must pay for the extra size, and yes, it does cost more than what you pay for a 1 TB personal OneDrive, but on the other hand, it is as SSD level SQL database stored in at least two geographical locations plus short-term and long-term backup features and calculation costs included. So, in order to be fair, you must compare apples with apples. I also talked to the customer and they did not want to migrate all of the data due to GDPR considerations.

As for the reports, this can really be a problem. When I presented on this subject in a webinar once, I asked what the main reason was for people not upgrading to the cloud, and the majority answered that it was due to complex reports. However, I asked the customer about this and they answered that they only used a maximum of four reports. The reporting functionality has extended a lot over time and now includes Power BI and more. I thought it relevant to ask about what these four reports were. It turned out that they didn't have to be reports at all. When we understood the real business requirement, we saw that one of them turned out to be solvable by just creating a view and putting this view and entity in a Modular App for a specific user group. The customer was excited and they said, "It is much better! Now we can see it real time!". Previously, someone had emailed the users the PDF export of the report. While this may not be a general solution, do try to understand what the business really needs and drill into this and solve it at its root. Often it doesn't have to be a report. Common solutions to replacing a complex SQL report include:

• Precalculate in Dynamics
  • Report with SSRS and FetchXML data source
  • Use a view
  • Use a chart
• Export data to Azure SQL with Data Export Service, aggregate, view with Power BI or similar
• Use document templates for Word or Excel or even Document Core Pack from mscrm-addons.com to create more document-based reports

The last issue that was put forward as a main reason for not going to the cloud was that there were many integrations. I challenged this by saying that there generally was no problem integrating with D365CE Online compared to on-prem. There are some particulars like throttling limitations that need to be considered, but these are quite steep (60,000 API calls every five minutes). Using the Data Export Service and doing parts of the reading from the Azure SQL database can also be both faster and a good way to offload the API a bit. In this case, we were upgrading from CRM 2011 so we had to revise all the code anyway and hence the added overhead to move it online was not too large.

Approaching the challenge

As for the general strategy used, I have adopted a strategy I call 1:1 upgrade. I picked it up from the gurus Joel Lindstrom and Scott Sewell during one of their sessions on upgrades at the CRM User Group Summit. Essentially, it means when upgrading you should not try to fix things, just try to upgrade. I like to make the analogy with refurbishing a house. If you are redoing the kitchen, focus on that, don't start doing the bathroom and bedrooms too.

In concrete steps, the 1:1 method was realized in the following ways:

1. Export the solution from CRM 2011
2. Strip out code and reports
3. Upgrade the solution to Dynamics 365 (8.2) via Dynamics CRM 2013 OnPrem (latest version)
4. Revise forms and other UI logic for 8.2
5. Upgrade code, component by component, and add back into the solution
6. Upgrade integrations, installed in a new hosting environment
7. Migration – as soon as 8.2 solution became fixated from a data model perspective, the migration could be started
8. Test, test, test – and of course fix based on testing

What is important to know is that since the time of this implementation, Microsoft has launched the Dynamics FastTrack program to assist moving a database, by moving the entire database, including customizations to the online system. This is an entirely different procedure, by no means a "next-next-finish" solution, especially for a complex deployment such as this.

Key project decisions

FREE Membership Required to View Full Content:

Joining MSDynamicsWorld.com gives you free, unlimited access to news, analysis, white papers, case studies, product brochures, and more. You can also receive periodic email newsletters with the latest relevant articles and content updates.
Learn more about us here

Get full access

or login