We all
want to get to latest version of Dynamic CRM as we are interested in getting
new features attached to it.
Here in this blog I would try to list down
following
- Considering
various Migration activities
- Considering
some important factors when doing migration
- Understanding
the reason for your migration – list down features that are not achievable in
existing CRM
I have
list down few of my thoughts, which I can think of when doing Dynamic CRM migration
I have encounter specific issue related to Product Migration, you can look at same here.
Tools to consider for Data Migration
CRM Configuration Migration is the one tool I found very
easy going for limited data migration.
Refer below blog for few effective tips for data migration
Pre-Configuration
in Dynamic CRM
Business Units & Security Roles
Do we
need to configure CRM with business hierarchy and have security around various
users operating within dynamic CRM?
Does
our business function across the globe?
The
answer to such question will involve us in configuring
business units and security role.
Users
Configuration
A
user must be configured in advance before we initiate the actual data migration
within Dynamic CRM,
so that the records can be associated with their specific owner.
What
about the users who might have left the organization and which specific user
must be used to replace
when doing migration.
There are two types of
records in dynamic CRM
Organization Owned: Like Products, Price-list, Competitors,
Currency, etc.
User Owned: Like Contacts, Accounts, Sales Order,
Invoice, etc. The records that are owned by a user or team, they’re connected
to a business unit and specific security roles for the business unit.
Therefore, these entities participate in role-based security.
Know the size of
the database
- How many customers we are migrating? (This typically decide the
duration of migration activity as most of the entities are directly
or indirectly related to customer base)
- What all other entities linked to Contacts especially if there are
some parent entity to contact like Account, Leads, or Organization? Can we
list those?
Is Data Cleaning
Required?
During the data migration phase, we get an opportunity to analyses
if we can get rid of garbage data by not taking it forward to another fresh
CRM. We can query the system to verify for what data needs to be migrated. Some
of the example to query garbage data are:
- Contact records that are not having any unique
identification like email ID, phone number, social security number, etc.
- Records that had created during the testing via some
service accounts.
- How many nulls or empty strings are there for some
entities?
- Are we having duplicate records with same unique
identification?
Consider Time &
Cost factor
It is the most crucial factor in
deciding a migration process.
- There are certain tools, which do
the migration at their best, but they come with their added cost but save a lot
of time. (Example – Scribe)
- For large-scale data that need to
be migrated an SSIS packages can be a good option where we can also define our
own business conditions for data migration. This option require time and
development efforts.
- Dynamic CRM does come with
default data migration tools as well, provided it require data to be formatted
accordingly
Managing
Workflow and other Triggering operation
Often we have business automation
implemented in our CRM. For example to send, welcome email to a customer when a
contact record is created in system or assign the lead to specific user or
team. We need to be very cautious when doing data migration as they might
trigger the business automation processes that we might not actually be
interested.
Usually workflows are
supposed to be in Draft or OFF state during the migration process and once all
the data is migrated, they can be turned in ACTIVE or ON state.
Some of the processes that are
specific to Dynamic CRM are:
- Deactivate the workflow processes
- Disable the Plugin Steps
- Disable the custom workflow
- Disable Database Indexes – For CRM
On-Premise
- Turn off tracing/logging for better performance.
Doing Trail and
reducing the overall migration Risk
A
recommended approach is to do a trail migration of subset of data and then
after verifying the subset data migrated go for an actual migration.
Once
we start data migration activity in Production environment, start-involving
users to verify the data being migrated. Users know their data very well, they
can identify any invalid entry, and we can reconsider our migration approach.
Comparing
report results provide the best way to verify if certain entities and their
respective data is been properly migrated or not.
Note : When you might be doing migration from CRM 2011 then if reports are build using SQL statement then it has to be converted to Fetch XML based when migrating to Dynamic 365 CRM.
An
example quarterly, monthly sales analysis report.