Let’s imagine, as part of a new Salesforce implementation, you need to migrate data from a legacy system. Let’s also assume the data can be exported into a .csv file. So, how many rounds of data migration should you do?
Since the title gives away the answer, let’s discuss the rationale.
If users stopped using the legacy system the moment they provide the first version of their data, you could probably get away with fewer rounds. But that’s an unrealistic situation. More likely, users will need to continue using the legacy system up until the entire Salesforce implementation is completed.
Thus, it’s normal to build scripts and processes that transform the legacy data into data consumable by Salesforce. This includes creating Salesforce templates with the related object fields and then massaging the legacy data so it fits the template.
Building these scripts and processes typically happen during the development phase. As a data architect, you’ll probably need multiple attempts to perfect the script, and will load the data into a development sandbox. This is considered the first round.
The second round occurs during user acceptance testing (UAT). That’s usually performed in a second sandbox dedicated for this purpose. The goal here is to confirm the scripts and processes are working end-to-end. It also allows the users to confirm the accuracy of the migrated data.
The third and potentially last round is when you receive the final and most recent data extract from the legacy system. From that point onwards, users should not touch the legacy system. The data is loaded into the production instance Salesforce and users begin using it.
The takeaway
Usually three rounds of data migration is needed to confirm the data manipulation and manual processes.
There are some cases in which a fourth round is needed. If you think you know, click reply and let me know.