a Salesforce Data migration can feel very overwhelming, especially if you have a large volume of data. It takes a ton of time and energy and if not done incorrectly, can lead to dirty data and unreliable results, which leads to distrust in the entire system. In a very bad case, user adoption drops off, and the system becomes completely useless to your organization. Good data is paramount.
Data migration isn’t fun. It’s manual, time-consuming, detail-oriented work. And a lot can go wrong. As consultants, we’ve helped keep organizations do so successfully, and we’d like to share our Salesforce data migration best practices with you.
1. Plan Carefully to Ensure You Measure Twice, Execute Once
Your Salesforce Data Migration Cadence
We work with two different kinds of data migrations – regular data flows between two key systems and one-time migrations during a shift to a new system. If you’re setting up an integration between two business applications, data will move between them often. However, if you’re moving everything to a completely new application – Salesforce in this case – you’ll need to prepare for a much larger project. In this post, I will be discussing the latter project and how to migrate your data from a legacy system to Salesforce.
The tips I share, however, are often applicable to integration setup and maintenance. If you need help with a reliable integration between Salesforce and another application, our team can provide consulting, development, and support. Contact us to learn more.
Scope, Timeline, & Budget Definitions
Before data mapping starts, before you start writing out directions for your data teams, you’ve got to map out the entire project through the scope, timeline, and budget. This step feels tedious but results in a plan that reviews and prepares for every potential risk and allocates all required resources beforehand. In particular, it helps us decide how much data we migrate and how far back we go for any entity in your source, as well as build target data models.
For example, given the goals and budget of a Salesforce implementation, it might be enough to migrate the following:
- Six months of cases because the support team mostly closes them by then and/or support metrics aren’t valuable past six months
- One year of opportunities to allow for year-over-year reporting
- All accounts, as the client is likely to have continued business with them
Business Goals & Key Stakeholders
Make sure to include all key stakeholders; anyone who regularly interacts with the data should have a leader included in the project to represent their specific needs, especially those who interact with relevant data in upstream and/or downstream systems. Salesforce often needs to work well with other systems, and prepping upstream/ downstream systems to be the source/ target of platform data is paramount. Looping in all relevant parties ensures your Salesforce data migration goals align with your overall business goals in the final application.
Take Only What You Need
When migrating data from one system to another, you’ll probably find data that you don’t use any longer. It may have been important once but now sits unused in a category somewhere, just taking up space. You can back up this data somewhere to reference later, but unless you need it, I recommend keeping it out of your new system; it will just bloat the application and weigh it down. It will needlessly increase the time and budget needed to get new systems online without commensurate benefit. Additionally, purchasing additional data storage beyond your Salesforce license allocations can be prohibitively costly, so keeping data volume down is very important. Large data volumes may even necessitate architecting your Salesforce solution drastically differently. Contact us to learn more about large data volume solutions.
Document Everything
A clear plan is written down, so document all steps involved. Establish naming conventions, define the purpose and format of every data field, especially custom fields. The latter is where we see the most problems – custom fields need clear definitions so that all team members involved with the data understand how to use them. Have a well-defined plan, especially for populating reference fields (lookups and master-detail relationships). You may even consider a script in certain cases versus manually data loading using a data loader or similar.
Pad Your Timeline
A Salesforce data migration isn’t necessarily difficult, but it takes time. The larger the data volume, the more the data variations to handle. And, more importantly, it requires focus and attention to detail – the devil is really in the details. One of the biggest issues we see in data migration projects is a loss of focus, which leads to mistakes. Not only should you set aside enough time to get through the process, but you should also pad the entire project for the breaks you will inevitably need. Consider budgeting additional time for a couple of practice rounds for representative sample data in one or two sandbox environments (explained in more detail later on in this post). It will save countless hours and heartache, not to mention deployment delays on the day of the release.
This due diligence makes the entire process smoother and is a crucial step.
2. Clean Your Data
Migrations are the best time to clean up your data. As I mentioned earlier, dirty data creates a ripple effect that negatively affects the entire business. So, before you put it into a new application, clean it up to protect your business.
Make sure to find and remove all duplicates, clean up those address lines, and remove irrelevant fields and values. You’ll also likely come across empty fields and missing information, and this is an excellent time to track down that data. Use tools such as Field Trip or Snapshot to get familiar with data density and cleanliness. Budget time for running by your data cleanliness findings with business stakeholders; it’s not just a technical endeavor!
Data Validity
Data validation should take place in two stages in your data migration project – during this cleaning and prep phase and at the end, during QA in the new application. Here is where a more analytical and detail-oriented approach pays off. Look for data falling outside of range constraints, established expression patterns, and fields violating data-type constraints.
Also consider the accuracy of data that can’t be reviewed at a glance. This may require validation via an external data review tool. For example, last year, I moved into a new construction home in a very new neighborhood. My mailing address wasn’t considered a “valid” address for almost six months. It took a few after that before it showed up on Google. All online ordering became a pain; I almost always had to call vendors to complete my order because my address would show as invalid. I spent a lot of time on the phone due to an increase in home shopping during the pandemic. Was it a huge pain? Yes, definitely, but I understood – no one wants to lose an order due to an incorrect address. The systems were just doing their due diligence.
Your data should be uniform, consistent, and correct before moving it into your new system. Make your job easier in the future by documenting these rules and putting workflows in place to ensure your team members adhere to them and keep the data clean.
Back Up the Clean Data
Then, back up this clean version of your data, just in case your first attempt at the migration doesn’t go according to plan. This is a great time to establish a regular and frequent backup schedule.
3. Data Migration Methods and Tools
We recommend migrating your data into Salesforce using the Salesforce API and Data Loader.
Salesforce Data Loader and API
The Salesforce Data Loader and Bulk API work together to move data in and out of your applications on the platform. Salesforce provides various APIs, like SOAP and REST APIs, to move different data types in and out of the system. As we’re focusing on migrating data from a legacy application to a new platform permanently in this guide, I recommend using the Bulk API tool.
If you’re managing a relatively basic Salesforce data migration, you may be able to use these tools without SQL experience. However, if you’re moving a lot of data and need custom rules and workflows in place, I highly recommend working with an Apex and SQL-experienced developer. Our team can help you with this process or find a reliable resource in our network.
The devil’s in the details during this process. Sometimes this tool automatically updates data during import. For example, take care with your “CreatedBy” and “CreatedDate” fields. You’ll need to put a rule in place to maintain the data in these fields in your original system, or it will seem as if all records in Salesforce were created on the same day by the same person. You could end up losing quite a bit of crucial historical data. Carefully monitor potential changes to naming conventions, organization, and the data itself. You’ll need to think about these details during the initial planning steps, but we’ve helped clients catch major potential errors this far into the game too.
Object Order and Data Relationships
If you take any advice from this blog post, this should be it. Object order is crucial. The relationships different data points have with one another are built on a hierarchy and relationships, and your import process must respect and adhere to this data structure, or your data will not migrate correctly. Salesforce covers this in detail in this knowledge article, but here’s the recommended sample order for importing core objects:
- Accounts
- Campaigns
- Contacts
- Opportunities
- Cases
- Pricebooks
- Products
- Leads
- Contracts
If you vary from this order, it will affect the relationships between your data types and therefore negatively impact your data workflows. Please take care during this step!
4. Sandbox Test Run
The larger a Salesforce data migration project, the more likely you are to run into some unexpected problems. You don’t want to be scrambling to troubleshoot during the large-scale migration, so I highly recommend running a test with a sample size in a Salesforce sandbox.
A Sandbox is a duplicate version of your production environment. By testing your migration with a sample size of data in it, you’ll get a much clearer picture of how well your migration will go, how long it will take, and potential errors you’ll face. If/when your test migration results in errors, update your migration strategy accordingly and test again. When you feel confident you can run a full data migration with minimal errors, it’s go-time.
5. Migration
You’ve set up the necessary steps and protections. Now it’s time to launch. Our biggest recommendation here is to do so after business hours but have a few developers on hand to troubleshoot. We manage many of our deployments over the weekend to ensure we don’t disrupt work and can address any migration issues before business resumes on Monday.
Turn off automated workflows, processes, and email deliverability during your Salesforce data migration too. The last thing you want is a bunch of emails to go to contacts on accident.
6. Post-Migration Data Validation and Quality Assurances
Once all data appears to have migrated over to Salesforce, it’s time to run a data validation check. If any errors have popped up, troubleshoot and then reimport only the affected files to avoid creating duplicates in your new application.
Smoke test all of your workflows and encourage your key stakeholders from step one to do the same. The last thing you want to happen is to get three weeks into a new system and find an import error.
Keep your old system (and a few licenses tied to it) up and running for a few months, just in case you run into issues and need it available for reference. Once you feel confident in the adoption of the new system, you can retire it.
Next Steps for Your Salesforce Org
Congratulations! You’re finished! Now it’s time to reap the benefits of all your hard work.
If you’d like support during your own Salesforce data migration or need help leveraging the platform in general, our consulting and development team may be able to help. Contact us today to learn more.
