When you move into Salesforce.com, almost inevitably you’ll have to tackle the job of bringing over your historical customer and company data. There are a couple of preliminary steps involved before you start doing imports into Salesforce.
First is to identify where all your customer and company information resides today. That could be in your email client (i.e. Outlook), an accounting system, spreadsheets, internal databases, or a legacy CRM system. Next is to think about the information you have in these repositories and the value of that information if it resided in Salesforce. As you’ll hear us say, "Just because you can put it into Salesforce, doesn’t mean you should."
Once you’ve identified the sources of your company data and determined what you’d like to migrate into Salesforce.com, the data migration process is as follows:
- Tour of the client’s current CRM to understand customization and how used
- Backup copy of the database delivered
- Tables identified for import
- Field mapping
- Salesforce system considerations addressed
- Initial import
- Validation by client & corrections made
- Client acceptance (sign-off)
- Final backup delivered
- Final import
- Post Go-live support
Below is the data migration process in more detail:
Tour of the Client’s CRM
Since everyone uses a CRM differently, we start the data migration process by having the client give us a tour of how they use their current system. In this phase we’re looking for unique customizations and to gain an appreciation of their business flow. Additionally we’re looking for how the client interacts with their customers using things like Tasks, Calendaring, Notes, Actions, Documents, Email Templates, etc. With this headset and a checklist of things to be sure to look for, we’re ready to start the forensics on the database.
Backup Copy of the Database
When migrating from a SQL database such as ACT!, GoldMine, Junxure, Advent, Sage CRM, SalesLogix, or Microsoft Dynamics CRM, the first step is to get a backup copy of the database and spin it up locally on a SQL server. This can be accomplished by the client providing us access to their system so we can perform the backup, or placing the backup on a secure FTP site for retrieval.
ERD & Identify Tables for Import
From there we’ll "crack" the database and create an ERD (Entity Relationship Document) to visually see the table structure, as well as get an initial record count for each table. There can be hundreds of tables in any CRM database, but just like Salesforce, not all may be utilized by the client. At this step we’re out to identify the tables that are being used by the client so we can start mapping fields.
A spreadsheet is created that can be shared with the client that has a tab for each table in the legacy CRM system along with the fields, data type and record counts. We’ll map each field that is being used by the client to a corresponding field in Salesforce. This is a tedious phase of the process as a CRM system can have hundreds and hundreds of fields to map.
Salesforce System Considerations Addressed
As part of the import process there are a multitude of additional considerations that must be addressed in order to have a successful import. Things like record ownership, how to handle inactive users (records owned by former employees in the legacy system that will not be users in Salesforce), required fields, system "time/date stamped" fields (i.e. record created date, record created by, last modified date, last modified by), security and sharing settings for record access, etc.
Once the initial mapping is complete, we’ll do some scripting to automate the transformation of data from the legacy CRM’s table structure to facilitate an automated import into Salesforce.com. We do this because data imports are an iterative process, and by spending a bit of time at this stage to automate procedures, we can make later revisions (and the final import) in a lot less time than the initial import.
An example of transformation would be that in the source database Account information might be stored in one table and the addresses for those Accounts are stored in a separate table. In Salesforce the data model is such that the Account address and Account information is stored in a single table, so we have to collapse the information from two tables down to one.
Additional work may also be required to clean up and standardize formats. For example, pick list values in the source database might be stored as a numbers which need to be translated to text to be useful to Users. Emails may be stored in raw HTML in the source database or contain additional header information which needs to be stripped out to make the records useful and legible to Salesforce Users.
The initial import can be done in a production environment if the client is new to Salesforce. If the client is already using Salesforce, we’ll do the initial import into a "Sandbox" or testing environment (space permitting) as not to impact current users and "live" data.
Validation by the Client and Revisions
After the initial import, we’ll give the client a tour of their data inside Salesforce.com and ask them to validate the import by taking a couple dozen client records from their current system and compare the information inside Salesforce.com. We do this because the client knows their customer data better than us, and they’ll know what to look for to ensure it’s accurate.
It is expected that based on the client’s feedback adjustments to the mapping and import procedures will need to be made. Because we’ve invested the time earlier in the process to script many of the procedures, subsequent refreshes of the data can happen quickly.
Client Acceptance of the Import as Accurate
The process of refining the data mapping and procedures with the client validating the import will repeat as needed until the client has signed off that the import is correct.
At this stage of the process we’ll establish a cutover date with the client. In many cases to minimize downtime by users (and the productivity impact to the business), the client will "freeze" or stop using their current system on a Thursday or Friday, we’ll grab another backup copy of the client’s database to ensure we’ve got the client’s latest information, and perform a last and final or "delta load" over the weekend so the client can go-live early the following week. Once the final pull of the database has been migrated, the client will stop working in their legacy CRM and work solely in Salesforce.com.
Post Go-live Support
For post go-live support, we’ll keep resources available the day the client goes live to respond to any issues that may have been missed during the validation and acceptance phase.
Besides the databases mentioned above, ShellBlack.com also has experience migrating data from RedTail, ProTracker Advantage, Grendel, Tamarac, SmartOffice, and FileMaker to Salesforce.
Other Salesforce Services