How we migrate Dynamics 365 CRM applications to the cloud (Part 2)

Part 2: Analyze, plan & rebuild the current solution

• Part 1: Approaches to migrate to Dynamics 365 cloud instances
• Part 2: Analyze, plan & rebuild the current solution
• Part 3: Options for data migration
• Part 4: Our tooling for data migration
• Part 5: Migration of activities
• Part 6: Logging and Error Handling

In the first part I wrote about the possible approaches for migrating from on-premises systems to the cloud. In part two, I go deeper on the task that are involved when choosing the “greenfield” approach. We typically take this approach, when we find a customer system with heavy technical debt and thus the wish to start over in the cloud. Therefore, the first step is to analyze the current system with the aim to get a clear picture of what functionality and data has to be migrated to the new cloud system.

Step 1 – Interview the power users

Before we even look at the solution, we setup a meeting with one or two power users of the current system. The aim of the first interview is to get a feeling of how the system is used and what we can abandon in the upcoming rebuild of the solution. We ask the power users to show us how they do their daily work. During the pandemic, this can be done perfectly with screen sharing over Microsoft Teams or similar solutions. I recommend that at least two Power Apps developers/consultants take part in the meeting, so that one can make the interview and the other can concentrate in note taking.

A good question to start the interview is “how do you start your workday?”. Hint: mostly everyone starts their day receiving an e-mail and after that interacting with different software systems. In our case, we concentrate on the interactions done in the dynamics system, but don’t forget about the surrounding software systems, often there are integrations that also must be considered moving to the cloud.

In the interview we ask the following questions for every entity that we get in touch with, while the power users present their daily workflow.

• Which fields are actively used?
• Which fields aren’t in use anymore?
  • Why aren’t they in use anymore?
  • Can we abandon them in the new system?
• Which Activities are being used?
• Are there workflows that get triggered by the customer?
• Which views are in use? Which views can we abandon?
• Is there data that we don’t need to migrate?

At the end, it’s good to ask if we miss a co-worker that has a different view of the system. E.g. Salespeople that points to marketing. If we identify someone, we try to setup a separate meeting.

For step 1 the desired output is:

• A list of entities, their views and forms that are used.
• A list of fields on the used forms that can be discarded.
• A list of business processes that are actively used.
• A list of used activities used in the system.

Step 2 – Interview the system admins

After we got a feeling how the system is used in daily life. We setup a meeting with the system admins and if present, the inhouse developers of the dynamics system to get a technical overview. Here we focus on installed solutions and integrations to other systems.

• Which solution is the main solution regarding customizations? Are there multiple solutions? And if yes, how are they structured?
• What third party solutions are installed and why? Are there third-party solutions that aren’t used anymore?
• Are there outgoing or ingoing (data) integrations? And if yes, how are they implemented? Can we abdomen some of them?

In best case we find one solution with all customization. In worst case we find multiple or even worse, we find none, which means all customizations sit directly on the unmanaged layer in production.

It’s important to focus on the “why”. We want to know what use cases drove the decision to buy third party solutions or build integrations to other systems. With the why in mind, we can watch out for new features on Power Apps Platform or Azure that can maybe replace the functionality out of the box.

Do not expect too much from the interview of the IT admins. If they aren’t the one that developed the system, they won’t be able to deliver much information. Often systems are developed over years, from externals and that left the company long time ago. The result is the reason why we choose the “greenfield” approach, a messy state.

For step 2 the desired output is:

• To know which solution is the main solution regarding customizations.
• A list of third-party installations that are actively used.
• A list of Integrations to other systems that must be present in the new system.

Step 3 – Analyze the solutions & Plan work items

Now we take the notes from the interviews as the starting point to our own walkthrough, where we extend the list of entities, forms, and fields to migrate. We add components that remains hidden to the normal user, like java scripts, plugins, and workflows by looking into the solution designer.

Now we use the XrmToolBox to create an Excel workbook with all fields of the entities that we want to migrate. Therefore, we use the “Metadata Document Generator”. Tipp: use the options “include Attribute location in Forms” and “Export all attributes in one sheet”. With this you get all attributes in one excel sheet instead one sheet per entity and you can filter attributes that are visible to the users. That’s great starting point to add additional columns, especially one column to classify if a field will be migrated or not and one for comments.

Additionally we add a sheet to the excel workbook where we list all the work that must be done around the “nonvisible” components of the system like java scripts, plugins and co. As a product, we get the initial version of our migration plan with all tasks that lie in front of us. We also estimate the time we need to get a rough figure how long we will need. This is the last reasonable exit to switch to the brownfield or lift and shift approach if there is too much work in sight for the migration of the functionality and data.

1. Complete the list of entities that must be migrated.
2. Create an Excel sheet with Entities and Fields that must be migrated.
3. Plan work items for the modernization work that must be done regarding to java scripts, plugins, and integrations.

Tipp: use the options “Include Attribute location in Forms” and “Export all attributes in one sheet” in Meta Data Document Generator for an better overview.

Step 4 – Rebuild the solution

Now it’s time to get our hands dirty. We spin up a new developer environment in the Power Platform portal, create a new empty solution upon the dynamics products we need and start by adding the custom fields and entities that are marked for migration. After all fields and entities are created in the new solution, we can start work in parallel building the needed java script, plugin’s, charts, … and integrations to surrounding systems. Have in mind that some old customizations or integrations maybe can be replaced by new out of the box features. Also removing complexity and only reimplementing a simpler version in the new system can help to be faster and at the same time leads to a cleaner system.

In the next article, I will go into the options we see for data migration in context of the “greenfield” approach.

Links

• Part 3: Options for data migration
• Metadata Document Generator · XrmToolBox