This is the third blog post in a series on managing data in Salesforce. Subscribe to be notified when a new post is published and check out the other blogs in the series.  

Anyone who has managed IT projects is likely to have seen the detrimental consequences of a data migration gone wrong — underestimated scope, poor execution, or over budget. To mitigate the risk of a bad data migration, these four steps are paramount. 

1. Clearly define and design.
   
   In a large or complex data migration with data from multiple sources and business owners, defining the scope of the project is a crucial first step. Take inventory of all data — where it resides, who owns it — to ensure that no data is forgotten and that users have all the information required to perform daily tasks. Produce useful design documentation during a collaborative requirements gathering phase.
   
   
   
   Design a visual ‘Source to Destination Entity Document’ to identify all of the data sources, their respective entities, and where they are mapped to in the new platform. For example, if your customer data is recorded on multiple excel spreadsheets managed by sales, but your order data is held  in relational database managed by finance, document this clearly and comprehensively.
   
   
   
   Ensure that this migration document is easy to understand and can be reviewed by disparate business units so that section owners can identify missing data entities. For example, marketing  can identify ahead of time that their crucial customer profiling database has not been included, to avoid last minute changes to scope. Later in the process, field level mapping documents should be provided, providing greater granularity of scope and transformation.
2. Analyze and clean all data.
   
   Make sure your data is squeaky clean before you migrate. This is the opportunity to remove duplicate records and redefine your data hierarchy. Clean data is the lifeblood of customer relationship management systems. In order for a CRM system to be successful, customer data should follow your standards, have all the required information, and should be duplicate-free. 
   
   
   
   Over time, and without clear data governance processes, it is natural for the quality and standardization to deteriorate. This deterioration affects not only the end product of your implementation, but also seriously increases development time and scope of the migration process.
3. Use an agile approach.
   
   Requirements will probably change and this will impact your data migration strategy. It doesnt matter what technology you are using to complete your migration; it’s important to follow some of the key features of Agile development projects in order to stay ahead of the game. Most importantly:
   
   
   
   Daily scrums. Impacting requirements changes to technical solutions is one thing. Knowing about them so late that it requires a re-write of the entire process is another. Ensure that the project team is communicating daily and that everyone is made aware of required changes. 
   
   
   
   Build migration routines incrementally. Group areas of development into logical chunks. This allows for partial migration, and allows users or stakeholders to get early sight of sample migrated data to identify potential issues.
4. Reconcile, reconcile, and reconcile some more.
   
   The basic requirement of any migration is to prevent unexpected addition or loss. But how do you know that the project is going to be successful? Reconciliation!
   
   
   
   Reconciliation represents one of the most important aspects of any migration project. It effectively audits the technical process to evidence that nothing has been added or lost in transport or during the transformation process. What and how much to reconcile is really down to what type of project you are undertaking. It's important to reconcile the key areas and success metrics of the project, but equally important not to spend unnecessary time reconciling every field. Some of the key things to reconcile:
   
   
   
   Currency data. Anything that means money should be totaled and compared between systems. 
   
   
   
   Record owners. Where systems have the capability to record user ownership of certain records (for instance, sales owning accounts and contacts), these should be reconciled between the systems. This is likely to test manually created mapping, as well as developed code.
   
   
   
   Entity row counts. It should go without saying that total row counts should be reconciled.
   
   
   
   Grouping. An excellent way to test a migration is to count anything that can be grouped. Whether that be counting the amount of opportunities against your customers, or how many opportunities have a certain products on them. 
   
   
   
   Lastly, does it all have to match? No. Some data may have been re-modeled, transformed, excluded, or not ported for various reasons. However, your reconciliation should take account of and be explanatory of this.

I hope these tips will help your next data migration endeavour.  Check back in two weeks for the next installment of this data blog series, in which I will detail data integration tactics. Or, subscribe to this series and receive blogs right in your inbox.