I want to run a data migration using data-loader. I have changed the structure of my database and now I need to migrate the data.

I have following questions:

  1. What is generally done in terms of testing the migration before doing it in production?
  2. Do you usually get a full copy sandbox and do a test run there first?

2 Answers 2


There are so many guides and points to consider while doing data migration, but I shall try to keep it down to testing/validation of data migration only. If you have the full-copy sandbox that is the best thing, and you do migration on it first. Whether you do it on sandbox or production here are few points from my previous experience:

Pre-migration checks

  1. Check the Timezone of the target org and make sure you have configured your dataloader accordingly.
  2. Turn-off Email-Deliverability as you don't to send emails to users associated with records during your data load.
  3. Determine the Order of migration of objects. A general migration order is given below, find yours from your org. Schema Builder is a good place to start to know your object dependencies.
    • Load Users
    • Load Accounts
    • Load Opportunities
  4. Create data template for each Object, in excel, using a data export from the Data Loader (use the export file as your template). Use those templates to import data back into the system.

Data Migration

  1. Do a small import first
    • Import 5-10 records first to make sure they uploaded as expected before importing all records.
    • If they all look good, then you can do the main import – Be sure that the first imported records are removed from your main list before importing them or you may end up with duplicates.
  2. Before loading data into production, make sure you have loaded data with same data files(data templates) in sandbox earlier. Depending upon sandbox availability, you can either use Developer, QA or Full copy sandbox.
  3. Audit fields (CreatedBy, Createddate, etc) update - Since Winter'16, once enabled, you will be able to set these fields when creating new records.

  4. Use of Vlookup function to match/refer external ids or Salesforce Ids of objects from one sheet to another

    • Note: VLookUp is case-insensitive, so make sure your IDs are unique. (For reference check out SF 15 digit and 18 digit Ids)

I prefer Index-Match over Vlookup (but Vlookup is more common I guess).

  1. Review exception reports, failure and success reports by dataloader, to see what data was migrated and what was not migrated.​

Post migration checks

  • Use reports to check data integrity.
  • Create reports for your different objects and include the fields that are most important to you. Sort by those columns to do a spot check on their utilization.
  • For Enterprise and above, you can use free apps from the AppExchange to tell you how complete records are or how much a field is used – Field Trip and AddressTools Free V4 both are free.

  • Use SOQL effectively to validate data after conversion.

  • 1
    I would also add to be aware of integrations that you may have in the system or code that generates records based on your imported data. EG if you are uploading historic "Closed-won Opportunities" data and you have an integration to create invoices when an opportunity becomes closed-won you may not want to create a load of invoices in your external accountancy system. If you have code that generates additional records within your org make sure that they are actually creating the records as expected.
    – Francis
    Dec 15, 2014 at 15:53

It is good to go with Salesforce user License, with proper Entities of meta data matching and we should meet this requirement with Primary Key and External Id matching, Data Validations, See the count of Data SYNC using reports in Salesforce also by tracking Success and Failure messages.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .