Avoiding disaster: Three major pitfalls in CRM data migration you need to know

All businesses collect data on prospects and customers, whether in a CRM system or not. And when it comes time to implement CRM, or to replace an existing CRM product, one of the first concerns is how to migrate your existing data.

The people who understand your data the most, and can help make critical decisions during the migration process, are usually the most valuable and busiest people in your organisation. Yet the implementation of a CRM system needs to be done without adversely affecting customers, or causing undue stress on already-busy, key employees.

Common uncertainties going through the minds of business leaders when migrating to new systems include:

  • When do we stop using the old system and start using the new one?
  • Should we run the two systems side-by-side just in case?
  • What if the support department can’t find information fast enough?
  • Our sales prospecting relies heavily on having information in a specific format, will that be maintained?
  • Can the new system be integrated with our phone system?
  • How will stored emails be migrated?
  • Will the new system enable us to work remotely?

In this article I’m going to explore 3 common pitfalls of data migration that I’ve encountered through decades of CRM system implementation. I’ll also share my advice as to what you can do to mitigate the risks.

Pitfall no. 1: Poor data modelling

Any new CRM system will typically bring enhanced capabilities over existing systems. For example, a modern CRM is likely to provide more granular modelling of customer organisations and people, compared to older systems like GoldMine or ACT! - legacy systems that are contact centric. Then there are activities. Older systems have a limited ability to link an activity to multiple other record types.

How to avoid the pitfall?

Critically consider each data entity in your old system. Don’t make the mistake of replicating an old outdated model in the new system. Make sure you understand the new system’s capabilities, and remodel your data to fit with the new system.

Pitfall no. 2: Analysis paralysis

At the start of a project we’re frequently told that the data in the old system is messy, badly maintained, and needs cleaning up before migration can start. There may be some elements that do need cleaning up, but in our experience this can lead to something we’ve written about before - analysis paralysis - when the fear of making an error, or forgoing a superior solution, outweighs the expectation or value of success in a decision made in a timely manner.

For example, let’s say you need to tidy up duplicates. The contact named Fred Smith has two records, and his phone number is different on each record. You could take the view that all the ambiguous records should be sorted out before the migration, and the correct number identified. You might even call the numbers just to be sure. Once your users start to clean-up data, they’re likely to spot all kinds of other issues, for example:

  • Duplicates contact records with different email addresses – which one do you keep?
  • Different contact records that share the same email address – which is the correct record to keep?
  • Address data entered inconsistently - sometimes the city is in the address field. Sometimes address records are all capitalised. There can be any number of inconsistencies, but is there a way in which bulk-changes can be made, or must it be done one record at a time?
  • Telephone numbering is inconsistent. Sometimes there’s an international dialling code with a bracket for the prefix – e.g. +44 (0)1234 567890 – sometimes not. Again, can you easily make bulk changes, or can it be done through programming?

How to avoid the pitfall?

There may be some simple clean-up jobs that can be done in a spreadsheet or database beforehand. In our experience, it is much more efficient to import the data as-is. Then, once it is in the new system, you will have far more capabilities to make bulk changes, merge duplicate records, and address data quality.

For more complicated data transformation jobs between old and new systems, at times I have resorted to writing programs to automatically transform the data and associated records - for example when there’s an important relationship between organisations or people.

Data naturally decays over time. Therefore, maintaining the quality of your data needs to become an on-going activity.

Pitfall no. 3: Missing data

One of the primary reasons businesses implement a CRM is to get rid of spreadsheets. But if the new system goes live and people immediately find data is missing, they’re going to find workarounds typically through reintroducing spreadsheets!

Missing data dents trust in the new system. The result being that you’ll need to work doubly hard to wean people off their trusty spreadsheets. Old habits can be very hard to break and need little excuse to be maintained!

While we’re on the topic of spreadsheets, great as they are, they’re no place for storing customer information and related data, e.g. service dates, phone calls, events, marketing information, and so on. Such data really should be in a centralised system such as a CRM system.

How to avoid the pitfall?

The way to avoid missing data is by making sure you have unique references from the old system stored in the new system. Most database or CRM systems will have a unique identifier, or ID, for each record type. For instance, ACME Inc. will have ID 456, whereas Eagle Lighting Ltd will have an ID 789.

It’s super-important that the ID is stored in the new system, creating a specific field name for it, e.g. OldSystemID. This way, if you do discover missing data, it’s relatively straight forward to export the data from the old system again, leveraging the unique ID, and to import it into the new system.

Be aware that IDs are often not visible in a standard export. You may need to go to advanced options and specifically include the relevant column. Or, in the case of ACT! or GoldMine, use SQL server or Access to query the data.


A lack of buy-in from users is enemy number one when it comes to the success or failure of your CRM project. Data migration is of utmost importance, yet I’ve seen plenty of examples where this has gone badly wrong. For example:

  • A business came to us having migrated from GoldMine to SalesForce. Because the data hadn’t been modelled correctly, users were not able to use the new system, and abandoned the SalesForce altogether. The investment was wasted.
  • Another client experienced an incomplete migration – i.e., missing data. They ended up in a situation where they were having to use both old and new systems. To further compound the problem, the situation necessitated the introduction of a new, onerous process for the creation and storing of ID numbers between the two systems (in a spreadsheet!).

When tackling CRM system implementation, you must be open to the reality that data migration is hard. To get it right requires an understanding of data and the analytical skills to interpret what that data does for your business, and how it can be leveraged by a CRM system to provide meaningful business outcomes. This requires both an understanding of business processes and experience using tools such as SQL Server, Access, MySQL and advanced Excel techniques and formulas.

In addition, the capabilities of export and import functions in both old and new systems can sometimes be a challenge. One that might best be addressed by writing a bespoke import program.

When embarking on a data migration exercise, be sure to remind yourself of the 3 pitfalls:

  • Poor data modelling
  • Analysis paralysis
  • Missing data