The only Salesforce migration roadmap you will ever need.
Salesforce Migration Best Practices
Before you begin any steps to Salesforce migration, you'll have some setup to do in your new Salesforce. Some steps you may have already done, but here's a Salesforce Migration Best Practices to ensure you've covered all the major components that will directly impact your Salesforce migration.
Salesforce user setup
One of the first things you should do is to setup all of the individuals who need access to your Salesforce CRM. Salesforce has extensive options for setting up users, so you may wish to learn more in detail here. On a high level, you'll want to ensure everyone has a user account created, and that they are assigned the appropriate role and permissions to use the database efficiently.
One of the first things you should do is to setup all of the individuals who need access to your Salesforce CRM. Salesforce has extensive options for setting up users, so you may wish to learn more in detail here. On a high level, you'll want to ensure everyone has a user account created, and that they are assigned the appropriate role and permissions to use the database efficiently.
Adding users in Salesforce
Adding custom fields in Salesforce
A very important part of Salesforce Migration Best Practices is to setup all the necessary fields to be able to import all your pertinent business data. Your old CRM database may have standard fields which Salesforce does not, or you may have created custom fields there to house data specific to your business - both scenarios would require you to create custom fields in Salesforce in order to retain that data.
A very important part of Salesforce Migration Best Practices is to setup all the necessary fields to be able to import all your pertinent business data. Your old CRM database may have standard fields which Salesforce does not, or you may have created custom fields there to house data specific to your business - both scenarios would require you to create custom fields in Salesforce in order to retain that data.
Adding custom fields in Salesforce
When you create custom fields, it's important to:
- Create them on the correct object (or module). For example, if you have custom fields on your companies/organizations in your old CRM, you'll need to create those fields on Accounts in Salesforce. For more info on Salesforce objects, read here.
- Create the field with the right "type". For example, if your field is formatted as a decimal number in your old CRM database, setup that field as a decimal field in Salesforce.
For a more detailed look, Salesforce has a great guide to custom field setup here.
- Create them on the correct object (or module). For example, if you have custom fields on your companies/organizations in your old CRM, you'll need to create those fields on Accounts in Salesforce. For more info on Salesforce objects, read here.
- Create the field with the right "type". For example, if your field is formatted as a decimal number in your old CRM database, setup that field as a decimal field in Salesforce.
For a more detailed look, Salesforce has a great guide to custom field setup here.
Customizing page layouts in Salesforce
Salesforce allows you to create page layouts that meet your needs. So, if you want to replicate how your data was laid out in your old CRM database, or create a new and improved view of your records, you can use the Salesforce page editor to decide how you want to view your data. This is the place where you can decide to add any custom fields you've created to your layout, remove unnecessary fields, or rearrange the order of the fields to make your day-to-day work more efficient. You can read more about using the page layout editor here.
Salesforce allows you to create page layouts that meet your needs. So, if you want to replicate how your data was laid out in your old CRM database, or create a new and improved view of your records, you can use the Salesforce page editor to decide how you want to view your data. This is the place where you can decide to add any custom fields you've created to your layout, remove unnecessary fields, or rearrange the order of the fields to make your day-to-day work more efficient. You can read more about using the page layout editor here.
Setting up page layout in Salesforce
Beware restricted and required Salesforce fields
Salesforce has some built-in data quality rules that may apply to your data fields, which you should pay close attention to as you prep for your CRM data migration.
- Picklists: These are a very common source of error during a crm data migration. When you have picklist fields, your incoming data from the import must be an exact match to an option from the picklist, or you will receive an error. There are standard field picklists (see state and country for example), and you may also have created custom field picklists to house your data. Picklists can be restricted, meaning that you must select from an option in the picklist provided; or they can be unrestricted, meaning that you can add additional options as you go.
- Required fields: You may have noticed if you setup custom fields that Salesforce provides the option to make the field mandatory or not. Salesforce has this requirement on some standard fields as well, for example "Account Name". You can view what fields are mandatory when viewing your page layout, denoted by a red asterisk. It's important to note which fields you, or Salesforce, have made required so that you can prep your incoming data if necessary (or make adjustments to the requirements in Salesforce in order to avoid any unnecessary errors during the data migration).
Enable audit fields in Salesforce
If you'd like to retain your records' created and modified timestamps, as well as which user created or modified the record, you'll want to enable audit fields in your Salesforce CRM. Otherwise, when you migrate your data, you will end up seeing that every record was created/modified on the date of the migration, and by the user who performed it.
The steps can be kind of tricky for beginners, as you need to both enable audit fields at an organization level (meaning on a high level, your Salesforce is configured to accept incoming audit field data) and at the individual permissions level, so that the user performing the migration has permission to send data to those fields. See video below on how to enable those.
You can also read here for how to enable audit fields at the organization level, and here for how to setup the profile permissions.
Salesforce has some built-in data quality rules that may apply to your data fields, which you should pay close attention to as you prep for your CRM data migration.
- Picklists: These are a very common source of error during a crm data migration. When you have picklist fields, your incoming data from the import must be an exact match to an option from the picklist, or you will receive an error. There are standard field picklists (see state and country for example), and you may also have created custom field picklists to house your data. Picklists can be restricted, meaning that you must select from an option in the picklist provided; or they can be unrestricted, meaning that you can add additional options as you go.
- Required fields: You may have noticed if you setup custom fields that Salesforce provides the option to make the field mandatory or not. Salesforce has this requirement on some standard fields as well, for example "Account Name". You can view what fields are mandatory when viewing your page layout, denoted by a red asterisk. It's important to note which fields you, or Salesforce, have made required so that you can prep your incoming data if necessary (or make adjustments to the requirements in Salesforce in order to avoid any unnecessary errors during the data migration).
Enable audit fields in Salesforce
If you'd like to retain your records' created and modified timestamps, as well as which user created or modified the record, you'll want to enable audit fields in your Salesforce CRM. Otherwise, when you migrate your data, you will end up seeing that every record was created/modified on the date of the migration, and by the user who performed it.
The steps can be kind of tricky for beginners, as you need to both enable audit fields at an organization level (meaning on a high level, your Salesforce is configured to accept incoming audit field data) and at the individual permissions level, so that the user performing the migration has permission to send data to those fields. See video below on how to enable those.
You can also read here for how to enable audit fields at the organization level, and here for how to setup the profile permissions.
How to enable audit fields in Salesforce
While there are countless other ways to setup and customize Salesforce CRM for your business needs, the items above are the most common to focus on to prepare for a smooth CRM data migration. Feel free to dive in to Salesforce's online documentation to learn more about how you can customize your database, but don't get lost in the weeds too early, or you may find yourself in perpetual setup-mode! Do what you need to prep for the migration, and the rest you can tackle post-migration as needed.
Once you have your Salesforce set-up, you need to make sure you understand where in Salesforce your data is imported to. Please check the next section "Know Your Salesforce Objects" to understand Salesforce objects.
Once you have your Salesforce set-up, you need to make sure you understand where in Salesforce your data is imported to. Please check the next section "Know Your Salesforce Objects" to understand Salesforce objects.
Know Your Salesforce Objects
You may be ready to see how your data looks in Salesforce, but first you should check that you know where it will be imported to in your new database. Not all CRMs structure their data in the same way, so let's take a quick look at the main modules in Salesforce so you can understand how they are used and what your current data will correspond to. For those who want to dive deep into the details of the Salesforce data model, you can check out their documentation here.
Accounts
The Accounts module is where you will track the company-level data for the clients that you work with. If you do not work with companies, but with individuals (for example, with contractors), you can use a "Person Account" instead of a standard company account. With either type, you can consider this module as the top-tier level in your data's hierarchy. Everything else funnels down from the account level - contacts, opportunities, etc. are all tied back to up an account. Your existing database may use different terminology - Salesforce Accounts are equivalent to "Organizations" or "Companies" in other CRM systems.
Contacts
This module is where you will track the individual points of contact at the clients you work with. These are typically contacts for existing business opportunities you manage, or potential, well-qualified opportunities that you are cultivating. Most CRMs have a contacts module, but others may call it "people" or "individuals".
Opportunities
The opportunities module is where you will track your company's sales. This includes your sales funnel, from the point a lead becomes qualified as a potential opportunity, through the sales stages, until it is closed (whether it is won or lost). Your opportunities (or, deals, in some CRMs) will be linked back to the contacts and/or accounts that they are associated with.
Leads
The leads module in Salesforce is intended for your tracking contacts who you have identified as a prospective client, so you can track your progress and eventually convert them to actual accounts/opportunities in your database (see more about converting leads here). Some businesses may not use the leads module, and others may be coming from a CRM database which does not have a separate module for lead tracking.
If your data is not currently segmented into leads vs. contacts, then you'll need to decide whether you want to make this a step in your migration - or, if you will implement post-migration as part of your new Salesforce business processes. If you want to incorporate this into your data migration, it is crucial to determine how to identify a contact vs. lead in your current CRM database. For example, do you have a "status" or "lifecycle stage" field which classifies a contact as a prospect vs. a business contact.
Additional Modules
There are many other modules in Salesforce which you may need to utilize. You will see Salesforce allows you to track campaigns, cases, pricebooks, products, and many more. You may wish to refer to Salesforce documentation to determine if your company may wish to use these as part of your new Salesforce implementation.
Custom Objects
If you have additional data to track, which does not fit well within Salesforce's standard objects, you may wish to use custom objects. These are typically extensions of your standard objects, but where you store data which is specific to your company or industry and needs to be tracked separately. Typically you still link back to your standard objects to maintain a relational database - for example, a company using Salesforce for human resources may use a custom object for payroll data, which is linked back to the individual contact record.
Your specific Salesforce implementation will be up to your database admin and your company's specific needs and processes. For the purpose of the migration however, make sure you are familiar with the above, so you can accurately scope out your migration needs and understand how the data will be structured in your new Salesforce database.
Now that you have understanding of Salesforce objects, it's time to choose your data migration tool. Please read section below to see your options.
Accounts
The Accounts module is where you will track the company-level data for the clients that you work with. If you do not work with companies, but with individuals (for example, with contractors), you can use a "Person Account" instead of a standard company account. With either type, you can consider this module as the top-tier level in your data's hierarchy. Everything else funnels down from the account level - contacts, opportunities, etc. are all tied back to up an account. Your existing database may use different terminology - Salesforce Accounts are equivalent to "Organizations" or "Companies" in other CRM systems.
Contacts
This module is where you will track the individual points of contact at the clients you work with. These are typically contacts for existing business opportunities you manage, or potential, well-qualified opportunities that you are cultivating. Most CRMs have a contacts module, but others may call it "people" or "individuals".
Opportunities
The opportunities module is where you will track your company's sales. This includes your sales funnel, from the point a lead becomes qualified as a potential opportunity, through the sales stages, until it is closed (whether it is won or lost). Your opportunities (or, deals, in some CRMs) will be linked back to the contacts and/or accounts that they are associated with.
Leads
The leads module in Salesforce is intended for your tracking contacts who you have identified as a prospective client, so you can track your progress and eventually convert them to actual accounts/opportunities in your database (see more about converting leads here). Some businesses may not use the leads module, and others may be coming from a CRM database which does not have a separate module for lead tracking.
If your data is not currently segmented into leads vs. contacts, then you'll need to decide whether you want to make this a step in your migration - or, if you will implement post-migration as part of your new Salesforce business processes. If you want to incorporate this into your data migration, it is crucial to determine how to identify a contact vs. lead in your current CRM database. For example, do you have a "status" or "lifecycle stage" field which classifies a contact as a prospect vs. a business contact.
Additional Modules
There are many other modules in Salesforce which you may need to utilize. You will see Salesforce allows you to track campaigns, cases, pricebooks, products, and many more. You may wish to refer to Salesforce documentation to determine if your company may wish to use these as part of your new Salesforce implementation.
Custom Objects
If you have additional data to track, which does not fit well within Salesforce's standard objects, you may wish to use custom objects. These are typically extensions of your standard objects, but where you store data which is specific to your company or industry and needs to be tracked separately. Typically you still link back to your standard objects to maintain a relational database - for example, a company using Salesforce for human resources may use a custom object for payroll data, which is linked back to the individual contact record.
Your specific Salesforce implementation will be up to your database admin and your company's specific needs and processes. For the purpose of the migration however, make sure you are familiar with the above, so you can accurately scope out your migration needs and understand how the data will be structured in your new Salesforce database.
Now that you have understanding of Salesforce objects, it's time to choose your data migration tool. Please read section below to see your options.
How to choose salesforce data migration tool
You've decided you're moving to Salesforce, and now it's time to decide how. You may have received recommendations from a trusted colleague, or read a convincing how-to guide. Before you commit to an option, take a moment to review the most common salesforce data migration tools to ensure you select the best fit for your specific needs and resources you have available.
Option 1: Salesforce Import Wizard
A very simple option, using the Wizard built into your Salesforce environment. To open it go to Your Name | Setup | Data Management. It works with any Salesforce edition and is free of cost.
When to use:
Option 2: Dataloader.io or Import2
You can choose a standalone service that allows you to import data from CSV, with more capabilities than Salesforce's built-in Wizard. Using these professionally built tools allow you to do more sophisticated migration tasks on your own.
When to use:
Option 3: Salesforce API
Sometimes, especially when you need to automate certain steps of data preparation or cleansing, the best option is to use Salesforce API directly. Thorough documentation is very helpful and there are various client libraries like Databasedotcom written in different languages.
When to use:
Option 4: 1-Click Salesforce Data Migration by Import2
In many cases, you do not have the time, know-how or resources required to do the data import yourself. This is why third-party services exist! Import2 for Salesforce uses a combination of Salesforce API and trained migration experts to automate and simplify almost every step of CRM data import. The result is both time- and cost-efficient.
When to use Import2:
Remember when you choose, you are not "stuck" in that decision. If you try to do an import yourself, but realize it's too complex or exhaustive to complete, you can turn to a new option. If you choose a consultant who is not a good fit for you, check out other salesforce migration tools! It is crucial to the success of your data migration that you are confident in the results. This means that by the time it is ready to begin, you've tested and approved the method you select.
Now you have your salesforce migration tool selected, salesforce set-up and you have understanding of Salesforce objects. Make sure to go through Salesforce migration checklist below. Data migration checklist will save you a ton time after you start your migration.
Option 1: Salesforce Import Wizard
A very simple option, using the Wizard built into your Salesforce environment. To open it go to Your Name | Setup | Data Management. It works with any Salesforce edition and is free of cost.
When to use:
- You have your current CRM data in CSV format and need to import only basic records like Accounts, Contacts or Leads
- You do not have more than 50,000 records to import (this is a limit built into the Wizard app)
- API is not enabled in your Salesforce Edition (Group, Professional) so other options are not available for you.
- You don't have any migration budget, but you have a few days of free time.
Option 2: Dataloader.io or Import2
You can choose a standalone service that allows you to import data from CSV, with more capabilities than Salesforce's built-in Wizard. Using these professionally built tools allow you to do more sophisticated migration tasks on your own.
When to use:
- You need to import various CRM objects not supported by Import Wizard.
- You are familiar with Salesforce Data Model or techy enough to learn it quickly.
- You are using Professional or Enterprise Edition and have API access enabled.
Option 3: Salesforce API
Sometimes, especially when you need to automate certain steps of data preparation or cleansing, the best option is to use Salesforce API directly. Thorough documentation is very helpful and there are various client libraries like Databasedotcom written in different languages.
When to use:
- If other tools didn't work out as expected.
- You have experience working with API
- You need to automate certain steps of data import.
- You are using Professional or Enterprise Edition and have API access enabled.
Option 4: 1-Click Salesforce Data Migration by Import2
In many cases, you do not have the time, know-how or resources required to do the data import yourself. This is why third-party services exist! Import2 for Salesforce uses a combination of Salesforce API and trained migration experts to automate and simplify almost every step of CRM data import. The result is both time- and cost-efficient.
When to use Import2:
- If other tools don't accomplish what you are looking for.
- You do not have the know-how or time for an API migration
- You have a tight timeline to complete the migration
- You have a large database that exceeds the limits of other tools.
Remember when you choose, you are not "stuck" in that decision. If you try to do an import yourself, but realize it's too complex or exhaustive to complete, you can turn to a new option. If you choose a consultant who is not a good fit for you, check out other salesforce migration tools! It is crucial to the success of your data migration that you are confident in the results. This means that by the time it is ready to begin, you've tested and approved the method you select.
Now you have your salesforce migration tool selected, salesforce set-up and you have understanding of Salesforce objects. Make sure to go through Salesforce migration checklist below. Data migration checklist will save you a ton time after you start your migration.
Salesforce Data Migration Checklist
You're committed to moving your data to Salesforce, and perhaps you've even dedicated a project manager to the migration task. The immediate next step is to create a plan - a kind of roadmap for your salesforce data migration, from start to finish. Proper planning of your data migration will ensure that the process runs smoothly and that you make the most efficient use of your time and resources.
Before you dive into any of the details of mapping data, setting up your reporting, integrations or any other functions of your new crm database, it's important to get a handle on the 30,000 foot view of what your migration project entails. These key components will be absolutely necessary to those involved in executing the migration, and it's best to have the answers well thought through and documented before you begin.
Before you dive into any of the details of mapping data, setting up your reporting, integrations or any other functions of your new crm database, it's important to get a handle on the 30,000 foot view of what your migration project entails. These key components will be absolutely necessary to those involved in executing the migration, and it's best to have the answers well thought through and documented before you begin.
Salesforce Migration Checklist
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.
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.