Author: David Masri Founder & CEO

The nature of data migrations is such that it's often not on the critical path, except as a dependency to start of QA\UAT. Because of this, early in the project, data tasks are often looked at as lower priority, and not set to start until midway through. This is a mistake, for a few reasons:

1. As your team is gathering requirements, they will have questions that will be very easy to answer if you have the data. Questions like "What are the Current Activity types?" or "How is the sales process defined today in terms of stages and steps?". Having these answers at your fingertips helps the whole team.


2. You never know what's going to go wrong. Suppose you (or your client) is having trouble exporting or understanding the data, or there is some issue with security clearance that has to be resolved before you can be granted access, or you run you into some serious data quality issues that need to be resolved, or the person who scoped the work underestimated the complexity of the transformations needed. Discovering things early can give you months of extra time to mitigate risks.


3. During your end of sprint demos, your team can demo the system, with real data that users can relate to.


4. Data analysis is needed to confirm the information given to you and the rest of the Salesforce development team is accurate and reflects reality. Often it only reflects the majority of cases and is missing at least some of the edge cases. Once these edge cases are brought to the team's attention, they may do some investigating which results in major changes to the Salesforce design. It's better for the project to catch these things early.

Start Early.

This article is adapted from my book: Developing Data Migrations and Integrations with Salesforce.