Data Migration Best Practices

This post will help prepare you for the migration of your data from your current systems into Salesforce. It provides best practices and insights into the most common data migration issues, enabling you to address them prior to the start of your Salesforce implementation. Check out our full data migration tips and best practices below.

Duplicate Records

Best practice: Merge all duplicates prior to migration. (Duplicate Contacts are the most common issue) 

Options for addressing duplicates:

  • Export the source data to Excel and find duplicates based on email address. Then merge the records in your source system.
  • If De-duping is not practical in your source system, you can perform a post migration clean up. See attached data cleaning process.

Data Quality Enforcement

Best Practice:  Ensure your data meets the data quality enforcement rules in Salesforce. (Many legacy CRMs do not have data quality enforcement rules.)

The most common issues: 

  • Email addresses – In Salesforce, an email address must be in a valid email address format (although not necessarily a valid email address). For example, joe@acme is an invalid email address format and should be corrected to Records with invalid email address formats will fail when migrating into salesforce. 
  • Date fields – When importing date fields into Salesforce, they must be in MM/DD/YYYY format. In some legacy systems, date values are stored in a text field with no formatting restrictions.
  •  Text fields in a Legacy system that will be picklists in Salesforce – For example, in a legacy system, there could be a field called “Account Type” as a text field with no data validation. For an Account Type of “prospect”, the values in the legacy system could be Prospect, New Prospect, Suspect or whatever value the user wants to enter. If you desire the values in Salesforce to be a picklist with options of Prospect and Customer (for consistency and ease of reporting), make sure the source data values are either Prospect or Customer.

Data Accuracy and Completeness

Best Practice: If the data is incomplete and the accuracy uncertain, consider excluding it from the migration, or update it prior to the migration.

Example: A field in a legacy CRM called “Specialty” represents a Contact’s area of specialization. If less than 10% of the records have Specialty populated, and there’s no consistency as to how Specialty is defined, is it really worth migrating into Salesforce?

Another Example:  Are your addresses populated correctly, are the values in the right fields, is there consistency in the state names? See below for Other suggestions.

Another Example: Are the client status values or client segmentation consistent and accurate on all records?

Another Example:  Do your records contain; at minimum, the required data. Name, status, etc.

Data Mapping

Best Practice: Ensure the data values in your Legacy CRM fields are storing the correct data.

Example: In legacy CRMs, because there is little data enforcement, it is not unusual to see email addresses, phone numbers or physical addresses in a general “Notes” field. If these situations exist in your environment, the migration will be smoother if the data is populated into the right legacy CRM field prior to migration.

Data definition

Best Practice: Have a clear definition across your organization as to the meaning of each data element.

Example:  In a legacy system, there is a checkbox on the Customer record called “Target Account”. Does everyone in the organization agree on what Target Account represents?  If there is confusion or disagreement on the meaning of any data attribute, align within your organization and update the data accordingly prior to migration.

Record Ownership

Best practice: Each record in Salesforce requires a record owner. (Although record sharing based on multiple rules can be established within Salesforce so others can view or edit records based on those rules.)

Example: This is a common issue in migrating Contacts from Outlook into Salesforce. Outlook users often have the same Contacts in their Outlook. Not only do the Contacts need to be de-duped once extracted from each Outlook, a record owner must be established before migrating into Salesforce. 

Another Example: A legacy CRM may have record owners who will not be users in Salesforce. Maybe they’ve long since left your company, but they are still designated record owners in your legacy CRM. For those record owners who will not be in Salesforce as users, create a mapping of who the record owner should be in Salesforce. Sikich can use this mapping to facilitate the migration.

Other Suggestions

Best Practice: Search and strip out unintended special characters: ! “” SPACE # $ % & ‘ ( ) * + , – . / : ; < = > ? @ [ ] ^ ` { | } ~

There are times special characters cause issues with data migration because the extraction of special characters to .CSV or excel causes unexpected results.

Best Practice: Convert ALL CAPS to Mixed Caps. This will allow your data in Salesforce to appear cleaner, especially in merge fields into eMails sent to customers and partners.

Best Practice: For fields that you know will be required in Salesforce, each must have a value in e very record in your data.

Best Practice: Standardize State and Country fields in your data. This will ensure data accuracy in reporting.

Have any other questions about migrating data into Salesforce or Salesforce itself? Reach out to one of our experts at any time!

This publication contains general information only and Sikich is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or any other professional advice or services. This publication is not a substitute for such professional advice or services, nor should you use it as a basis for any decision, action or omission that may affect you or your business. Before making any decision, taking any action or omitting an action that may affect you or your business, you should consult a qualified professional advisor. In addition, this publication may contain certain content generated by an artificial intelligence (AI) language model. You acknowledge that Sikich shall not be responsible for any loss sustained by you or any person who relies on this publication.

About the Author