<aside> 🧭
Navigation:
</aside>
The data migration from Dynamics CRM 2011 (on premise) to Microsoft Dynamics 365 (on premise, Version 8.2) means to migrate the business data, system data and metadata from CRM 2011 to D365. This process requires a methodology adapted to the D365 platform because it is carried out in a "big bang" approach considering the technological context and technical constraints that continually put pressure on the CRM data and metadata transfer process.
The methodology is characterized by a process in terms of strategy and dynamics (stages), which is supported by .NET tools, Dynamics 365, and SQL Server technologies. So, these tools have helped us with the implementation of our strategies: organizing our data model, grouping, and ordering our entities, excluding our entities from the process, and adjusting our migration code. In addition, these tools help us in every step of the process that we had previously established: creating the essential requirements, preparing the basic data, transferring the data, and finalizing the data.
Data Migration, big bang approach, methodology, metadata, D365, Dynamics 365 On-Premise, Dynamics CRM On-Premise, Microsoft SQL server 2017, SSIS, SQL Server Integration Services, .NET Dynamic Link Library (DLL), Jet Brains Decompiler.
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 (downloadable for free on the Web) .
In general, a data migration is a mass movement of data from a source to a destination. The data movement can be performed according to following approaches: the "big bang" approach and the “phase " approach.
The "Big Bang" approach means that the migration takes place only once and we know when it starts and when it ends. This approach requires, in principle, a ”shut down” of the system including the data source to be migrated. On the other hand, the phased approach, although it complicates the migration process because the data migrated to the destination has been modified in the original source, allows smaller pieces of data (and metadata) to be migrated.
Whatever approach is chosen, data migration takes place in a specific scenario, a scenario determined by its technological environment. Before describing our scenario, let us first establish the existing and potential list of options related to data migration.
Without emphasizing the technical aspect of a case, in this case, whether it is a "Cloud" technology (cloud technology) or an "on Premise" technology (on-site technology), there are several execution contexts[1] :
From these options, could be extracted the cases of so-called figures specific to each execution context mentioned in the table above (types a, b, c, d, and e). So, what is a specific option?
A specific scenario is characterized by the following three elements: the data and metadata structure, the technology or platform in which the transfer is constrained and the technological context, and finally, our last element, which is the version and build number of the platform.
Description of option “type A”: from database to database
Description of option “type B”: from database to service
Description of option “type C”: from « flat file » to database
Description of option “type D”: from « flat file » to « flat File »
Description of “type E”: from service to service
Before the list of types mentioned above, it should be noted that our data migration takes place in TYPE A and more precisely in TYPE a-3.
Migration is the migration of data considering the three elements of our definition regarding our option:
