This is the third post in a series of posts about migrating from Dynamics 365 on-premise to Dynamics 365 Online. The content and topics are from my recent sessions at D365UG Summit and Extreme365.
In Part 1, I blogged about the various reasons of why to move from an on-premise version of Dynamics 365 to Online.
In Part 2, I provided some consideration of when to make the move.
Originally in this part, I was going to discuss the various steps (how) but found that there is a lot of things to consider. This post is about taking inventory of your existing Dynamics CRM system assets and components. Don’t worry, more posts are coming on this topic.
Before you begin your migration project, it is not a bad idea to review what you are getting yourself into. This is a good time to review your existing Dynamics CRM system and begin to consider all its component parts and how they will translate to Dynamics 365 Online.
The first step is to take a full inventory of your current Dynamics CRM system to help you plan how to migrate these items, identify potential issues during your migration and finally, decide if you even need or use some of these assets!
Here is a list of the items you should document:
- 3rd party-add products
- Database size
- Custom Code (Scripts, Plug-ins, etc)
- Reports (SSRS or other)
- Business Readiness
Review Inventory and Plan
Now that you have your list of Dynamics CRM Assets, the next step would be to evaluate this information an put together a strategy. From this list, here are some things to consider:
Data – do you need all that historical data or would this be a good time to clean it up? How big is that database? Remember that you will need to pay per GB above the base 10 GB. If you have a 100GB CRM database, you will need to consider the value of the data being stored and the corresponding subscription requirements or come up with another strategy.
Users – do your user profiles fit a full enterprise user, or just sales or service? Could they utilize team member licenses?
Reports – During your implementation, you likely came up with a list of “must have” reports. Years later, are some of these reports being used? Do they need to be converted or can they just be tossed?
Plug-Ins – If you still need these custom plug-ins for your solution, do you have the source code? You may need to update some of these plug-ins with updated SDK methods or libraries. If you don’t have the source, what will be the strategy to replace this functionality?
Solutions – Are some of your custom solutions managed? Do you have the zip files or even the unmanaged versions? What if you don’t? In a later post I can provide some guidance, but ideally you should have access to the unmanaged solution you may need to update it as part of the migration.
ISVs – For the 3rd party solutions and ISVs, do they have an upgrade path and updated versions? Are they still even in business?
In part 2 I mentioned above the concept of timing. When would be a good time for the business to take on a migration? Busy season may not be ideal, but maybe not during the summer while everyone is on vacation. This could be a part of your inventory list.
Based on the inventory, you may decide that a lot has changed since the initial implementation or it would be a lot of effort to update and migrate the existing solution and this could be a good opportunity to start fresh with a brand new implementation of Dynamics 365 Online and just migrate some key data and re-visit the business requirements and processes.
You now should have an Excel Worksheet filled in with long lists of all you Dynamics 365 Assets. In the next few posts, we will be looking at those lists and dealing with migrating those assets to Dynamics 365 Online. Even if you are on the FastTrack program, these are still things that need to be considered for a Dynamics 365 migration project.
Nick Doelman is a Microsoft Business Solution MVP and is diving into the world of PowerApps, Flow and CDS. Look for some upcoming blog postings on these exciting subjects!