Revisit - Part 2: Analyze, plan & rebuild the current solution
In the first part we wrote about the possible approaches for migrating from on-premises systems to the cloud. In part two, we 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 goal 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 goal of the first interview is to get a feeling of how the system is being 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 this Job-Shadowing we get a great impression on how the current System is being used. We 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 focus 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 focus on the interactions done in the Dynamics system, but don’t forget about the surrounding software systems, often there are several integrations that also must be considered moving to the cloud.
In the interview we ask the following questions for every entity of the Dynamics System 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 an impression on how the system is being used in daily business. We setup a meeting with the system admins and if present, the inhouse developers of the Dynamics System to get an technical overview. Here we focus on installed solutions and integrations with 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?
The best case scenario: we find one solution with all customization. The worst case scenario: we find multiple or even worse, none solutions, 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 this way of questioning in mind, we can watch out for new features in the 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”.
Hint: use the options “Include Attribute location in Forms” (1) and “Export all attributes in one sheet” (2) in Meta Data Document Generator for an better overview.. 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 JavaScripts, 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 it will take. 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.
- Complete the list of entities that must be migrated.
- Create an Excel sheet with Entities and Fields that must be migrated.
- Plan work items for the modernization work that must be done regarding to JavaScripts, plugins, and integrations.
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 JavaScript, plugin’s, charts, … and integrations to surrounding systems. Bear in mind that some old customizations or integrations can maybe 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.
We recommend to create three environments of a Dynamics 365 Instance:
- DEV (Sandbox)
- TEST (Sandbox)
- PROD (Production)
The DEV-Environment will be used to implement the changes. The TEST-Environment will be used to test and get an acceptance from the Power User. The PROD-Environment will be used for the Production itself. To provide the best experience to propagate changes from one Environment ot another we use a Azure DevOps-Deployment-Pipeline. So also in future changes, the Dynamics 365 System will be able to quickly adapt to changes made and have a defined process how changes will be introduced in DEV and propagate till PROD.
In the next
article, we will go into the options we see for data migration in context of the “greenfield” approach.
Links
