Options for Data Migration into Salesforce

For other objects’ legacy data (such as Opportunities, Cases, and Activities) that you want to have in Salesforce, you have to enter information manually or use the Data Loader, which is a data import and export tool that comes with Enterprise and Unlimited editions to automatically migrate data into Salesforce.

Using the Salesforce Data Import wizard

Launching the Salesforce Data Import wizard.

If you’re an administrator, you also see an Import button in the upper-right section of tab home pages. For example, if you want to import your company’s Leads, click the Leads tab, and then click the Import button, which is to the right of the page’s displayed list view title. Steps and tips for using the import wizard for different objects’ records varies:

• Import Leads: Only a user with the Import Leads permission can perform this operation.
• Import Contacts and Accounts: Salesforce uses the same wizard that can take you through importing Contacts and/or Accounts. Individual users also have the ability to import their personal Contacts and Accounts.
• Import new campaign members or update them when linked to a campaign: Salesforce uses the same Data Import wizard, but this time exposes just the Campaign Member object to update marketing statuses for Leads and Contacts.

Investigating the Salesforce Data Loader

As someone famous once said, with great power also comes great responsibility. Only use Data Loader if you’re comfortable with understanding how objects, records, and workflows and/or triggers relate to each other. Data Loader is a very powerful tool for nontechnical users. You can export data, import data, accidentally overwrite and delete a lot of data, and set off a domino effect of workflow rules if you’re not careful. Always make sure to make a backup of the data if you’re planning to make an update. You might be problem-free without a backup until that one time a mistake is made and you can’t undo the 1000s of fields you’ve overwritten.

Without getting too technical, experts link data by using the Salesforce application program interface (API) to enable your technical people to access data programmatically. The Salesforce platform is used to customize or integrate Salesforce to do even snazzier things than what you can do with it out of the box. And before you suffer from jargon overload, a platform is basically a collection of rules and commands that programmers can use to tell a program — Salesforce, in this case — to do certain things. To access the Salesforce API, though, you must have Enterprise or Unlimited Edition.

Migrating your legacy data into Salesforce

Determining your data sources

As you go through your preparation, assess what and how much information needs to be in Salesforce. Here are some tips for this step:

• Garbage in, garbage out. When you move to a new home, you usually look through your old home’s closets and decide what to haul with you and what to throw away. Moving data requires the same type of evaluation.
• Make a list. Catalog the different data sources, including what types of records, what range, and how many.
• Design a storage plan. Work with your customer relationship management (CRM) project team to determine where different information should go — and why.
• Think about the timing and the sequence of the import. For example, many companies create user records first, then import Accounts and Contacts, and finally, migrate and append Opportunities.
• Keep it simple, if possible. The more complicated you make the migration, the greater the impact on your timeline. Assess the level of effort versus the potential value of the effort.

Preparing your data for migration to Salesforce

If your legacy system doesn’t make cleanup easy, you might prefer to bring all the records into Salesforce first and then use the Salesforce data management tools to clean data later. The risk is that people with the best intentions may still succumb to human nature and not want to focus on the cleanup effort once the data is already in the new system.

Regardless of when you do it, cleaning data is not glamorous work, but it’s gotta be done, and should be done on a regular basis. Here are a few tips as you prepare your data:

• Export to a simple format. Oftentimes, it’s easiest to export data to applications like Microsoft Access or Excel, with which you can delete columns, sort rows, and make global changes.
• Strive to use standard naming conventions. If different data sources refer to Accounts by different names (for example, IBM versus International Business Machines), now is a good time to standardize naming. This can help avoid duplicate record creation.
• Edit or add fields in Salesforce to support the migration. For example, if your pipeline reports track margin per Opportunity, you need to build a custom Opportunity field to support margin data.
• If your existing data source has unique record IDs, migrate those IDs to a custom read-only field. You can always delete or hide the field at a later stage. Not only can this help you verify the accuracy of your migration, but those IDs might also come in handy for integration (especially if you don’t plan to shut down the other data source).
• Map your data columns to field names in Salesforce. For example, the Company field in Microsoft Outlook typically maps to the Account field in Salesforce. Some system administrators even rename the column headers in migration files so that they exactly match field names in Salesforce. Doing this minimizes the migration madness.
• Conform your data to fit Salesforce standards (or the other way around). Each field in Salesforce has certain properties that may include size limitations, decimal points, date formats, and so on.
• Add a Data Source column to your import file and map it to a custom field in Salesforce. By doing this, you can defend where data came from.
• Assign the correct owners to records wherever possible. If you don’t have all records assigned, the owner defaults to whichever administrator is executing the migration.
• Gain acceptance from stakeholders of the files you’ve prepared. At least if you offer them the chance to review, you avoid surprises.

Testing the import into Salesforce

• Select a small sample of significant records. The higher profile the records, the better — especially when reviewed by a stakeholder.
• Remember to turn off workflows. You don’t want to annoy other users by unnecessarily alerting them when test data flows through the workflow rules. Some of you may think that it’s helpful to keep certain workflow rules on especially if they were built to prevent bad data from coming in. This is not true. Do the work ahead of time and prepare the data well, before importing.
• Review page layout. Consider adjusting the page layouts to make validating the data import easier. Put fields in Salesforce in similar screen locations to those of your legacy systems.

Analyzing the test data results

• Build a custom report that allows you to look at the record data collectively.
• Open a record, if necessary, and compare it against the import file. Confirm that the record’s fields show what you think they should show.
• Build a custom view from a relevant tab’s home page to see your imported data laid out in columns on a list page. Users could go to a report, but a view keeps them focused.
• Validate the data with selected stakeholders to get their feedback and support that the test data results look correct. It’s not enough that you think the test import was accurate. Your end-users are the ultimate test.
• Adjust your process or make changes to the import file or Salesforce based on the results of the test import. For example, maybe you forgot to map a field or the data didn’t import correctly because of a field’s properties.

Migrating your final data

Here are a few suggestions for this step:

• Communicate expectations with your users. If you’re moving from one system to another, you might have a lapse in which data must be updated prior to going live.
• Do it during downtime. If you have significant data, consider running the migration during nonworking hours. Especially if the system is live for some groups of users already, this may avoid confusion.
• Save the log files of records that didn’t successfully import. The error messages are fairly intuitive, and you can usually see common rejection reasons for why certain records didn’t get imported. Make sure to spend time determining whether the rejection is caused by a data-formatting or quality issue as opposed to a pesky workflow rule that you didn’t intend to fire.
• Build yourself some cushion for error. Don’t try to execute the migration the day before sales training. Something unanticipated could happen that prevents successful completion.

Validating and augmenting your data

Make sure that data is stored in the correct fields and that values make sense. If you see an address in a phone field, you need to clean your data or fix your field mapping. Strive for perfectly imported data — but expect less than that, too.

Prior to rolling out Salesforce, take the extra step of manually or automatically updating some records to wow users and drive more success. When giving a demonstration or training, show users these fully entered examples and let them know the potential for Salesforce.

Once you have everything in Salesforce, the fun begins!