How to avoid being caught by some common traps when migrating to Microsoft Dynamics CRM.

Considering the impact on delivery dates, testing, training, regulatory compliance and budget, it is always amazing how often the complexities of migration are overlooked. There are many traps to fall into when implementing your shiny new CRM system but migration is one stick that the underlying business will beat you with. Let’s look at 1o of these traps you want to avoid:

1. Your project plan has one task that says ‘Migrate Data’.

This is very easily done as either the team developing the new system or the vendor, can’t estimate the effort so it is just left as a single item. Don’t do it. Do some analysis that will at least give you a consideration of risk, effort and cost. Without these, managing the expectation of the business will be impossible.

2. Not using an automation tool to migrate data.

In the past we have conducted migrations based on SQL scripts, batch files, custom code etc. Quickly you realise that there are real benefits to automation. For example the new system has 5 new fields in a table. Rather than going back and redeveloping the migration code, you just point the tool (we like using Simego) at it and click update. 1 hour saved and no errors introduced, commit it to source control.

3. Migrating old data that might better be placed in a reporting system.

You should always consider that some data might be better placed in a reporting or document management solution. If you have a ‘end of year’ balance brought forward into a new system, do you need all of last years transactions or can you just lookup a report showing them? Rationalising some of this data can pay dividends in the scale of your migration project.

4. You let the vendor leave out migration or worse make it your entire problem.

Migrating data is risky and can be expensive; your development team knows how their current system works better than anyone. Make sure you have some migration commitment from the vendor before agreeing the deliverables and costs.

5. Assume that the migration with be straightforward because the old system and the new system do the same thing.

The architectural requirements of systems mean that they may have completely differing internal structures and security models. These factors influence the effort of migration by factors of 10. Even simple upgrades between versions can be the same as moving to a different vendor’s.

6. Underestimate the effect of the new security model on migration.

Security models are there to make sure that data is not viewed or manipulated by an unauthorised individual. During migrations it is often necessary to circumvent or assume the identity to extract and insert data. The developers of the current systems could make it extremely difficult for you to move data by using encryption, logic in the user screens and even more esoteric (smart at the time) tricks.

7. Thinking you can sort out the data quality once it is in the new system.

Often a driving reason the move to a new system is that it has better data quality control. For example, we often see telephone numbers saved as ‘TBC’ in an old system and the new system will only allow number to be saved. A significant phase in migration is cleaning the underlying system so that clean data can be stored easily into the new system. Often if you migrate dirty data, even with the best intentions, it loses priority and remains dirty undermining the value of your new system.

8. Underestimating the involvement from the business to clean the data.

As with 7, it is important to realise that users will have to assist in cleaning data. You can make this easier by creating lists of broken records and request rules for your automation tools to follow, but the bottom line is that your users know the data and are generally the best ones to clean it up most efficiently.

9. Not realizing the impact of month/quarter/year ends or other business events on the migration.

Many accounting systems require journaling and retrospective adjustment. Additionally, when picking a date for migration, make sure the business is available and not buried in month end, quarter end, tax year-end, year end or some other business event which requires significant business focus.

10. Not documenting the migration process so no one knows where the data came from!

When migrating data it is often necessary to transform the data several times before it finally resides in the new system. Often a client will ask, why is the address used and not the billing address from the old system? You need to have a method of tracing the source to target and often your automation tools can help to generate documentation.

At xRM Consultancy we are experts at migrating data from a variety of sources into Microsoft Dynamics CRM - talk to us to see how we can help you avoid these data migration traps


This post reproduced/adapted from an original by our friends at Simego