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.

I really liked your article, I have had to find out most of the information that you presented on my own, so it is nice to have it laid out like that.
With all the new technology and new software who or rather which product do you think is the best to use?
Posted by: Charlotte | 01 December 2008 at 16:46
Thank you for your comments, Charlotte (and apologies for the delay in replying). Of course, I'd have to recommend dn:Director from Datanomic for data quality and data integration products. Not only do I work for Datanomic, but I'm also responsible for some of the product's key features and the production of a single platform that can profile, audit, transform, cleans and match data of any type, in batch or real-time.
Incidentally, my blog has now moved to the corporate site - you can find the latest postings here: http://www.datanomic.com/category/resources/blog/
Posted by: Steve Tuck | 18 February 2009 at 15:43