7 tips when migrating from one Salesforce to another
I was recently asked to migrate data from one existing Salesforce entity into a brand spanking new one. Salesforce as source and Salesforce as destination: that’s a piece of cake, right? Well, as you may already have guessed, this is not entirely true! But as long as you keep the following tips and tricks in mind, you are already halfway there!
1. Not enough user licenses
We had 85 old users, some were active while others were already out of use. We had to migrate all 85 into a destination org where only 50 licenses were available (has anyone seen ‘Apollo 13’…?). Until recently, you could not use an inactive user as owner for a record, you could only do this with still active users. Luckily Salesforce has introduced some advanced user permissions that can help us with this problem, and reduced the need for additional user licenses. You can find more information on this in the Winter 16 release notes.
2. Data validation issues
Some validation rules may not be 100% compliant with legacy data (or the other way around). While the quick & dirty solution is to temporary deactivate the blocking rule, it’s only postponing the issue for later as the first user that will try to update the record will face the blocking message. The best solution here is to modify the data before the upload or to slightly adapt the validation rule.
3. Attachments: which flavour?
Files, Content, Library, Attachment, …. in Salesforce: each file storing solution has different limitations such as their file size. Dataloader is sometimes more restrictive (file size related) than a manual upload done in the user interface. Furthermore, don’t forget that it’s not an easy task to upload 30.000 files in one single pass. The best solution here is simply to split the load into several uploads.
4. Limitation of “Export All” menu in Salesforce Setup
Watch out: this useful functionality doesn’t export all fields, for example formula fields. On top of that, you also have to wait one week between two “Extract all” requests. You better carefully plan & think twice about everything you need before requesting a full export.
5. Use & store a Legacy ID
Always use a column with a link coming from the previous system (Legacy_ID_c) in your CSV file. Even if it’s not needed and/or not possible to create a custom field for such purpose in the Salesforce destination table. Thanks to this Legacy ID it will be easier to remove or debug records afterwards. For example: I had to do a files operation where I needed to remove some of the 800 “picture.jpg” files without knowing which one from the new entity referred to which one in the legacy org.
6. Organization is key
Carefully save all successes and errors files generated after upload/insert. They are needed to keep track of everything that could have gone wrong and give you unexpected results. Only delete the error files when no error occurred. And don’t forget to rename a success file with the kind of operation you performed. For example “Account – UPDATE – Parent field relationship success.csv”
7. Test, test & test for each object and each field.
Some fields are only allowed to be populated with an Update operation while others are only allowed to be populated during an Insert. It is possible to specify the value for system fields (such as created date/by & last modified date/by), but this is only possible during an Insert operation (and not for all objects), and not during an Update. If an update is needed afterwards, some system fields will be changed (last modified date/by) and won’t match your uploaded value. So double check everything before pressing the Insert button. A good read on this matter is the “Enable Create Audit Fields” article. To know for which fields you need to use Update or Insert, the SOAP API developer guide is your bible for this. Ideally you should perform your test in a full sandbox having the same limitations than your production environment (same available user licenses, same storage space limitation, BULK data load jobs, …)
Migrating from one Salesforce org to another might be a tedious operation, but investing in doing it properly definitely pays off. Luckily you don’t have to face this on your own since we at 4C have a bunch Salesforce consultants to assist you in your migration challenges!