I got an opportunity to work on a Data Migration project early on in my career when I fresh started with Salesforce CRM platform. I faced a lot of challenges and of course, learned a lot with it as well.

Be advised when I tell you that Data Migration in salesforce can be a real time-consuming and mind-boggling task if you don’t do it right. This is my experience of how to approach a Data Migration task. Crossing the T’s and Dotting the I’s to make a data migration task successful.
Data migration is the process of getting data from the legacy system, mapping this to the new data requirements of connected systems and then uploading this data into the new system (here Salesforce for reference). The data mapping task highlights the data transformation needs, as well as the data-cleaning needs to ensure the new system now has the data sanctity as per business expectations.

Having a strategy around data migration ensures:

1. The challenges are identified early on so that the go-live can be done smoothly.
2. The new environment has the current data at the time of go-live.
3. Stakeholders are confident with the sanctity of data that is being migrated.
4. Stakeholders gain confidence and understanding of the data that is migrated in the new environment prior to go-live.

High-level steps to be followed for any data migration

1. Create data mapping Templates for the Entities to be migrated. These templates would have the Legacy and current system (Salesforce) field definitions and related business logic if any.
2. Get access to Data for each object to be extracted from the source system in the format specified in your mapping template.
3. Identify a Data subset and get it validated by the stakeholders.
4. Clean the Data and apply data transformations (if needed). Review the issues with the stakeholders (example default values for fields if data is missing)
5. Now, this is the first time you are trying to data migration in Salesforce Org. Before that, de-activate all legacy system to Salesforce integrations. Disable (suitable) Salesforce triggers, process builders and workflows if they should not run during migration.
6. Upload a few records (say 100) for each object and validate the insertion in Salesforce.
7. Upload the remaining records for each object.
8. Spot check data by comparing it with the original data files for any discrepancies.
9. Validate data migration in salesforce and approve the data quality
10. Temporarily activate Salesforce -legacy system integration to enable two-way sync of the records that were uploaded in Salesforce. Check if the integration works as expected and the sanctity of data in both the systems is intact.
11. Insert test records (with the integration enabled) and update existing data in Salesforce and Legacy system to see if the integration is working as expected.
12. Get the stakeholder’s validation of data in both the systems.
13. Upon Business approval, permanently enable the Salesforce -Legacy system integration and Salesforce triggers, workflows and process builders.
14. Most important of all, have a Roll Back Plan in place so that the business is not affected at any point in the whole process. Pointers to include as a part of the Roll Back Plan:
15. Remove all the Salesforce – Legacy system linkages
16. Analyze data issues and use the source data/source data mapping files from Legacy system to update the Salesforce data and Legacy system data.
17. Review and resolve the issues in Salesforce and in Integration

Scenarios/Questions to think about the Data Migration activity

1. There may be coded value in the backend for certain field values i.e. different values in frontend and backend for the same field e.g. Country is shown as India on the frontend but is registered as IN at the backend.
2. Incorrect data type e.g. say in the legacy system the description is 1000 chars long but in Salesforce the description field is taken as ‘Text Area’ has only 255 char limits.
3. Numeric data in the legacy system needs to be cleared for any extra decimal values placed at the end if they are not to be uploaded as it is. e.g. 10.00
4. Percentage fields need to be checked in the legacy system if they are extracted with or without the % sign. We need it without the % sign in Salesforce. Salesforce has a percent data type field, so if in the legacy system the fields are storing the value with %, the data must be cleaned before uploading.
5. Mismatch in the values of the picklist fields, mismatch issue can be as small as the values being case sensitive.
6. Format of the Name field in the legacy system?? In Salesforce the Name field has 4 different subfields (salutation, first name, middle name, last name). We’ll be needing the names in this format separately to upload.
7. For the URL links, what is the format saved in the legacy system e.g. is there Https or Http attached with every URL or not.
8. In Salesforce checkboxes are to be registered as True (checked) and False (unchecked)
9. Blank fields values should be registered as blank (i.e. without any value) while extracting data rather than having 0 or any text showing that the value is blank
10. The extracted data (Special character) for some fields in some systems is not clear, due to which it’s not good data to be uploaded in Salesforce. e.g. Bad Latitude & Longitude Info (5º 15’ 05” S)
11. The address field in the Legacy system should be mapped properly to salesforce as there may be data inconsistencies in the legacy system. e.g. maybe the city, country, and pin code information is stored in one field in some records in the legacy system or maybe the billing & shipping info are not clearly differentiated. What should be done in such a case while uploading data in Salesforce?
12. Fields registering values such as Height, weight, temperature, etc. should just have the numeric values and not the suffixes along with the value in the field such as feet, inches, grams, kg, C, F
13. Orphan records i.e. records having parent record non-existent, business needs to decide what to do with such records.
14. Records corresponding to the ex-users in the legacy system will have to be allotted to someone in salesforce, identifying who would that person be?
15. There may be a case where certain data wasn’t mandatory in the legacy system and has been made mandatory in Salesforce, which should be entered there as a value for a successful upload. All the Salesforce mandatory info needs to be in the data set that’s being uploaded for successful data migration.
16. Data in the legacy system needs to be checked for duplicate records, business needs to decide which record to keep as a primary record among those and which all to delete.
17. Numeric Data in excel in text format needs to be converted into numeric data type before upload.
18. Date-Time Format in the legacy system and in Salesforce should match.
19. For using a data loader to upload data, unless you change the system time to match the Salesforce Org’s time, the date-time fields will show incorrect values.

There is always a scope of adding points here. But this is what I recollect as of now from my experience. Hope this helps!!