Almost every project I have worked on involving a brand new Salesforce org has included some aspect of data migration. Migrating data can be a complex puzzle that can frustrate the most experienced Salesforcian (side note: not sure if this term has been used before. If not, dibs on credit!). At first blush, it can seem like a relatively easy task that should not take much time to accomplish. You just take data from a few tables over here in the old application, load it into some spreadsheets, then stick it into Salesforce… simple, right? Not so fast, kemosabe! I have been guilty of making this rookie assumption myself and I would like to share some useful insights I have found so others do not fall into the same trap.
For this article, we will use the following entity relationship diagram (ERD) as reference.
Understand the Data Model
If you have ever put together a puzzle, what is the first thing you do? You look at the lid to see what the final picture looks like. The same goes with migrating data – you need to review the data model so you see how the data will fit into Salesforce. You need to have a solid understanding of how the objects are related, which objects are dependent upon others, and the order in which the data needs to be loaded.
Map the Data
Once you know how the data is organized, you need to dive into each object and build a field-to-field mapping. This should be a simple task that should be done with the data owners. They know their data better than anyone! Typically I start this process on my own and map as much as I can before going to them, but they need to have final sign-off that the data from the fields in the originating application map correctly to the new fields within Salesforce.
Start with the Foundational Data
Once you review all the data being migrated, you will have an idea which objects can stand alone and which tables have references to other objects. Most of these independent objects are what I call foundational data points, which are typically master objects in Master-Data relationships or objects that do not reference other objects (think Account and Product shown above).
If you think about the Account object, you only need to populate the Name field to create an Account. Nothing else is required so this is typically an easy object to map and load first. With that being said, there are always exceptions. An account may require a territory, so the territory object would need to be loaded first.
The Product object also requires very little data to create a new record and does not reference any other objects. This object would also be one of the first to have data loaded.
Build on the Foundational Data
In the sample ERD, you can see that Contact and Opportunity reference the account object. Once the opportunity records are loaded, you can then load the records in the Quote object since it references both Accounts and Opportunities. Finally, Quote Line Items can be loaded last since quotes and products have already been loaded.
By following the steps outlined above, you will eliminate the biggest issue most users face when migrating data: confusion! The most important thing you can do during a migration is to build a detailed understanding of the data. Once you know how the data is structured in the old application and how that structure has transformed in Salesforce you can build a proper plan to migrate the data.
In my next post, we will dive into some of the more technical details needed to hook the data together and load it into Salesforce.
droppinknowledge.wordpress.com 