The decision has been made to drop your company’s contact management system and move to a new CRM system.
Migrating data from a contact manager to a CRM system involves a number steps, including the following:
- Define the functional requirements for the CRM system
- Analyze the data from the contact management system
- Configure and customize the CRM system
- Map contact manager data fields to CRM tables and fields
- Extract contact manager data
- Import data into the CRM system
While moving through these steps, there are a number of important considerations for ensuring a successful data migration.
Data Migration and CRM Configuration
There’s a common misperception that a “data migrator” can be easily inserted into the middle of a project.
However, it’s not possible to fully separate data migration from CRM design. This is because the nature of the source data and decisions about how data will be managed moving forward dictate a number of factors about the overall CRM architecture, specific characteristics of the destination fields and the migration process itself.
Some of the questions that normally come up are:
- How was the information used in the past and how will it be used moving forward?
- In which CRM object or entity is the destination field for a contact manager field? Is it an Account field, a Contact field or a is it a field in a custom CRM object/entity?
- What should the data type of the destination field be (text, picklist, lookup, etc.)?
- Do a large number of contact manager lookup values for a given field need to be consolidated into a lesser number of CRM picklist values?
- Do any repeated fields in the contact manager need to be normalized in the CRM system? For example, are there repeated fields in the contact manager such as Property 1, Property 2, Property 3, Property 4, etc. that should be managed as a related object/ entity in CRM?
Splitting Up Contact Records
As contact-centric applications, contact managers either do not have a related Account (company) table or they do not require that Contacts have an Account relationship. Therefore, when there are multiple Contacts who work for the same organization, the name of the organization is typed into the Company field of each record in the contact manager.
If there are, for example, five Contacts in the contact manager who all work for the same organization, one Account record and five related Contact records should be created in CRM.
It’s important that the spelling of the company name in the contact manager be consistent across Contacts who work for the same organization so that the proper relationships can be created in CRM.
Contact Manager Call and Meeting History
The history table in contact managers is structurally different from the history table in CRM systems. Proper mapping and transformation needs to occur in order to preserve all important information.
If there are many years of history in the contact manager, should there be a defined cutoff date, before which contact manager history records are ignored?
Contact Manager Notes
In contact management systems, historical information can end up in both separate History and Notes areas. It often makes sense to combine historical information from both areas of the contact manager into just the History area of CRM. Moving forward, the decision should be made whether to use the Notes area of the CRM system or whether everything should be “noted” in History.
Contact Manager Email History
Email history records can contain HTML tags that need to be stripped out in order to render the body of the emails legible in the long text field of CRM history. Removing these tags can be a time consuming process.
Secondary Email Addresses
Certain legacy contact managers allow for an unlimited number of email addresses per Contact. Most CRM systems default to a single email address per contact. Should additional email addresses be added to the Contact object in the CRM system. If so, how many? Alternatively should a custom email object/entity be added to the CRM system?
Duplicate Merging
There are several approaches for removing duplicate records. These approaches are not necessarily mutually exclusive.
The severity of the duplicate problem and the importance of retaining the best field values from each instance of a record determine which approach should be taken.
- Merge all suspected duplicates in the contact manager ahead of time
- Merge suspected duplicates within an intermediary database as part of the data migration process
- If there are a small number of duplicates, and it’s important to retain the best data from each record in the “winning” Contact record, then the CRM system’s “stare and compare” merge functionality, by which the best data from each record can be preserved, can be used after the data has been migrated.
Legacy Fields
It often makes sense to migrate some of the data in contact managers into CRM as “legacy” fields. These are typically defined as read-only fields in which certain data from the contact manager is presented for reference only. Contact manager ID fields such as Contact ID and History ID should always be migrated into CRM as legacy fields. If IDs are not brought in, it’s a lot harder to fix problems after the fact.
File Attachments
Since contact managers allow for each user specify their own attachment folder, in the absence of proper administrative oversight of the contact manager, attachments can end up scattered all over the network. If it’s important that file attachments are attached to CRM records, then the attachments may need to first be corralled into a single location.
If there are many gigabytes of file attachments, could migrating all these attachments require extra storage if the selected CRM system is cloud-based?
Email Lists
In contact managers, email list membership is often managed using custom checkbox fields or using the Groups feature of the contact manager. In a CRM system, it’s better that email lists be managed using campaigns. One reason is that integrated marketing automation systems can leverage CRM campaigns and campaign membership.
In order to migrate list members, legacy fields for active email lists can be migrated to CRM. Corresponding campaigns can be created in CRM and then CRM Contacts can be added to these campaigns en masse as members.
Test Data Migration(s)
One or more test migrations should always be performed. Once the test migration has been signed off on, the final migration can be performed. Due to all the variables, even with stakeholder and end user review of the test migrations, adjustments often need to be made after the final migration.
Change Management
Change management is an often-overlooked component of a contact manager to CRM data migration. Contact managers have some functionality that CRM systems do not, such as a built-in email client. Users need to be prepared for any major changes and trained on how to accomplish certain tasks within a new CRM system when those tasks are performed in a different way.
With proper pre-planning and execution, migrating contact manager data into a CRM system will be a much smoother process and will result in higher CRM adoption.
