Conducting a successful Salesforce data migration is one of the most challenging tasks for a Salesforce professional. Data migration is the process of transferring data from one system to another; however, the work required before the actual transfer is the most complex part.
Data migrations can be very different depending on the size, format and accuracy of the source data; however, there are three general phases that you can follow. Preparation is the most critical phase in Salesforce data migration, this article has a special emphasis on it.
The success of the whole migration depends heavily on having prepared well for it, so make sure you allocate enough time to complete this phase. The better you prepare, the less chances you have to iterate later.
In the preparation phase, you will first need to identify the data to migrate and the data source of truth. The type of processes you have built in Salesforce will highly influence your Data selection, although you could also realize you need to build additional objects and processes when analysing the data you need to migrate to Salesforce.
Typically, the source of truth in an online business is the backend, as it is where customer transactions are directly stored. However, not all business data is stored in the backend. For example, most information related to sales processes is likely to be stored in a Customer Relationship Management System. Ideally, Customer Service agents will be processing service tickets in the same system, but this will not always be the case. If Customer Service Teams do not work on the same system as Sales agents, some more business data will be found in the Customer Service tool they use. Other teams could be working with different tools too, but, before you get overwhelmed, try to focus first on identifying which data gathered by which team/s is relevant.
As it is very likely that more than one tool is used in your business and that you are therefore going to use more than one data source (i.e. different sources of truth for different data categories), the first exercise you will need to do is selecting which data to migrate and where to extract it from; in other words, deciding which specific information you need from each system.
The next step in the preparation phase is ensuring all records of each source system have a unique Identifier. If any of the data categories in one source system is related to another one in a different system, the unique ID of the second one is required in each related record. For example, if you are planning on migrating current Customer Details from the backend, but you would also like to import past Sales Contract information from the previous CRM, every Sales Contract record in the CRM is required to have a backend ID.
Note that if IDs are not in place, data cleansing will be needed. It is extremely important that duplicates and outdated accounts are discarded from the migration. Help from users will be required here, as they should be able to fill in missing IDs and to indicate which data they want to keep.
At this point, you will need to get a sample of metadata from the source system/s, so that you can see how data is structured in every source system (every field and table needs to be included in this sample). Map Admin tables, fields and values in the source system/s to the different Salesforce Objects, Fields and values in your (new) Salesforce instance. The more different from your Salesforce data model data structures in the source systems are, the more complex the data mapping process will be. The higher the number of source systems you need to extract data from, the more complex the data mapping process will also be.
The second phase involves the actual transfer of data from the source system/s to your Salesforce org. The migration method you choose will mainly depend on the type of resources you have available (developer, admin), the volume of records you need to import into Salesforce, the complexity of the source data and the distance between the source data structure/s and the Salesforce data model. The amount and the expected complexity of the data transformation will also determine the transfer method.
Once data has been transferred to Salesforce, you will need to ensure that all data has been transferred correctly, i.e. all data has been transferred with the right format and relationships between the different data tables are reflected accurately in Salesforce.
If the result of your Quality Assurance test is not successful, you will need to find in which phases errors happened. If they are found in the preparation phase, you will need to iterate on the whole process.
Salesforce data migrations are very complex processes and each of them is pretty much a unique process. The key is having a good understanding of source system/s and data structure/s. The reason for having to conduct a migration into a (new) Salesforce instance are varied and might also give you a hint on which data you need to extract from where. For example, you could need to migrate from a different CRM into Salesforce because you have realised you need to build scalable processes and Salesforce is the right CRM for it. Or you could need to migrate from one Salesforce instance to a different one because you have acquired a company that works on Salesforce and you now need to move its data to your Salesforce instance as part of the post-acquisition integration. Finding out which source data is trustworthy, where it is stored and how it should be mapped to the Salesforce data model can be very challenging, but remember that a good preparation phase is the key to success.