Rodrigo Groener
This is the first part of a series of blog posts about how we migrate our customers Dynamics 365 CRM instances to the cloud. In the next weeks I will share with you my experience, lessons learned, pain points and solutions from the last four years, where we had multiple projects that involved a data and functionality migration to a Dynamics 365 CRM instance.
In the first part we’ll have a look at the possible approaches for migrating from on-premises systems to the cloud and which option we typically choose in our projects. In practice we see three approaches.
Typically, a customer is using a Dynamics 365 Customer Engagement (on-premises) instance for serval years and wants to migrate to the cloud. The instance is grown over the years in size of records and in number of customizations. After an initial meeting with the customer, we make a first analysis of their dynamics instance, where we take a look at the installed solutions, count the total number of records in the entities and interview some power users how their day-to-day job looks like in the CRM system. In most cases, we find that even the power users only use a friction of the provided functionality of the once developed or bought solutions. Furthermore, we find plugins that aren’t cloud ready. A lot of JavaScript code that needs manual investigation if it is even used or not and, on top, all JavaScript code must be updated for the unified interface. The results of this first short analysis typically, if not already requested by the customer, leads to the desire to make a fresh, clean start with the new cloud system. That’s why every so called “migration” project also includes intensive cleanup and modernization tasks besides the prominent data migration. Here the “brownfield” and “greenfield” approaches comes into play.
Remove unused fields and entities from solutions Remove unused managed solutions Remove unused plugins and workflows Remove unused and unsupported client-side code Data cleanup. Delete unused data rows or define which data rows will be migrated
The Microsoft FastTrack Team provides tools to migrate on premises environments to the cloud for eligible customers. The migration is performed by both the Microsoft partner and the customer. From a high-level perspective the process includes the following steps. You start by taking a database backup of your on-premises system that you upload to a blob storage in Azure. From here you use the provided VMs to upgrade your environment across all versions until you reach Dynamics CRM 9.0. You need at least a Dynamics CRM 2011 and SQL Server 2008. For example, if you start with a CRM 2013 instance, you first upload a DB Backup, use the provided VMs to upgrade from 2013 to 2015, then from 2015 to 2016, from 2016 to CRM 9.0. As a last step you use a tool that maps the on-prem users to the Azure Active Directory users and from thereon migrate your data including all solutions to a Dataverse instance.
When to use this approach? Large CRM installations at eligible customers where it’s required to have the data and functionality as in the on-premises instance. Don’t consider it as a silver bullet because there are still cleanup and modernization tasks that must be done.
At a high level, this approach consists of two steps: import existing solution and migration data. In contrast to the lift and shift approach, we start with an empty Dataverse instance where we import the existing solution with all customizations and afterwards copy over the data from the old on premises instance. Dependent on the technical debts of the source system, it’s necessary to first customize the unmanaged solution beforehand importing it to the online instance. Therefore, we setup an extra development environment on premises where we can cleanup and modernize the solution.
When to use this approach? CRM installations where the custom solution doesn’t need a lot of modernization tasks, because there is a little to no technical debt.
At a high level, this approach consists of two steps: build new solution and migrate data. This approach is very similar to the “brownfield” approach. Instead of using the old solution, we build up a completely new solution. This approach pays out if the old system has heavy technical debt, or there are many unused parts in the system. Typically, we also use this approach where only a few fields were added to the system entities and nearly no other customizations. For example, customers that heavily rely on the sales process and mail tracking feature. Using this approach instead of the brownfield one, the customer can directly benefit from new out of the box features in the online environment.
When to use this approach? CRM installations where the custom solution has nearly no customizations or installations that suffer from heavy technical debt.
At our clients we mostly use the greenfield approach, due to the wish for a fresh start over without technical debt. Additionally, we install a preconfigured solution for the german market. This allows us to not completely start from scratch.
In the next article, I will provide more details about how we analyze the source solutions for the rebuild.
Autor des Beitrags
Gestartet als Hobby in der Schulzeit Anfang der 2000er Jahre und ersten Taschengeldaufträgen für Websites im Bekanntenkreis auf Basis von PHP, MySQL sowie HTML, hat Rodrigo seine Passion für das Entwickeln von Anwendungen bis heute nicht verloren.
Wir sind ein Software-Unternehmen mit Hauptsitz in Karlsruhe und auf die Umsetzung von Digitalstrategien durch vernetzte Cloud-Anwendungen spezialisiert. Wir sind Microsoft-Partner und erweitern Standard-Anwendungen bei Bedarf – egal ob Modernisierung, Integration, Implementierung von CRM- oder ERP-Systemen, Cloud Security oder Identity- und Access-Management: Wir unterstützen Sie!
Mehr über uns
Mit unserem Newsletter informieren wir Sie stets über die neuesten Blogbeiträge,
Webcasts und weiteren spannenden Themen rund um die Digitalisierung.