Loop in the right people.
Your CRM database is likely not used by just one person. You want to be sure that you have invited those that will be most impacted by the decisions and the results involved from migrating the data to be a part of the process. This doesn't mean that the CEO needs to be on every status call or validating test results. What it does mean is that if your CEO looks at your opportunity pipeline every week, that they are made aware of the timing of the CRM migration, when testing will happen which may impact the reports they view, and so on.
In the same vein, if you are not the database administrator, chances are you may not be as familiar with every dataset you are moving. For example, if you are sales, you can confidently review and approve the results of the import of your opportunities data. However, if you are also migrating marketing data, you should enlist the help of someone familiar with that dataset to validate the results. This will significantly increase the confidence and accuracy of the migration results.Determine the method of migration.
You're here because you are considering a third-party service, like Import2, for your Salesforce data migration
. That's a fantastic choice! But of course there are other options
, and you need to be aware of the advantages and disadvantages of those before you commit, as well as how they fit with the resources (time and expense) you can allocate to the project.
In a nutshell, you will decide if you want to:
- Migrate the data yourself, using CSV files. This is typically best for smaller and uncomplicated datasets, and assumes you are able to obtain the CSV file(s) from your old CRM database.
- Hire a Salesforce consultant. There are plentiful choices out there for Salesforce consulting services, who essentially work as a project manager for your CRM migration - albeit this can be a costly and slow-moving option.
- Use Import2 to automate the technical aspects of the migration for you. You work together to scope the requirements of your project, and offload much of the heavy-lifting of the migration - such as mapping fields, dealing with errors, and actually exporting and importing the data.Decide what data you wish to move.
This means carefully considering what data you want to keep, and what data (if any) you will exclude. A successful migration does not necessarily mean migrating every piece of data. In fact, a migration to a new database is the perfect time to take stock of your current data and assess what is truly useful for your team.
Practically speaking, it is typically more expensive (and more labor intensive to review and validate) to move more data. So, if you don't need large chunks of data for your business processes or reporting moving forward, decide now and leave it behind. Or, if your new database will have useful integrations to bring in things like emails, calendar events, etc. - you may not need to migrate that history from your old database because it will be synced using other apps.Prep your data.
You know the phrase - messy data in, messy data out. If you don't take care to clean-up your data as best as possible prior to the migration, you will still end up with a messy database at the end - just in a shiny new package. If you have years of bad data collecting in your old system, it may not be possible to get it perfect. However, you can still try to tackle any major items before you make the move, such as:
- Invalid email addresses
- Missing addresses or phone numbers
- Assigning records to an owner
- Closing out lost opportunities
- Purging untouched or lost leads
There are many approaches to cleaning up data, and you will have to decide what makes sense for your business and the current composition of your database. The end goal should be to achieve a set of data that you feel comfortable moving over and using in your new database. Prep your new Salesforce CRM database.
There are some basics you'll want to have setup before you begin any practical steps to migrating your data. You should ensure you have:
- Setup any fields
you need to accommodate your old data (i.e. custom fields, audit fields, etc.)
- Add users and ensure they have the permissions necessary to use the CRM database according to their roles.
- Turn off any validation rules, workflows or triggers in Salesforce that will impact your ability to import the data. There are many out-of-the-box rules Salesforce has enabled that can be triggered during a CRM data migration, causing errors during the import. The basic rule should be: if you don't need it now, disable it. You can always go back in and setup these items as you see fit after the migration is finished. Determine a cut-off date.
This may seem obvious, but it's a bit more nuanced than you may think.
The obvious cut-off date is when you have agreed as a team that you will no longer enter data into your old CRM. This ensures that when you begin your import that you are migrating the most up to date data, and you won't lose any updates or new records that your team may enter after the fact. A cut-off date will allow you a clean, accurate and timely transfer.
However, you may also have planned a period of time when you will still have access to your old CRM database, in case of any post-migration needs come up. This may be to perform checks on the migration results, or for referencing old reporting or analytics before you've set those up in your new CRM database. The most important thing to keep in mind is that, while the old database may still be available, once you start your migration, any new records or changes should be done in Salesforce! The old system should act as an archive, not as a live database.
Speaking of archives - when you've reached your cut-off date, make a backup of your database! Whether or not you will still have access to your old data once the migration is finished, it is highly recommended that you have created a backup of your entire dataset as a security measure in case anything should go sideways.
And finally, know your "unofficial" cut-off date. This is when you can say with confidence, that you are satisfied with the results of the migration and anything that may come up after this point, is not critical. This is when you can say goodbye to your old database, shake hands with your project manager, consultant or therapist (just kidding!) and consider the migration project complete.