Author: Julien Le Dantec, Senior Consultant at Nexell GmbH

Migrating data from your legacy system(s) to Salesforce can be a bit of a bumpy road. While the platform can automate many tasks, no amount of Salesforce “magic” will replace your involvement during this phase. 

To help you avoid the many potholes along the way, we want to share a list of common pitfalls you could fall into and how to safely bypass them.

1.Improvising data migration

Migrating data takes time. Therefore, it’s important to plan ahead. Whether you prefer to use specific methodologies like the Agile framework, with its specific sprints, or Waterfall, you should establish a plan for data migration. Allocate your own resources (not an intern or an external staff member without business knowledge) and book your schedule so that you work together with your project manager. This will help you monitor the task progress and celebrate quick wins along the way.

2.Setting aside (the right) stakeholders

Migrating data should never be a one-man show. Gathering stakeholders is the safest way to get proper vision and anticipate issues linked to the migration. It will allow you to select the correct information and potentially see the logic (validation rules, workflow automations, etc.) that links it together. Moreover, by sharing the data responsibility, you will be able to share the cleaning workload and assign the related tasks to the proper people, thereby accelerating the process and reducing the perception of the associated effort.

3.Ignoring your current data situation

Reflect on the current state of your data and ask yourself key questions before going any further:

• What data do I have today?
• What is the quality of my data?
• Which part is accurate?
• How far back in the past should I go?
• If multiple systems are in use, which is my source of truth for each type of data?

This reflection is a good opportunity to create an inventory of the data in your different systems and to build your data dictionary. This inventory is not a simple shopping list, but it will help you prioritize the data you must clean prior to the migration.

4.Feeling confident about bad data quality

Bad data quality will have consequences at multiple levels:

• Missing information: Your automations cannot run on empty data, and your communication can be negatively impacted in the case of, for example, missing email addresses.
• Inaccuracy: Inaccurate data, whether it’s irrelevant or badly formatted, will impact your analytics, as you will not be able to create proper reporting and get a current realistic representation of your pipeline.
• Usability: How will your users link their opportunities to the right accounts if, for example, two of them have the same name? How will you be able to calculate the related revenue?
• Adoption: If your users are disappointed by the data they’re seeing, and if they feel like they can’t trust it, you run the risk of them looking elsewhere—and, therefore, not adopting Salesforce.
• Costs: Bad data quality is expensive. Extra time is needed for a given task, which directly impacts your ROI.

 5.Keeping duplicates “for now”

You’re there and you’re taking the time and making the effort to analyze and review your data, so continue by removing your duplicates. This goes along with the topic of bad data quality. While tools exist, we strongly advise you to merge your duplicates at this point.

Here are a couple of examples of the impact of duplicates:

• Searching: The search bar is a great tool to quickly get what you are looking for (and is now even better; with the implementation of Einstein search, you can even leverage AI). However, if you receive multiple similar records as a result of keeping dupes, you’re wasting this great feature.
• Reporting: Compiling the information, while simple in principle, becomes a pain and you lose the visibility that the board needs to make the right decision—the one that will shape the future of the company.

After importing the cleaned data, you can implement duplicate rules before go-live so that the effort that has been put in is still enforced when everyone receives access to use the platform.

6.Migrating all of your data

You have gathered your legacy data in one place. This is a great start to visualizing the current “data” picture. Not all of it will necessarily need to be imported; in fact, probably not. Some historical information might be exceptional, super-specific to particular cases, and not representative—and, therefore, not imported to Salesforce. This moment is also the opportunity, with the selected data to import, to verify potential gaps with the CRM and to create additional fields in the system if you wish to keep some legacy data. However, keep in mind that the more data there is, the more time will be needed to clean and implement it. Depending on the legacy systems you have been using, you can keep an extract of your not-so-useful legacy data and refer to it when needed.

7.Minimizing the importance of ownership

Migrating data involves creating new records in Salesforce. Each of those records should have a record owner. Ownership is an essential part of Salesforce. It is useful to organize data access and permissions. In a nutshell, it allows for:

• Individual assignments: Whether your teams are split by regions, customer types, or even products, records must be assigned to share and organize the workload. 
• Collaboration: Providing your customer with a faster solution can be achieved by other members of your team. Therefore, ownership can be shared with one individual or with an entire business unit if needed. Another benefit of sharing records is avoiding the creation of duplicates for “unfound” records.

Importing data, a sequence example:

When you have taken all of the previous steps into consideration, you can move on to this suggested hands-on sequence example built from my empirical experience:

• Identify the Salesforce objects that will be in use.
• Be aware of how they are connected (e.g., master-details, lookups).
• Respect the specific sequence (user first, then accounts, contacts, etc.).
• Create a template per object that respects your Salesforce data (e.g., date format, currencies, picklists, checkboxes, etc.).
• Populate your templates.
• Make sure it’s clean (e.g., no duplicates, no format/spelling errors, etc.).
• Start small: Import only a small number of records to ensure proper entry and see what it looks like in Salesforce.
• Temporarily turn off potential automations (e.g., workflows, validation rules).
• Verify ownership assignments.
• Prepare your file in your regular XLS format and, when ready, save a copy in CSV format.
• Run a data backup (e.g., exports or reports).
• Launch your import.
• Last but not least, run a sanity check.

 

As you have seen in this article, data migration should not be improvised. It will require time and effort. While it may not look like the most appealing part of your implementation journey, it is one of the building blocks of your CRM database. 

To make a watch analogy, while the best Swiss watchmakers create beautiful designs with shiny exteriors, your watch hands will not turn properly without the right cogs inside the watch. Similarly, the essence of your CRM is your data. At its core, it all starts here.

About the author:

Julien Le Dantec saw the CRM wave coming and decided to ride Salesforce back in 2017 after returning to school and graduating with his MBA. Since then, he has experienced dozens of data migrations and  is sharing his experience with you to bring value to your transition journey.