Salesforce developers typically consider data migration to be a simple and mundane part of the job. As we learned in a recent project, this is a misconception. In our case, we encountered issues with incorrect data in the new system, and ultimately the project took more time than planned. There is a lot at stake when doing data migration. If data are incorrectly imported, the implications can be huge. Imagine what happens if revenue data are incorrectly imported, if the record ownership gets set incorrectly, or tasks meant for the Sales VP get assigned to the new intern.

This article includes a few things to keep in mind when doing data migration.

  1. As you initiate the process of mapping of the data from one system into another, one of the first things to perform is the user mapping. We need to have a clear understanding of how will the user ids of existing system map to the new user ids on the Salesforce platform. This user mapping information is critical to ensure that the record ownership is set up correctly in the new system. This is also a good time to revisit which all users have what kind of licences.
  2. Typically when you are doing a large data migration, you should revisit the existing profiles and Organization Wide Defaults. OWDs and Profiles are the foundation of the security of any Salesforce instance, and it is critical that these are set up correctly.
  3. As you set up all the new data in the new system, make sure that all the page layouts and mapping of page layouts to profiles are set up properly for all the record types.
  4. If you are migrating the data from one Salesforce instance to another Salesforce instance, then plan to have a couple of licences available of the old instance for a few months after the cut over date. If, after the migration there are issues, this old instance will come in extremely useful in investigating issues.
  5. If you are migrating code from one Salesforce instance to another make sure that the Apex classes do not have any hard coded instance names like ns1. These can easily be removed using Apex methods like getSalesforceBaseUrl. Also if there are any hard coded ids of Account, Opportunity ids in your classes or test case, then this may lead to incorrect behaviour of Apex programs in new instance.
  6. Revisit the apps that have installed Appexchange apps. Most Salesforce instances that are active for many years tend to have many apps that are not really being used. A large data migration may be a good time to uninstall those unused apps.
  7. As you move in additional data into your Salesforce instance, keep a watch on the space you are consuming. In case you are reaching your permitted space limits, it is time to call your Salesforce representative to purchase additional space.
  8. When inserting the records into the new system, it is extremely important to identify the ordering of insertion of objects into Salesforce. As a trivial example you will need to insert all the accounts first, and then all the contacts so that relationships between contacts and accounts are set up properly. In real situations, the relationships between objects can be fairly complex. Besides the ordering of objects, you will need to insert fields of the same object multiple times (again), so that all the lookups are set up properly.
  9. It is important to plan out the data migration. The users should be informed well in advance about the cut-off date, and possible issues that may happen. Also it is always a good idea to have a few pilot users available to test over the weekend in which a major data migration is planned.
  10. From a developer perspective it is important to plan/provide sufficient time for testing the results of data migration before you roll out the instance to users. Just because the data loader has executed without any errors does not mean that the migration is complete. Use the Developer console to perform basic queries like – total number of accounts of a certain record type, number of accounts without any contacts, number of accounts owned by user XYZ etc.
  11. It is also import to do sanity testing directly in Salesforce. Login as different types of users, and view a few records of different objects. Compare these same records manually with the original system. Although many tools are available, there is no replacement to manual verification when testing data migration.
  12. Before you run a tool like data loader to import the data into your new instance, revisit the active workflows and triggers. You need to evaluate if all the workflows and triggers of the impacted objects should be disabled before uploading data. Often there are active workflows that send emails to customers when certain stage is reached. Imagine the situation if unwanted/incorrect emails get sent to thousands of Customers as you upload all the contacts.
  13. Typically CreatedBy, CreatedDate, LastModifiedByID, LastModifiedDate are read-only fields. However, during data migrations it is generally desirable to insert records with legacy dates and ids to match the source system. You can raise a case with Salesforce Support and they will make these fields editable for a limited time. You will need to mention in the Case that you would like to enable "Create Audit Fields."
  14. When inserting date fields, Salesforce data loader uses the time zone of the user inserting records. The user id being used to insert records should have “proper” time-zone settings.
  15. Last, but not the least, make sure you make a backup of existing data of the new Salesforce organization before you initiate the Data Migration.

About the Author

Naveen Gabrani is a Salesforce architect and runs a Salesforce consulting company, Astrea IT Services.