Somewhere along the line, most companies will need to go through the process of migrating data. It’s one of those dreaded tasks that must be done, but it can get messy and can create more problems than you anticipate. While we can’t guarantee that data migration will ever be fun, there are some steps you can take along the way to make it go smoothly.
What is data migration?
Before we jump in, first of all, what is data migration? It’s when you have your data in another system like Microsoft Dynamics, ACT!, or another Salesforce organization and you move it into a new or existing Salesforce organization. Essentially, it’s just like it sounds – moving data from one place to the other.
Do your prep work.
What you do to prepare can make or break the process for you. Penrod’s Data Specialist Brandon LaFave recommends knowing your data really well before you start.
“I think one of the most important things that customers can do is become familiar with their data,” Brandon said. “Is the data clean and not in need of much preparation? Are there a lot of duplicate records? Deciding whether or not the data should be cleaned before it gets imported into Salesforce is important. While we recommend cleaning the data beforehand, there are tools that can be used to clean the data once it is imported into Salesforce.”
Penrod’s discovery process is an important part of how we do things here and it will shed light on other steps you need to take before moving your data, like identifying key stakeholders, what objects you’re migrating, and any other custom importing you’ll be doing.
Clean bad data.
As Salesforce MVP Steve Molis once said “I don’t know what circle of hell bad data may be, perhaps it’s the third or fourth, but no matter what, who wants to live like that? No one.”
The truth is, at least some of your data is messy – it happens to the best of us. When we work with you to migrate your data, we do a lot of the heavy lifting to make sure your data is scrubbed and useable. We run into a few frequent fliers when it comes to bad data, so if you’re thinking about migrating your data soon, be on the lookout for these:
If your records are missing bits of information like name, email address, and phone number for contacts and leads, you will probably never use it. Before we migrate your data, we’ll filter out bad records like this. As you add new records to your organization, make sure that all important information is included.
Bad Email and Phone Format
Salesforce has a set format for email and phone numbers. Make sure yours are formatted according to their requirement.
Salesforce also has maximum lengths for different fields. If your fields exceed the max, the record will fail. Records need to fall within the appropriate length so the data can be migrated properly.
Give your data a home.
Once your data is clean, mapping is the next step. This is where we give your data a “home” in your new system. This part can get confusing because different systems have different field names, so you’ll want to plan this part out carefully. Failing to map accurately could mean you lose some data.
“Mapping is where we take the field names from the source system and match it to fields in the Salesforce destination,” Brandon said. “Salesforce has plenty of out of the box standard fields on all of its objects but many times a client will have specific fields that require custom fields. This is important because we want to make sure that we retain all of those important pieces of data.”
Moving your data to your Salesforce organization.
Importing is when your data finally moves into your Salesforce organization. Unfortunately, there’s not just a button to press to make sure this happens correctly. This step takes time and planning. The most important thing is to ensure key relationships are maintained throughout the system. Typically, we start by migrating users first so each record can be assigned to the right owner. Then we import accounts and contacts before moving other categories over to your Salesforce organization.
Another important part of the process, Brandon says, is to use the original system’s unique identifier field as external ID. Doing so ties it to the old system and will help you find it if for some reason the data doesn’t migrate properly into Salesforce.