How to migrate Dynamics CRM to Dynamics 365 ( in 10 steps or more)

Migrating Dynamics CRM to the cloud is not a new topic for us. In the past, we have analyzed the advantages and disadvantages of such a migration, in order to encourage businesses to make informed decisions about the systems they use and through which departments operate.

Considering that a well-informed customer has decided to migrate to an online environment and requests the services of a Microsoft implementation partner to migrate Dynamics CRM to Dynamics 365, the optimal migration process often remains unknown to him. Most of them realize after the migration that their application has lost essential functionality, the processes are different, or that the data import was incomplete, leading to a negative impression on Dynamics 365 systems.

In this article, we aim to define an optimal migration process, in 10 steps, to ensure that the migration from Dynamics CRM to Dynamics 365 is done according to correct standards. Whether you are an implementation partner starting your journey or a business that wants to know more about migration, we hope you will find this article informative and apply this process to your implementations.

Before describing the process itself, we need to focus on some bits of information that are essential for the client, and that they must fully understand before migrating.

Business considerations

Licensing

When deciding to migrate a Dynamics CRM to the cloud, one of the key factors to consider is the licensing model. For applications in the Dynamics 365 suite, Microsoft relies on a well-established model among modern SaaS services, namely the one based on monthly subscription, otherwise known as the pay-as-you-go model. This licensing model is subject to recurring operating expenses, a possible obstacle for companies that cannot afford technological costs at an operational level.

GDPR

Another decisive factor in approving the migration decision may be the protection of personal data. If the migrated CRM application stores our customers’ personal data, we must take all the necessary legal actions in order to ensure that the migrated data can be stored outside the country or, in some cases, outside the continent.

Technical Considerations

Dynamics CRM on-prem version

Before starting the migration process is important to identify the version of Dynamics CRM in the on-prem environment. It is recommended that before migrating to the online environment, the on-premise Dynamics CRM be updated to the latest version (at least v9).

The migration between older versions must be done progressively. We cannot simply jump directly from Dynamics CRM 2011 to Dynamics 365. Such an implementation will require us to progressively migrate the application from 2011 to 2013, from 2013 to 2015, 2015 to 2016, and only then can we talk about the possibility to migrating to Dynamics 365. How much version of installed CRM is older, the more difficult the migration will be, as customizations and application code will be “deprecated”, ie using outdated methods and technologies, which are no longer in the quality standards imposed by Microsoft for 2021.

Database migration system

Microsoft recommends that any migration of Dynamics CRM from an on-prem environment to an online environment be done using Fast Track. This is a service provided by Microsoft for migrating on-premise applications from the online environment. More information about eligibility here:

https://cloudpartners.transform.microsoft.com/resources/fasttrack

To migrate the Dynamics CRM application from the on-prem environment to Dynamics 365, the Microsoft Partner works alongside Microsoft and Fast Track to prepare the database and application for their new home. The final migration will be performed after several DRY RUNS, which aim to verify the compatibility of the on-prem solution with the Dynamics 365 environment.

Custom functionality implications

Any migration plan should aim to ensure that the impact on productivity is minimal. We should therefore consider that when migrating the CRM application to the online environment a number of features may be affected. This depends on the degree of customization of the application and how the customizations were performed. Adapting those customizations to the new environment thus becomes a crucial priority in order to preserve the functionality of our applications.

If all potential blockers have been prevented or resolved, it is time to move on to preparing the Dynamics CRM migration plan. It should be borne in mind that the migration process may differ depending on the customer’s needs and the customer’s internal processes. The plan outlined below represents only a series of actions that are generally required by any migration. In practice, business needs differ from client to client. That’s why the LINKSOFT team meticulously customizes the migration plan for each implementation.

Generic plan for migrating Dynamics CRM on-prem to Dynamics 365 online :

STEP 1
Preparing Dynamics 365 environments

Point 0 of the migration is the opening of two online environments, an isolated test environment (Sandbox) and the production environment, the final destination of our CRM. This step is done exclusively by the implementation partner after the migration decision has been taken at the client level.

STEP 2
Evaluation phase

The first major phase of any migration is the evaluation of the on-premise Dynamics CRM application. It is recommended that this assessment be made both technically and in terms of business processes.

From a technical point of view, the evaluation of the application is made to ensure that the functionalities will have the same behavior once migrated in the online environment. This ensures that at the end-user level there are no major differences in User Experience.

The evaluation of business processes is performed in order to identify areas where processes can be optimized, or redesigned for the Dynamics 365 environment. We look at business processes from both a technical perspective and a functional one and prepare testing scenarios based on the knowledge acquired in this phase. We also look to identify the need for any training requirements, if the there the difference between the on-premises environment and the online one is substantial.

I. Technical evaluation

Both the implementation partner team and the client’s technical representatives participate in the technical evaluation in order to identify all the elements that need to be modified or adapted in the CRM migration. Also, for implementations with a very large number of users, it is recommended that the Microsoft team be involved in the evaluation stage. Microsoft engineers can provide a number of tools with which we can scan the application on local servers and that can automatically generate a list of problems to be solved before migration. What we evaluate in this phase:

JavaScripts

Some methods used in JavaScript codes may become deprecated or unsupported for use in the online environment. A complete list of major offenders can be obtained by using the tools that Microsoft provides for code analysis. We should look to rewrite the code so that it is 100% compliant with the new environment.

Plugins

As with JavaScript, the methods used at the plugin level can be deprecated or unsupported. At this point, we also consider the 2-minute processing limitation imposed by Microsoft on processes running in Dynamics 365 environments. It is also necessary to isolate plug-ins at the Sandbox level and test functionality before integration.

Third-party integrations

Probably the most challenging technical aspect is checking the way in which the integration interfaces were developed for third-party applications. The implementation partner and the third-party software manufacturers must work together to prepare an adaption plan for the new environment. This process may involve:

-changing the authentication method and, ideally, creating new endpoints.
– a total rewrite of the interface if an unsupported or deprecated integration method was used. This is a fairly common case for old implementations.
– replacing the third-party integration interfaces with a Dynamics 365 connector. In the online environment, many integrations can be performed using pre-built connectors, eliminating the need for further developments.

Reporting methods

Reports that use SQL procedures cannot be used in Dynamics 365 online.
All reports must be rewritten using either Fetch XML or Power BI.

Console applications

We also look at whether there are console applications that need to be replaced or adapted to the new online environment. Depending on their complexity, the decision may be to rewrite them using other means (eg Microsoft Flow) or to adapt them so that they can be used together with Dynamics 365. We need to make sure that we have full access to the server where the console application is installed and that the server can connect to Dynamics 365.

SQL database changes, stored procedures/triggers

The decision, in this case, is a simple one. Since the SQL language is not supported in the Dynamics 365 online environment, we will have to rewrite everything using supported methods.

Portal

The Dynamics 365 online portal is fundamentally different from the on-prem Dynamics CRM portal. The online portal is part of the Power Platform suite and is constructed using Power Apps allowing native integration natively with the Dynamics 365 application through simple configuration.

II. Business process evaluation

In the business process evaluation, the implementation partner, through their business consultants, and the operational representatives of the client perform an in-depth analysis of all processes managed by the CRM. For this analysis, the consulting partner team will try to make the business as efficient as possible so it is important to keep in mind that some processes may require substantial changes in order to be optimized for the new environment.

Business process analysis

At this level, each business process in Dynamics CRM is analyzed both separately and in context, in order to identify optimization opportunities. This is done in order to ensure the online application can perform at maximum performance, using as few resources as possible.

User and Module analysis

Dynamics 365 is built using Power Platform and relies on the Dataverse for storing and managing data. The novelty here is that we can assign roles to users, through which they access the various modules of the Dynamics 365 application, and build model-driven apps for these roles that include specific modules and functionalities. That is why the aim of the analysis is to group users as efficiently as possible in order to ensure a coherent and scalable security structure.

Licenses and access rights

It is very important to identify the type of license and associated rights required for each user. If Dynamics CRM on-prem does not limit us in regards to access based on licensing, the online environment is not so forgiving in this regard. Each user must be granted appropriate licenses and rights or else we may find ourselves in a situation where access to certain modules and entities is limited or non-existent.

STEP 3
Solving the problems identified in the evaluation

Technical problems can be solved both in the on-premise environment or directly in the online environment. The decision on the environment is made according to each issue.

It is recommended that troubleshooting plugins or rewriting unsupported JavaScript methods be deployed in the source Dynamics CRM environment production before migrating to Dynamics 365. This minimizes the risk of additional problems during the final migration. In other words, it is advisable to update the on-premises application as much as possible before the migration, so that our CRM meets most of the Dynamics 365 requirements before being transferred to the new environment.

There is always a possibility that we will encounter some problems that cannot be solved directly in the source environment and may need to be solved directly in the new online environment. These problems will become more apparent after the first DRY RUN.

STEP 4
DRY RUN 1 (Identification)

A dry run is a testing process that simulates the import of data in order to identify what problems still remain in our system, that were not covered in the evaluation stage.

Before starting the initial dry run, Microsoft defines a set of prerequisites that must be met in order to prepare the database for migration. It is very important that all changes to the database are documented, as they will need to be redone before each DRY RUN. The most pressing of these prerequisites is the one concerning the maximum size of the database that is to be migrated. The database cannot exceed a maximum size of 1TB, which means we must find ways to compress it if this standard is not met.

The first DRY RUN is performed by the deployment partner, in close collaboration with Microsoft and, as mentioned before, is the import of the exported database from the on-premises Dynamics CRM environment into the Dynamics 365 online environment.

We can consider that the DRY RUN was performed successfully when the Dynamics 365 CRM application can be accessed online and provides us with all customizations and data from the on-premise environment (even if they are not initially functional).

After the import, the testing of the business processes in the Dynamics 365 online environment follows. The testing is based on the test scenarios prepared during the evaluation and aims to identify the real problems of the system after migration. After testing we will get a real picture of the state of the system as well as a list of problems that will be sent to the development team.

STEP 5
Solving the DRY RUN 1 problems

Solving the identified problems can be done directly in the Dynamics CRM on-premise source environment, and the changes can be migrated using an online solution for retesting. By solving the problems directly in the source environment, we reduce the possibility of their recurrence in the final migration.

If the problems cannot be solved in the source environment, we resort to solving them directly in the online environment. It is important to prepare a series of solutions that will be exported from our testing environment and re-imported after each DRY RUN and after the final migration. We will call these solutions “migration patches”.

Problem-solving also involves the punctual approach of each item of technical evaluation, to ensure that nothing is left to chance. This step should also include the integration of third-party applications with the CRM system. The environment we have created after the import perfectly simulates our final solution, and therefore allows third-party developers to identify the actions that need to be taken in order to integrate with the new application.

STEP 6
DRY RUN 2 (Evaluation)

In performing the second DRY RUN we need to redo the steps described previously, but only after deleting all the data from DRY RUN 1. This ensures that we fully understand the steps and actions needed for the actual migration. Always perform your DRY RUNS into empty environments in order to perfectly simulate the final procedure. This may seem tedious but is an essential work ethic for proper migrations.

We take everything from the top going through migration prerequisites again, we import the database again, the only difference occurring after the import, when we will also import the migration patches, defined in the previous point. We reiterate the testing process with all the steps performed in DRY RUN 1, and depending on the test result, we asses the need for a final DRY RUN.

Optional: If the difference between the on-prem version of Dynamics CRM and the online version, Dynamics 365, is very large, it is recommended that after performing DRY RUN 2 we organize training sessions in order to prepare the client’s team for working in the new online environment.

STEP 7
DRY RUN 3 (Control)

“Practice makes perfect”, and when it comes to essential systems for our customers, it is recommended that we perform a test as necessary in order to ensure that when we make the final migration everything will go smoothly. We perform all the steps from the previous points again and from scratch. We dot the i’s and cross the t’s. We document everything that can be documented about the changes we’ve made and about the functionalities of the new system so that at the time comes for the final migration there are no questions to which the answer starts with “Maybe…”.

From a business point of view, we need to make sure that users are informed about the migration to the new environment, the user account details are prepared and delivered to the teams and everybody is ready to GO LIVE!

From a technical point of view, we need to make sure that all third-party providers for the CRM are informed of the application downtime and the exact moment of migration. Very often the other partner teams have to make changes to their systems during the migration process.

STEP 8
Final Migration

The same repeated ballet, the same steps, the same music, a different venue (the production environment).
We cut all access to the Dynamics CRM application.
We prepare the database for import.
We export the database from Dynamics CRM and import it to Dynamics 365.
We import the migration patches.
We test.
And finally…

STEP 9
GO LIVE!

STEP 10
Final check-up

After a successful migration, we have one more step to perform. We need to make sure that all users are informed about the migration to the new online environment and the disappearance of the on-prem environment. Make sure that all credentials are communicated transmitted, and that the system works properly for each predefined user and group.

Conclusions

Migrating a Dynamics CRM system online is not an small task. It requires months of planning, training, testing, and optimization to ensure that the Dynamics 365 app works properly and provides added value over the on-prem version.

With the increase in size and complexity of the system to be migrated, the number of parties involved, and the effort to be devoted to this process also increase. The steps described in this article are just an essential part of any migration process. In practice, the process can become much longer and more complicated, with migration variables differing fundamentally from implementation to implementation.

LINKSOFT’s recommendation is that any migration be done by an experienced Microsoft Partner. This way we make sure that our application will reach the online environment successfully and in the shortest time possible. However, this article is intended to serve as a best practice guide for beginning professionals. Our promise as Microsoft Gold Partners is to deliver at outstanding quality standards, whether it is through our own implementations or by encouraging others to subscribe to these standards.