Migrating data from a contact manager to a CRM system should be relatively straightforward, right? Just bring up a data mapping UI on a screen, map the appropriate fields and then click “Import”. Unfortunately, there are many possible factors that can add complexity to the migration of data from a contact manager to a CRM solution. Here are just a few of them.
Mapping Contact Fields to CRM Accounts and Contacts
Since contact managers have historically not had true Company (Account) records, users have had to store company level information within a specific contact record (often by just picking a primary contact record from one of multiple contact records for a company). If the company level information that’s within primary contact records needs to be properly migrated into a CRM system, it can take time and effort to both decide on logical contact-to-account field mapping and to execute properly on the migration of this data.
Creative Use of Fields in Contact Managers
In some cases, when a contact manager has been in place for many years, fields have gotten increasingly creative usage. For example, we recently heard of a case in which the Address 2 field was used to hold the name of the Sales Rep for the contact. Sometimes, the same user defined field (UDF) has been used for different purposes by different users, which results in very inconsistent data.
Runaway Pick List Values
Over time, contact managers can get a lot of bloat in pick lists. Implementing a CRM solution is normally an opportunity to restore some discipline to pick list values. However, unlike with contact managers, CRM pick list fields normally require strict values. This of course, means that decisions need to be made about how to pare down legacy pick list field values – which may involve shedding some data and transforming other data.
Secondary Contact Fields Within a Contact Record
Contact managers have typically employed some “flat fields” for secondary contacts. In other words, within a contact record, there are fields for storing the names and numbers of other contacts from the same company. Since CRM systems are by nature, relational, the normally recommended path is to create separate contact records in the CRM system for these secondary contacts. This, of course, means properly extracting secondary contacts in such a way that they can be imported.
Normalizing Other Flat Data
Since many contact manager versions have historically not allowed for the creation of custom tables, in some cases, users have created duplicate sets of custom fields in the contact record for storing data such as multiple quotation line items. This has to be managed from both the perspective of properly normalizing this type of data in the new CRM system and migrating the old, flat data into a related table or object, if the latter is needed.
Distributed Email Content
Older versions of some contact managers stored the body of emails as file attachments, as opposed to inline text. Where these attachments lived could be defined by each user — they could have been set to save to a local drive or to a network drive. Wherever these attachments are located, they all need to be corralled into a single location, associated with the appropriate History record and then imported.
Distributed File Attachments
As with email attachments, file attachments can often be distributed across different folders and drives within an organization. In addition, file naming conventions can make it a challenge to identify which attachments belong to which records.
Mapping Old Users Into a New System
When contact manager user leaves their company, that person’s name is still associated with Contact and History records. CRM licensing normally requires that record “owners” are licensed users. Therefore, a contact manager record owner cannot always be mapped straight across as a record owner in a new CRM system. In order for the original contact record or history record owner’s name to be preserved in a new CRM system, that person’s name may need to be pre-pended or appended to a text or a memo field.
Multiple Contact Manager Instances
Often when a company is using “a contact manager”, they are sometimes actually using multiple instances of the same application. Each user may have taken the application down a separate path in terms of field usage and custom field creation.
Contact managers that have been in place for a while can have a large number of duplicate records in them. Migrating data to a CRM system is an opportunity to clean up these duplicate records.
Sometimes there’s old data in a contact manager that should not be imported. For example, it doesn’t always make sense to import history records that are over 10 years old. Filtering out records by date range requires extra time to be allocated to the data import process.
The Need to Adapt to a Security Model
If each user in a new CRM system was previously using a separate instance of a contact manager (or even separate brands of contact manager), now that all the data is in a single, central database, security rules (permissions) may need to be put in place to ensure that a given user only has view or edit rights to a subset of records.
These are just a few of the possible complexities that can be encountered when migrating contact manager data into a CRM solution.