0 Minuten Lesezeit

Teile den Artikel!

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.

  1. Lift and Shift (FastTrack Migration Program)
  2. Import Solution (Brownfield) and Data Migration
  3. New Solution (Greenfield) and Data Migration

Why it’s mostly more than a pure migration project?

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.

Cleanup Tasks

  • 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

Modernization Tasks

  • Move from integration built directly on the SQL server to Logic Apps and Azure Functions calling the Web API
  • Move from full trust plugins to sandbox plugins
  • Move from CRM workflows to Power Automate cloud flows
  • Transit to unified interface and app model
  • Use Power BI for reports instead of SQL Server Reporting Services (SSRS)

The lift and shift approach (FastTrack migration program)

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.

Pros

  • All data will be migrated to the cloud including audit logs

Cons

  • Need to be eligible for the FastTrack program
  • Still a lot of work has be done due to technical debt (SQL Server Integrations, Full Trust plugins, unsupported client-side java script code)

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.

The “brownfield” approach

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 depts 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.

  1. Extra development environment to cleanup and modernize solution
  2. Initial unmanaged solution import to Dataverse development environment
  3. Additional modernization tasks
  4. Data migration

Pros

  • Entity Metadata (Entity Names, Field Names, Field Types) of custom Entities stays the same which keeps the data migration simpler

Cons

  • Modernization Tasks
  • Extra tooling for data migration required

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.

The “greenfield” approach

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.

  1. Create new unmanaged solution in Dataverse development environment
  2. Rebuild the solution components
  3. Data migration

Pros

  • No modernization tasks
  • Clean start over with all out of the box features

Cons

  • Rebuild of solution can be time consuming.
  • Entity Metadata (Entity Names, Field Names, Field Types) of custom Entities can change, which must be considered in the migration
  • Extra tooling for data migration required

When to use this approach? CRM installations where the custom solution has nearly no customizations or installations that suffer from heavy technical debt.

Witch approach do we use most?

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.

Links

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. Hierbei hat ihn von Anfang an die Frage „Ok, das funktioniert jetzt, aber wie mache ich das eigentlich richtig?“ dazu motiviert, immer Neues zu lernen. Sein Studium der Elektrotechnik fiel außerhalb der Klausurphase meist seinem Nebenjob als Softwareentwickler sowie dem privaten Studium von Softwaredesign und -architektur zum Opfer. So entschied er sich, seine Passion zum Beruf zu machen und kam im Jahr 2014 als Student zur Objektkultur. Hier betreut er nun seit 2016 unsere Kunden bei Herausforderungen im Bereich Individualentwicklung und Softwarearchitektur. Hierbei entstanden Lösungen auf Basis von Azure PaaS-Diensten, Dynamics 365 und der Microsoft Power Plattform.
Da es neben Büchern und Softwarekonferenzbeiträgen vor allem Blog-Artikel waren, die ihm auf seiner Reise in den letzten 20 Jahren geholfen haben in neue Themen einzutauchen, möchte er seine Erfahrungen aus dem Projektalltag hier auf dem Blog teilen.