Why is Migration Necessary
Many technological advancements face objection since they need a “cultural change”. Users find it hard to abandon their old habits and learn new things. As such, a successful transfer always seeks to cut the learning curve and make the transition as seamless as possible.
When starting Salesforce, your company has most likely been in business for a few years. Your staff are accustomed to their current workflows and you have collected tons of data on your clients and your products. All of these needs to be available in Salesforce, or the transfer will fail. This process is “migration”.
Migration is twofold; you must both address the workflows and processes, and you must give access to the legacy data. In this piece, we are focusing on the challenges of the latter: “data migration”.
Challenges of Data Migration
Let me start with a concrete example. One of our clients was migrating from their previous CRM to Salesforce. They already had their Salesforce objects and processes created and tested, and now they were ready to make the final move.
When you confront this, there are several issues to consider:
- Field mapping – you need to know how your data should be organized in the new system. This must be very granular, down to every object and every field
- Transformations – in some instances, you might need to change the format of the data to make it suitable for the new system. This is especially true for date fields
- Data cleaning – migration is a good time to get rid of invalid and out dated data. Instead of transferring the headache to the new system, see what you can discard. “The fastest operations are those that are never done”
- Relationships – you probably had foreign keys and relationships in your old system. These need to map correctly in Salesforce too. To get this right, it is best to figure out the proper order to upload the objects, so that the parent items are migrated first
- Processes and validation rules – especially if you have a working system (like in our case) chances are that there are processes and workflows at work. Carefully review these, and if necessary disable them. You don’t want to spark 10,000 emails going out when importing all those records. At times, they might also prevent you from properly uploading your data. Disabling the culprits let you finish the upload, and then follow up any remaining issues within Salesforce. That way you can create reports and easily assign someone to take care of those.
Tips and Tricks
- Excel can be very helpful, especially as the data loader tool requires CSV files. Having an Excel file allows you to create formulas and easily format your data, and export the result as CSV. This way you can also map relationships even before importing
- We can take care of relationships in two ways; either on the data loader tool or within Excel. For small records, using Excel is the best choice. For instance if your org has less than 10 users, it might be best to just export their names and IDs and then remap any fields that involve user assignment directly in Excel
- The other method is using a temporary column: upload the legacy ID column, and then use it to track down the actual ID column after the import and run an update.
- The native data loader has a “hidden” feature; you can remap fields inside it. Say you need to put the legacy IDs of accounts in the parent object (and not the actual record IDs). The native Dataloader actually allows you to make this mapping during the upload. It must be noted though, that to do this there must be a relationship between those objects (which SF will use as reference). Also, you need to manually edit the SDL file inside notepad or a similar editor to achieve this. The mapping would look like this: ParentAccountID__c=Account\:ImportID__c
- If you need to import data such as “date created” and “user modified”, please note that they might not be available in all objects. These are called the “Audit fields” and previously, Salesforce required you to specifically ask them to allow you to override their values. As of this writing, this permission is now natively available for many objects (meaning you don’t need to contact Salesforce anymore) but not all of them.
- You might still face failing processes or flows. Keep an eye on the debug logs and be prepared before you do the migration. In case you see that “flow failed” message, a good to see what is failing is to note down the ID, open a sample flow in the flow builder, and then replace the ID in the URL with what you typed down. This should reveal the failing flow.
- In this project, we used the paid version of dataloader.io. Unfortunately, we did not have a good experience. The tool timed out under the load we put on it, which forced us to redo our work over and over again. The native data loader proved to be much more reliable.
Do you have a data migration project? Call us to see how we can help!