Skip to Content

18 Tips on CRM Data Migration

By Salesforce.org December 18, 2019

Collaborate to improve your CRM data migration

By: Alejandra Neyra, Data Analyst/BI Manager, Council of International Schools

Working on a nonprofit CRM data migration from one system to another? Here’s what I learned and what I wish I had known before starting the data migration.

Lesson 1: Create a timeline, but don’t be afraid to adjust it when necessary.

We decided to apply the agile framework and divide the work into two-week sprints. We thought we could do the migration of one service area in one sprint. We have four service areas, four sprints, eight weeks. Voilà!

The migration for the first service area took two sprints, as was the case for the rest, yet we kept talking about a two-month project. Adjusting plans would have helped managing budget, timelines and expectations from management and each service area that was waiting for their data to be migrated to Salesforce NPSP.

Lesson 2: Familiarize yourself with the different tools, add-ins, and apps available in the AppExchange that can facilitate the design process, data cleaning, data imports and data validation. Check available options in AppExchange before doing any time-consuming manual processes.

Below are some of the tools we used and worked well for us. Several providers offer their products to nonprofits for free or at a discounted rate.

 Planning and defining requirements Importing data   Data cleaning and validation
  • Confluence is a collaboration tool that help teams share knowledge. Free for nonprofits.
  •  LucidChart is a solution for visual communication and cross-platform collaboration. Free for nonprofits.
  • Data Loader is a free Salesforce client application.
  •  Dataloader.io is free for up to 10,000 records per month.
  • Spreadsheets
  • ASAP Utilities is an add-in for Excel. Free for use by nonprofits, contact them via email after the 90 days trial period expires.
  • Power BI Desktop is a business analytics service.
  • Field Trip App(AppExchange) reports on overall field use.
  •  Elements documents the Salesforce org and processes around it (not free, but useful).

Lesson 3: Choose only one channel of communication with your Salesforce implementation partner.

Daily communication was happening through Slack, Confluence messages, via e-mail, and Chatter. After some time, it became extremely difficult to find files or conversations. Having one channel of communication would have prevented this issue.

Lesson 4: Simplify your existing data model.

Transitioning to a CRM is the perfect opportunity to recreate the data schema, eliminating unnecessary objects or entities and relationships. Your organization has evolved since the last system implementation, and the new data model should reflect this progression.

For example, we eliminated 32 custom objects in the new data model, which made it easier for internal users to understand it, interact with Salesforce NPSP and generate reports. Internal users now rely on this knowledge and can generate solid reports for analysis, mostly without requiring any technical support.

Lesson 5: Make changes at the end of each sprint.

Review followed by adaptation is a core principle of the agile framework. However, suggesting actions for improvement may prove difficult if your field of expertise is not data migration. If a process is taking too much time, most likely there is a better way to do it.

For example, the migration created a significant amount of duplicate contacts that we had to clean up manually. It was a time-consuming task that we could have done without in our time-constrained project. Later, we found apps available in App Exchange that can identify and clean up duplicates reducing manual work.

Lesson 6: Understand the differences between the data model in your legacy nonprofit CRM and Salesforce NPSP, and how these differences will impact the migration – and the spreadsheets.

Our data model in our legacy system consisted of a contact associated to one or many business relations. The new data model in Salesforce NPSP consists of a contact associated to one or many affiliations. While it sounds similar, it is not! This difference required us to recode contacts to fit the NPSP model.

Lesson 7: Only migrate essential data to Salesforce.

This takes time up front, but will save a significant amount of time once the migration starts. Make a list of the fields and historical data that will be migrated to Salesforce.org NPSP. Confluence is a good tool to record this information. Make relevant backups, but do not spend time migrating data that has not been used in the past nor would be used in the future. The result will be a user-friendly system with relevant information for internal and external users.

Lesson 8: Develop a high-level vision

Take time to understand the new data model, the fields in each object, the relationships among fields, but also the formula fields, workflows and process builders that are expected to generate new data. Understanding the core of the model will expedite the migration as you will know which fields must be migrated and which fields will be generated by Salesforce NPSP. Here’s a useful Trailhead trail from Salesforce for more on administering NPSP.

Lesson 9: Create a clear API naming convention.

The Salesforce Admin and Data Scientists/Analysts need to work with API names all the time. This means that they should have clear names.

API names can’t be changed once they are added into workflows and process automations, as there is a risk the automations would break. So make sure to have a consistent API naming convention before building automations in Salesforce. We worked on a naming convention, but details like this were overseen during the migration as process automation was happening in parallel. This affects the work of the team every day.

Lesson 10: Use a new naming convention for custom fields that replace standard fields in Salesforce NPSP.

Several fields from our old CRM were migrated that are standard fields in Salesforce NPSP, yet the standard functionality did not meet our requirements, which lead to the creation of custom fields. These fields were differentiated by using lower case, instead of upper case, at the beginning of each word.

Modifying the naming convention of new custom fields could have prevented confusing internal users with standard and custom fields that look alike.

Screenshot of custom fields

Lesson 11: Have a clear naming convention for files used to migrate each object.

Having a system in place to easily identify the files for upsert and the errors that were generated with each upsert per each object will help validate whether all data was migrated, do cross checks between the two systems, and find these files when needed.

Lesson 12: Get any tool that can help clean up the data.

Nine years of data resulted in large and complex spreadsheets that needed to be cleaned. Find and use available tools to help clean the data. Examples of cleaning operations that are needed are recoding IDs, merging duplicate records, renaming dropdown values, changing phone number formats, and capitalizing names.

Lesson 13: Choose the correct format to upsert date fields in Salesforce.

Standard DD.MM.YYYY, MM.DD.YYYY, YYYY.MMM.DD or any other possible combination may result in errors – yes, we tried them all. The following format YYYY-MM-DDThh:mm:ssZ worked to migrate date fields – and yes, dates must be modified in all spreadsheets to do the upsert in Salesforce. (Note that an upsert means to insert rows into a database table if they do not already exist, or update them if they do.)

Screenshot of date fields

Lesson 14: Validate that the correct email addresses have been migrated for each contact.

We validated the accuracy of emails after migrating the object “Contact”, but we did not perform further validations after migrating fields in related objects which displaced about 800 e-mails. Monitor email addresses if you want to prevent this from happening. Email is the preferred method of communications from many, and you can’t afford to misplace this information.

Lesson 15: Merge duplicates that were created in Salesforce NPSP once your contacts have been migrated.

This is time-consuming, but it is important to merge duplicates before distributing Community/Portal login credentials to external users. Otherwise, one user will receive two login credentials which will confuse them as well as create unnecessary clutter.

Lesson 16: Document all errors that occur during the migration.

Document all errors that occur during the migration and make them visible to the organization and the implementation partner. The documentation made it easier to decide which of these issues were so critical that they needed to be resolved before the implementation partner completed the project.

Photo of calming office decorations inspired by Zen

Lesson 17: Keep calm.

As the migration gathers steam, you will be downloading information from your old CRM, cleaning up files to upsert, cleaning up error files from the upserts that have taken place, cross-checking data from your old CRM with that in Salesforce, identifying missing data, identifying errors, cleaning up data that has been migrated in Salesforce, handling complaints from internal users who are missing data, and so on, and so on. Get moving to de-stress (and yes, there’s even a Trailhead trail on movement basics!).

Lesson 18: Celebrate small victories.

Set milestones in the project and then celebrate achieving them. The big party to celebrate the completion of the project is important, but it’s more important to celebrate the small accomplishments that will keep you and the team going.

For more tips, keep learning about NPSP here on Trailhead.

Learn More

About the Author

Alejandra Neyra

Alejandra Neyra

Alejandra Neyra is the Data Analyst & BI Manager at the Council of International Schools. Alejandra is responsible for providing relevant data analysis and reporting across the organization, applying different quantitative and qualitative techniques. She also implements initiatives to encourage schools and universities to use data for decision-making. Her previous experience includes working as a Data Analyst for the American School of Doha and as Program Assistant for the U.S. Treasury Department, Office of Technical Assistance. Alejandra has a Master’s Degree in International Development Economics from Hochschule für Technik und Wirtschaft, Germany, and a Bachelor’s Degree in Economics from Mount Holyoke College, USA.