Migrating to Salesforce CRM is one of the most consequential IT projects a mid-market or enterprise organisation undertakes — and one of the most frequently executed poorly. The most common outcome of a failed CRM migration is not a technical failure; it is a clean data problem: records that were incomplete in the legacy system are now incomplete in Salesforce, duplicates that existed before migration exist again in Salesforce, and the new platform inherits all the data discipline problems of the old one rather than providing the clean start the migration was meant to achieve. This guide covers the migration process from the pre-migration data audit through to go-live, with the specific steps that determine whether the migration succeeds.
The best migration guide is the one that helps the team move without losing control.
A practical explanation should make the transfer feel organised rather than risky.
That means the guide should help readers think about what needs to move, what needs to change, and what can wait.
For many businesses, migration succeeds only when the data structure and the new workflow are planned together.
It also needs to keep the team from creating avoidable cleanup work after the move.
A good migration plan has to balance data accuracy, process changes, and user adoption at the same time.
That makes the process more than a technical copy job.
How to migrate to Salesforce CRM is a practical topic because migration can help a business move customer data, sales history, and processes into a stronger system without losing the work already done elsewhere.
Step 1: Audit Your Existing Data Before Moving Anything
The most important work in a CRM migration happens before a single record is moved. Migrating dirty data into Salesforce merely transfers the problem to a new system — it does not solve it. A pre-migration data audit should cover:
- Completeness: What percentage of contacts have email addresses? What percentage of accounts have industry, company size, and annual revenue populated? Identify the fields that are critical for Salesforce’s automated workflows and ensure they are populated before migration
- Accuracy: Are job titles consistent (VP Sales vs Vice President, Sales vs VP of Sales are three records for the same role)? Are company names consistent across records for the same account? Standardise picklist values before migration
- Duplication: Run a deduplication analysis on the existing dataset. Most CRM databases accumulated over 5+ years contain 15–25% duplicate records — contacts that exist multiple times with different email addresses, capitalisation variations, or data from different import events
- Relevance: Not all data in the legacy CRM needs to migrate. Leads that are 3+ years old with no activity, closed deals from prior to the current sales team’s tenure, and contacts who have unsubscribed may be better archived than migrated. A smaller, cleaner dataset is a better starting point than the full legacy database
Tools for the audit: Excel or Google Sheets for analysis on smaller datasets; dedicated data quality tools (Validity DemandTools, Cloudingo, or DataGroomr) for larger datasets of 10,000+ records.
Step 2: Map Your Data to Salesforce’s Object Model
Salesforce’s data model differs from most legacy CRM systems. Understanding the mapping before migration prevents data loss and post-migration confusion:
- Companies→ SalesforceAccounts: The company-level record. Account hierarchy (parent/child account relationships) should be preserved during migration if it exists in the legacy system
- Individuals→ SalesforceContacts(if associated with a company) orLeads(if unqualified prospects that have not yet been verified as genuine opportunities)
- Deals/Opportunities→ SalesforceOpportunities: Map legacy deal stages to the Salesforce pipeline stages configured for the deployment
- Activities/History→ SalesforceTasksandEvents: Completed activities log as Tasks (Closed = True); meetings log as Events; note that Activity history migration is often deprioritised because the legacy data is historical reference only
- Custom fields: Any custom data in the legacy CRM (industry codes, contract terms, custom attributes) must map to either a standard Salesforce field or a custom field that must be created before migration
Create a formalData Mapping Document— a spreadsheet that lists every legacy field, the Salesforce field it maps to (or “Do Not Migrate” / “New Custom Field Required”), and any transformation rules (e.g., “Legacy Status = Active → Salesforce Lead Status = Working”).
Step 3: Configure Salesforce Before Migrating Data
Salesforce must be configured before data is imported — not after. Importing data into an unconfigured Salesforce org and then reconfiguring it means all imported records may need updating to reflect the configuration changes. Complete before importing:
- Pipeline stages (with correct probability values)
- All custom fields required by the data mapping
- Picklist values (Lead Source, Industry, Account Type, Stage) that match the transformed values in the import file
- User accounts for every person who will be assigned records in the migration
- Required field validation rules (temporarily disable these during migration — re-enable after the clean data import is complete)
Step 4: Prepare and Clean the Import Files
Salesforce imports data from CSV files. Prepare separate CSV files for each object in the recommended import order:
- Accounts(import first — Contacts and Opportunities reference Account IDs)
- Contacts(import second — reference the Account IDs generated in step 1)
- Leads(can be imported alongside Contacts for prospects not yet associated with Accounts)
- Opportunities(import after Accounts and Contacts — reference Account IDs and optional Contact IDs)
- Activities(import last — reference Opportunity, Contact, or Account IDs)
Each CSV row should include only the data for one record, with one column per field. The first row is the header row with exact Salesforce field API names or display labels (the Import Wizard maps headers to fields). Clean the CSVs before import: remove leading/trailing spaces, standardise date formats (MM/DD/YYYY for US locale), remove special characters that cause import errors, and validate that all referenced IDs (Account IDs on Contact rows) actually exist in the previously imported dataset.
Step 5: Import Using Data Import Wizard or Data Loader
Salesforce provides two native import tools:
Data Import Wizard(Setup → Data → Data Import Wizard): Salesforce’s browser-based import tool — user-friendly, supports deduplication matching on import, suitable for files under 50,000 records. The Import Wizard allows you to map CSV columns to Salesforce fields via a drag-and-drop interface and configure duplicate detection rules (match on Name + Email, match on Account Name + Billing Zip, etc.).
Data Loader(downloadable client application): Salesforce’s command-line and GUI tool for large-volume imports — supports files of up to 5 million records, batch processing, and bulk API usage for high-speed imports. Data Loader is required for imports exceeding 50,000 records and for any migration that needs to be scripted and rerun (it supports command-line execution and scheduling).
For enterprise migrations with 100,000+ records, theSalesforce Bulk API 2.0via Data Loader or a migration tool (Informatica Cloud, MuleSoft, or specialist CRM migration platforms) provides the most reliable large-scale import performance.
Step 6: Validate the Import
After every import batch, run validation checks before proceeding to the next object:
- Record count: Does the imported record count match the source file row count (minus any duplicate-skipped records)?
- Spot check: Manually verify 20–30 records across the dataset — compare the Salesforce record with the source file row to confirm all fields mapped correctly
- Relationship integrity: Verify that Contacts are correctly related to their Accounts, and Opportunities are correctly related to both Accounts and Contacts
- Run the Data Quality Report (pipeline data quality, duplicate check) immediately after import to identify any systematic issues
Keep the Data Loader import log files — they record every record that imported successfully and every record that failed with the error reason. Failed records are common (picklist value mismatch, required field blank, invalid date format) and should be corrected and re-imported in a remediation batch.
Step 7: User Training and Go-Live
Migrate during a low-activity period — weekend or month-end — to minimise the window during which the legacy system is live but Salesforce is being prepared. Sequence:
- Complete the final data export from the legacy CRM (this is the last authoritative snapshot)
- Import to Salesforce and complete validation checks
- Run a 60–90 minute training session for all users covering the core Salesforce workflow: finding their records, logging activities, updating pipeline stages, and creating new leads
- Set the legacy CRM to read-only (prevent new data entry) immediately after training
- Salesforce is now the system of record — all new data entry happens in Salesforce
Conclusion
A successful Salesforce CRM migration is 70% data preparation work and 30% technical execution. Organisations that invest in the pre-migration audit, data cleaning, and field mapping before touching Salesforce arrive at go-live with clean data, a configured platform, and a team that knows how to use it. Those that rush the migration to meet an arbitrary go-live deadline inherit all their legacy CRM’s data quality problems in a new system — and spend the next 12–18 months cleaning up the mess while trying to manage their pipeline on it. The extra two to four weeks of data preparation that the careful migration approach requires is the best investment a migrating organisation can make.
The best migration plan is the one that protects data quality during the move. If the planning is thin, cleanup often comes after launch.
Common Problems and Fixes
Common Migration Mistakes to Avoid
- Migrating before configuration is complete: Importing data before pipeline stages, custom fields, and picklist values are finalised creates a re-import requirement
- Migrating all historical data: 5+ year old closed deals and leads with no activity are noise in the new system. Set a migration cutoff (e.g., only records with activity in the last 3 years)
- No deduplication before import: Duplicates in the legacy system become duplicates in Salesforce. Running deduplication before migration is always faster than cleaning duplicates after
- No parallel running period: Some organisations shut down the legacy CRM on migration day and immediately depend on Salesforce. A 2-week parallel period — both systems running simultaneously — allows reps to catch errors and build confidence before the legacy system is decommissioned
- Underestimating the data transformation work: Transforming legacy data to match Salesforce’s picklist values, date formats, and field structures is typically 50–60% of the migration project’s effort. Allocate accordingly
Problem: Data Mapping Errors Cause Corrupted Records After Salesforce Migration
Data mapping — translating field values from the source system’s format to Salesforce’s expected format — is the most error-prone part of CRM migration. Common mapping failures include picklist values that don’t match Salesforce’s configured options (causing import errors), date formats that differ between systems, and phone numbers with inconsistent formatting that fail Salesforce’s validation rules. To prevent mapping errors: (1) Export a sample of 100-200 records from your source system and manually map each field to its Salesforce equivalent before building your full import file. (2) Create a data dictionary that documents every source field, its data type, any transformation needed, and the target Salesforce field — review this with a Salesforce admin before importing. (3) Import a test batch of 50-100 records first, verify all mapped fields in Salesforce look correct, then proceed with the full migration.
Problem: Salesforce Migration Fails Partway Through and Leaves a Half-Migrated Org
Large data migrations involving thousands of records frequently encounter errors mid-import — a field validation failure, a duplicate detection trigger, or an API timeout — that stops the import partway through. If you’ve already imported 5,000 of 10,000 accounts, partial data can cause confusion and data quality issues. To manage this risk: (1) Always test your full import in a Salesforce Sandbox first and let it complete without errors before importing to production. (2) Import data in sequential chunks of 1,000-5,000 records rather than one massive batch — smaller chunks are easier to troubleshoot and re-run when errors occur. (3) Use Salesforce Data Loader’s “success file” output feature, which creates a CSV of successfully imported records with their new Salesforce IDs — this lets you track exactly which records imported and which failed, enabling targeted re-import of only failed records.
Problem: Historical Activity Data From the Old CRM Is Lost After Migration
Most CRM migrations focus on importing current records (contacts, accounts, deals) but fail to import historical activity data — past emails, call logs, meeting notes, and interaction histories. This loss is significant: account teams lose visibility into previous customer interactions, and support teams can’t see how a customer was originally engaged. To preserve historical activities: (1) Export historical activities from your source system as a structured CSV with associated record IDs, activity type, date, and notes. (2) Import historical activities as Salesforce Task records linked to the appropriate Contact or Account records using the external record IDs as the relationship key. (3) If the volume of historical activities makes full import impractical, prioritize importing activities for your top 20% of accounts by revenue, and archive the remaining history in a shared document or data warehouse accessible to your team outside Salesforce.
Frequently Asked Questions
What is the best tool for migrating data into Salesforce?
The best migration tool depends on your data volume and technical complexity. The Salesforce Data Import Wizard (accessible from Setup or the app launcher) handles imports of up to 50,000 records for standard objects (Contacts, Leads, Accounts, Opportunities) with a user-friendly CSV upload interface — no technical setup required. Salesforce Data Loader is a free desktop application supporting up to 5 million records per import, with bulk API processing for high-volume migrations — it requires more technical knowledge but handles complex migrations reliably. For enterprise migrations involving millions of records, complex data transformations, or cross-system integrations, commercial ETL tools like Informatica Cloud, Talend, or MuleSoft offer advanced transformation capabilities and error handling beyond what the native tools provide.
How long does a Salesforce CRM migration typically take?
Timeline varies significantly by data volume and complexity. A simple migration of 10,000-50,000 records (contacts, accounts, opportunities) from a single source system with clean data typically takes 2-4 weeks including data prep, sandbox testing, and production import. A complex migration involving multiple source systems, historical activity data, custom object mapping, and validation with business stakeholders typically takes 6-12 weeks. Enterprise migrations involving hundreds of thousands of records, parallel system operation during cutover, and staff retraining programs have taken 3-6 months in organizations with complex data governance requirements. The data preparation phase (cleaning, deduplication, mapping) almost always takes longer than the actual technical import — budget at least 50% of your total migration timeline for pre-import data work.
Should you clean data before or after migrating to Salesforce?
Always clean data before migration, not after. Importing dirty data into Salesforce creates a much harder deduplication and cleanup problem than cleaning the source system first. Pre-migration data cleaning should include: removing duplicate records (use your source CRM’s deduplication tools or Excel), standardizing field formats (consistent phone number formatting, state abbreviations vs. Full state names), filling in required fields for records that will fail Salesforce import validation, and removing or archiving records that are more than 5 years old with no recent activity. Post-migration cleanup is 3-5x more time-consuming than pre-migration cleanup because you must work within Salesforce’s interface and data governance rules rather than the more flexible source system environment.
What should you do with your old CRM after migrating to Salesforce?
Keep your old CRM in a read-only state for at least 90 days after going live on Salesforce. This provides a fallback reference if users report missing data and allows your team to cross-reference historical records during the transition period. After 90 days, if no major data gaps have been identified: export a final full data backup from the old CRM to CSV files and store them in a secure archive location (shared drive, cloud storage) for regulatory or audit requirements. Then cancel the old CRM subscription to eliminate double-running costs. Do not delete the old CRM data immediately — retain the archived CSV exports for at least 3 years to comply with most B2B data retention policies and potential legal discovery requirements.