Home | Resources | dq:view Blog | Data Migration | The DOs and DON’Ts of CRM Data Migration

Steve Tuck wrote, on 01 Jul 2008

The DOs and DON’Ts of CRM Data Migration

According to a Gartner Research report, “Eight Steps to Implementing a Successful CRM Project” (October 2006), CRM project failures continue to run at nearly 50%. What the report fails to identify is that a significant number of these failures are due to inadequate data resulting from deficient data migration practices. Poor data quality leads to poor user adoption and poor CRM performance; getting the data migration right is critical to success.

In my experience of dozens of CRM Migration projects there are two key mistakes that are commonly made, to avoid these:

  • Don’t Assume that Migrating Data will be Easy - Companies invest large sums of money, time and effort in buying and customising a new CRM system, but all too often they overlook the challenge of populating it with fit for purpose data, leaving the migration to the last minute and then just dropping data from the legacy system straight into the new system. It’s like buying a new car and selecting the colour and a range of luxury options, but then fitting it with the engine and tyres from your old vehicle and wondering why it performs so badly.
  • Don’t Leave the Data Migration to the Technical Team Alone - Whilst a data migration undoubtedly needs skilled technical staff to understand the physical data models and to extract and load data in an optimised way, the critical area of data transformation requires business knowledge. Key decisions about how information should be translated from one system to another, or how duplicated records should be matched and resolved should be made by a business user and ratified by a governance board.

All too often, the implementation of a new CRM system is seen primarily as a technical challenge. The truth is that, to be successful, a CRM programme requires collaboration between the business and technical teams. The data migration element is not just about plumbing the two systems together; it’s about understanding the contents of the data and its business context and constructing a process that delivers data that is optimised to perform in the new system. This requires time and effort; here are 8 steps of my own for ensuring a successful CRM Data Migration:

  • Establish a governance board that sits above both the CRM Implementation and CRM Data Migration Project. This should consist of representatives from the business and IT.
  • Start the CRM Data Migration project at the same time as work on the tailoring and implementation of the CRM system itself begins. The migration project will often identify shortcomings in the system design - it’s best to identify these as early as possible so that they can be properly address rather than worked around.
  • Identify all of the source systems. Unless you are doing a like-for-like system replacement your new CRM system it is likely that the new system will need to be populated with information extracted from a number of legacy applications.
  • Decide on an approach to migrating historical information; will all, some or none of it be migrated? This is most relevant when replacing a CRM system. Including historical data may dramatically increase the volume of data to be migrated (and consequently the time it takes), but not migrating it means you may need to maintain the old system for archive purposes.
  • Assess up-front whether a one-off data migration is required, or if the project actually requires the ongoing integration of different systems. Many so called migrations actually require continuing feeds of data to be in place.
  • Decide whether a “big bang” approach is practical (is there sufficient downtime to execute the migration?) or if a phased, or “trickle” migration is required. Avoid the mistake of one insurance company that got to within a month of implementing a new CRM system before realising that it would take more than 2 weeks to migrate all of the data, but it had only allowed for a 48 hour operational window in which to complete it.
  • Use subject matter experts, from within the business, to map data to the business level entities (Customer, Address, Contact History) in the new system. When implementing a replacement system the mapping exercise should be repeated based on the legacy system entities to ensure that no critical data is left behind.
  • Identify whether the data migration needs to include a deduplication process and where it will be done. If one is needed, must it be completed before the data is loaded to the new CRM system, or could it be done afterwards with the data in situ? As with an business rules, those used to match and merge data should be designed by an empowered business user and confirmed by the governance board.

At first sight, it appears that little has changed in the 15 years since my first CRM data migration project; significant numbers of CRM implementations are still doomed to failure because inadequate attention is paid to the data that powers them. However, attitudes are, I believe, changing and so too is the technology that is used to deliver data migrations. These projects are finally moving out of the darkened basement, thanks to innovative solutions that provide powerful functions through easy-to-use interfaces and enable business users and IT specialists to collaborate effectively.

Post Your Comment