In all the excitement of selecting a new database, it’s easy to overlook a big piece of the implementation project—migrating data from your AMS to your new Salesforce CRM. The more you know about data migration, the better prepared you’ll be for your implementation project.
Think of migration as a data management opportunity
When you’re planning a move across country, you begin organizing and Kondo-ing your belongings long before hiring a mover. It’s the same with moving data. There’s plenty you can do to prepare for data migration, even before selecting your database partner.
- First, make sure your association has a dedicated internal project manager to oversee implementation and data migration. They’ll keep your team on schedule so when it’s time for migration, your data is ready to go.
- Take a hard look at the data you currently collect and manage. You don’t want to migrate data you don’t use or need. Review documentation or talk to staff about prior data cleansing projects. Find out what decisions were made about data to keep, archive, and delete. Take this opportunity to establish and document new practices and rules for data entry and management.
- Talk to staff throughout the organization about their reporting needs. Ideally, you had these conversations during the requirements analysis process, but if not, do it soon. Decide which of their needs to include in requirements.
Decide which data to migrate from your AMS to Salesforce
Your implementation timeline and budget will depend upon the quality, format, and amount of your source data—the data you want to move into Salesforce.
- Identify the data you plan to use and want to move into Salesforce. Where is it now? Which systems? Who are the owners of those systems? These people are your subject matter experts (SMEs). You’ll need their knowledge as well as their involvement and buy-in.
- Which records have the data you want to move? How far back in time will you go? Industry regulations and/or business rules should guide these decisions. Always preserve giving/gift data. You may decide not to migrate data from prospects or leads that haven’t interacted with your organization in more than three years. If your data goes back a long way, you can choose to import data summarized by year instead of preserving each separate transaction.
- How will you handle financial transactions, particularly open orders and invoices? Would it be better to migrate on a specific day of the month, quarter, or year?
- Which existing third-party applications will be integrated with Salesforce and which ones will you drop in favor of Salesforce-based solutions, for example, Pardot? Talk with your Salesforce partner about the migration implications of both approaches.
- Does all the data you plan to migrate still support your organization’s strategic and business goals? If not, assess whether you should continue collecting it.
- Determine how the data to be migrated will be delivered by the source system owners, when (deadline), and in what format.
Assess AMS data quality and format
Staff members rely on “rogue” databases, such as an Excel spreadsheet or an old CRM that’s no longer supported, for several reasons.
- They haven’t been properly trained to use the “official” database.
- They can’t get the data they need from the database or they can’t get it in a useful format.
- They don’t trust the data in the database.
Don’t give staff any reason to resist adopting Salesforce and keep using an old database. Ensure the needs of these users are met, and make sure they can trust the integrity of the data you’re moving into Salesforce.
Data cleansing is a key element of the data migration project. Set aside time before migration to clean up dirty data: discard duplicate records, correct or remove inaccurate and outdated information, and complete fields in records. The extent of the data cleansing required will show how badly you need more stringent data entry procedures and business rules.
Clarify who is responsible for the cleansing project. Will staff do it or will you outsource the project? Decide when it needs to get done and, if staff is handling it, what system they’ll use. If you’re migrating data from more than one source system, make sure you use a common unique identifier for the same records across those source systems.
Begin the data mapping process
Data mapping is the process of mapping (matching) data fields from a source file (an export from your AMS) to fields in Salesforce. To do this successfully, someone on your project team—an IT professional or Salesforce partner—must understand how data is structured in every source system and how that structure compares to the Salesforce structure.
There must be a place for all source data in Salesforce. The tables, fields, and values in the source system(s) get mapped to the different Salesforce Objects. Most likely, additional Objects and processes will be created in Salesforce to accommodate all the data you wish to migrate, manage, and use.
Decide who’s responsible for creating the data mapping document and when they must complete it. If no one on your organization’s staff has this expertise, ask your Salesforce partner about taking on this responsibility. You don’t want to wing it!
Allow enough time for migrating data from your AMS to Salesforce
Now you can see why we suggest getting a head start on this project. Plan to take care of data cleansing before the migration project begins so you can focus on other implementation tasks.
Factors that impact the migration timeline are:
- Number of source systems
- Number of table/fields in each source system that must be imported
- The amount of data cleansing required
- Complexity of data mapping required
Make sure any staff involved in data cleansing, data validation during migration practice runs, and user acceptance testing have clear calendars so they can take on this additional responsibility. Don’t plan a data migration project for busy seasons, for example, the lead-up to a conference or board meeting.
Close in on the data migration milestone
Your Salesforce partner will use a specific migration tool and method based on the number of records, complexity of the source data, differences between the source system(s) and Salesforce data structures, and talent on hand to do the work, i.e., your staff, Salesforce partner, or other consultant.
Decide who will conduct the quality assurance (QA) and user acceptance testing (UAT) in a Salesforce sandbox environment. How many times? Who’s creating the testing scripts and when? Remember, you can outsource these tasks if your staff doesn’t have the expertise or bandwidth to handle them.
Data migration is an iterative process. You’ll do multiple practice runs before the final migration. Your staff must be involved in validating the data during this process.
One more item, your final task: celebrate with your project team once migration is complete. Data migration is more than a “small win” milestone—it’s a significant achievement in your Salesforce implementation.
If you’d like to learn more about data migration or other aspects of Salesforce implementation, we’d love to answer your questions and talk with you about our experience helping associations switch from an AMS to Salesforce.