Imagine a desk strewn with business cards. Now imagine that same desk’s contents attacked by a four–year-old with safety scissors. The four-year-old has carefully cut the company name off each of the cards. Now, you have twice as many pieces of cardstock lying around, and less than half the original value of information.
This is what it’s like to migrate data into Salesforce without maintaining the relationships between objects.
I’d like to tell you about my very first CRM data migration of online data into Salesforce. I had no tools beyond MS Office and no budget, save my own time and effort. But, beyond the torment of data cleanup (merging duplicates, fixing the bad default “Austria” country codes in phone numbers on records, etc.), there was one larger pain that, at the time, I had not fully anticipated. That was maintaining the relationships between all of the different objects – Accounts, Contacts, Opportunities, Notes, and Tasks, etc.
In Salesforce, like in most standard relational databases, each of these objects has a unique ID. If you pull up a Salesforce record, you can see this ID as part of the URL: https://blahblahblah.salesforce.com/006a000000yguWe. That part at the end of the URL with the alphanumeric gibberish – that is your object’s Salesforce ID.
The unique ID is created only when a new object is created in, migrated to or imported into Salesforce.
Thus, you see, to do a manual migration of the most basic data into Salesforce involves these steps:
- Import all of your Accounts (with a former CRM system’s unique account ID) into Salesforce.
- Export all of your Accounts (with a former CRM system’s unique account ID) from Salesforce, also including the newly created Salesforce unique Account ID.
- If your Contacts are in Excel or in a database, do a match on the Contact’s former system unique Account ID to find the Account’s new Salesforce unique ID. In Excel, one would do this using two worksheets and a VLOOKUP.
- Import all of your Contacts (with the former system’s unique contact ID, AND with the new Salesforce Account ID) into Salesforce.
- Export all of your Contacts (with the former system’s unique contact ID) from Salesforce, also including the newly created Salesforce unique Contact ID.
- If your Notes, Emails, Activities, etc. are in Excel or in a database, do a match on the object’s related IDs (old contact ID or old account ID or both). In Excel, one would do this using multiple worksheets and a VLOOKUP.
- Import all of your Notes, Emails, Activities, etc. into Salesforce using the appropriate Salesforce Contact or Account (or both!) IDs.
- If your Opportunities are in Excel or in a database, do a match on the Opportunity’s former system unique Account ID to find the Account’s new Salesforce unique ID. In Excel, one would do this using two worksheets and a VLOOKUP.
- If you have Contact Roles, Products and Pricebooks and Opportunity Line Item Schedules, it just keeps going from there!
Check out this lovely set of ERDs representing the Salesforce Data Model.
There are quite a lot of relationships, depending on what level of data you intend to migrate.
As you’ve gathered by this point, I never want to do a manual CRM data migration again. I don’t think anyone else should have to either. So when my current company, Cervello, was looking to create a converter for the Highrise CRM system to migrate its own data to Salesforce, I was first onboard.
In our application, the Highrise Converter, all of these steps are done for you with the click of one button – “Import Data”. Plus, you will see not only the import, but also the “mapping” status, which is the creation of these relationships between key objects.
Accounts, Contacts, Opportunities, Notes, Emails and Comments come into the system all glued together as they were meant to be. We solved our own problem of data migration from Highrise to Salesforce, and now we’re excited to share it with you. You can find it on the AppExchange here: Cervello Highrise Converter