Salesforce.com Implementation -- Day Two

The first challenge: getting real data into Salesforce.com. We had two years of Account, Contact and Case data that we very much wanted to retain for tracking and reference purposes. Toward that goal, our Salesforce.com Sales Rep (Luke St. James -- he's GREAT!) had recommended that we get a Salesforce.com Partner to assist with the data migration. My boss had been speaking with them by phone, and they had been on-hand a week before for the SFDC demo. They had also provided us a quote for their services.

Six weeks, $50,000 US ... yikes!

To be fair, their fee included more than just the data migration from our old SQL database. It also included a full "business process review", data de-duplication of data from our legacy system, data migration into SFDC, and training for our Support staff.

On the otherhand, they projected this to be a 6-8 week effort, and wouldn't be able to start until the first of the year. I started looking for other options.

Through a little keyword searching on the "Help & Training" link, I discovered the Data Loader. The Data Loader is a client application that you download to your desktop. With it, you can bulk import or export data from your Salesforce.com instance. Eureka! This was handy.

To find the Data Loader, you must be the System Administrator:

1.) Click Setup (top of screen, just right of center -- see screenshot below)
2.) From the Administrator Setup menu in the left side bar, click Data
Management -> Data Loader

The best thing about the Data Loader is that it gave me my first glimpse into the architecture of the Salesforce database. Through the Data Loader, I could see every table (err, I mean object), and every field within those tables. I could not see data types, but seeing the object data structures was enough for now. I exported every object that the Data Loader could view.

The Data Loader creates CSV (Comma Seperated Value) files, which you can view readily in Excel. As I skimmed through all the CSV files, I became aware of all the fields in the database -- even the ones I couldn't see from the Page Layout screens. This was cool!

I started to see how object relationships were handled. For instance, in the Contacts.csv file that I had exported, there was no field named "Account". Instead, there was a field labeled "AccountID", which contained a unique 15-byte alpha-numeric string of characters. I grabbed a random Contact, and tried to see if the AccountID had a matching value in Accounts.csv file. It did ... bingo! So that's how they relate Contacts to the parent Account.

It quickly became clear that I'd have to load my legacy data in a systematic way:

1. Import all Accounts
2. Export all Accounts to get their AccountID values
3. Manipulate my Contact import file, replacing the Account Name with this AccountID value
4. Import all Contacts
5. Export all Contacts to get their ContactID values
6. Manipulate my Case import file, updating the appropriate AccountID and ContactID to each record

Phew ... sizeable task, but doable. Monkey work.

Now I had a list of field names for the Salesforce.com database, and I could map those to the field names in our legacy CRM database. Importing the data didn't look like it was going to be all that difficult a task afterall. I hadn't imported a single record, but I had a data map of both systems and was confident that we'd be able to do this work in-house.

It's a GREAT feeling when you can go back to the boss and tell him, "Hey, guess what -- I'm gonna save you $50,000, and deliver the product EARLIER than expected."

So naive.