<aside> 🧭

Navigation:


</aside>

Summary

The data migration process requires a methodological approach to address any errors generated by our validation tests once the data is transferred. The data migration process must be accompanied by a “Troubleshooting” process. The latter should provide appropriate, accurate and relevant solutions to help make the data migration a success.

Two types of errors are possible: a generic type error and a specific type error. Because of the content of errors generated by the CRM platform, it is natural to categorize them according to its two types.

To provide a better understanding of the content of these errors (generic and specific), tools are available (platform log, CRM trace log, server log, SQL query tracking, decompilation of .NET Framework CRM services). Thus, using these tools will generate a process (containing inclusive steps), creating inclusive levels of Troubleshooting. Once the errors are entered in a transparent manner, the solutions can be applied and thus put an end to the error generated by the platform.

Finally, the white paper shows how much CRM service contract extensions (“EntityServiceInternal<T>”) could play a key role in a problem-solving process.

Keywords

Dynamics 365, Data Migration, Dynamics CRM, Troubleshooting, CRM Trace, CRM Exceptions, Event Viewer, Decompiler, Dynamics Link Library (DLL), MS SQL Profiler, Stored Procedures, OrganizationServiceFault, Database, FaultException, C#, CRM SDK365, Microsoft.Crm.ObjectModel, Asynchronous CRM services, Synchronous CRM services.

Confidentiality

The white paper does not provide any confidential client data related to data migration. All the code in this white paper is only related to the CRM SDK365 code.

INTRODUCTION: How to resolve a post-data migration error in Dynamics 365?

Troubleshooting is a systematic approach to problem solving that could used to find and resolve problems related to asynchronous and synchronous CRM services. The first step is to collect information related to the problem, such as undesirable behavior, a lack of expected functionality, or a crash in functionality related to the triggering of services (synchronous and asynchronous) that rely on CRM service contracts (Create Request, Update Request, SetState Request, etc.), etc.

Context : data migration phases

The migration from the CRM 2011 database to the D365 database takes place in an "unrestricted" environment from which we had access to all services and components of the Dynamics 365 platform. Our migration process has been executed in 4 steps:

Step 0 : Creating technical requirements

Step 1 : Data Preparation Process

Data related to the CRM security model (Team, Business Unit, System User and Queue)

Data related to CRM Entity Configuration Model (Solution, Solution Component, Localized Label)

Step 2 : Data Transfer Process

Transfer by Groups and Zones

Step 3 : Data finalization process

Finalize related to symmetrical indexes and keys

Finalization related to deploying CRM components using SDK