Salesforce Data Migration Checklist: How to Move From a Legacy CRM Without Losing Data

A successful Salesforce data migration follows eight steps: audit your legacy data, define scope, cleanse and deduplicate, map fields, load in dependency order with external IDs, validate with reconciliation reports, rehearse in a full sandbox, and cut over with a rollback plan. Skipping any one of these steps is the most common reason records go missing, relationships break, or users lose trust in the new system. Most mid-market migrations need at least two full mock loads before production, and the highest-risk phase is almost always data cleansing, not the load itself.

For Houston companies in energy, healthcare, logistics, and professional services, a structured Salesforce data migration protects revenue history, customer relationships, and compliance records. This checklist reflects how a seasoned digital transformation partner delivers: phased delivery roadmaps, a zero-downtime commitment, and discipline in enterprise system integration. If you are evaluating Salesforce consulting in Houston, use it to test any proposal you receive.

Quick Answer: The Salesforce Data Migration Checklist at a Glance

• Step 1: Audit. Inventory every legacy source, object, record count, and owner.
• Step 2: Scope. Decide what to migrate, archive, or retire.
• Step 3: Cleanse. Deduplicate, standardize, and fix invalid values.
• Step 4: Map. Match every legacy field to a Salesforce field with transformation rules.
• Step 5: Prepare Salesforce. Create external IDs, users, record types, and picklist values.
• Step 6: Load in order. Parents first, children second, using upsert.
• Step 7: Validate. Reconcile counts, totals, and relationships, then run user acceptance testing.
• Step 8: Cut over. Freeze, run a delta load, go live, and monitor.

What Is Salesforce Data Migration?

Salesforce data migration is the process of extracting records from a legacy CRM or other source, transforming them to fit the Salesforce data model, and loading them accurately into Salesforce. It includes accounts, contacts, leads, opportunities, activities, notes, attachments, and custom objects.

A complete migration also covers:

• Relationships: parent-child links between records
• Ownership: assigning each record to the correct Salesforce user
• History: preserving dates, stages, and activity timelines where required
• Files: moving attachments and documents into Salesforce Files

Why Do Legacy CRM Migrations Lose Data?

Migrations lose data when scope is vague, source data is dirty, field mapping is incomplete, or no one reconciles the results. These are process failures, not tool failures.

The most common causes are:

• Truncated fields: legacy text fields longer than the Salesforce field length
• Broken relationships: child records loaded before their parents exist
• Invalid picklist values: values rejected because they were never created in Salesforce
• Owner mismatches: records assigned to inactive or missing users
• Silent load errors: failed rows never reviewed or reloaded
• Validation rule conflicts: rules that reject legacy records with missing or old-format data

Step 1: How Do You Audit Your Legacy CRM Data?

Start by inventorying every object, field, record count, and data owner in the legacy system. You cannot protect data you have not measured.

Capture the following:

• Object list: accounts, contacts, leads, deals, cases, activities, custom tables
• Record counts: total, active, and inactive records per object
• Data quality indicators: percentage of blank, duplicate, and invalid values
• Integrations: systems that read from or write to the legacy CRM
• Attachments: file volume, file types, and total storage size
• Business owners: the person accountable for each data domain

Information gain: profile your data before you design anything. A simple count of blank required fields and duplicate emails often reveals that 10–30% of records need cleansing or retirement before migration begins. Treat that figure as a planning prompt, not a guarantee.

Step 2: How Do You Decide What Data to Migrate?

Migrate only data that supports current business processes, compliance obligations, or reporting needs. Everything else should be archived outside Salesforce.

Use a simple decision filter for each object:

• Migrate: active customers, open pipeline, recent activity, required history
• Archive: closed records older than your retention window, kept in a data warehouse or file store
• Retire: test data, duplicates, and orphaned records

Smaller scope means faster loads, lower storage cost, and a cleaner user experience. Confirm retention requirements with legal and compliance teams before you delete anything.

Step 3: How Do You Cleanse and Deduplicate CRM Data?

Cleanse data in the source or in a staging area before loading, never after. Fixing problems after go-live is slower, riskier, and harder to audit.

What Should a Data Cleansing Pass Include?

• Deduplication: match on email, phone, company name plus address, or a legacy unique ID
• Standardization: consistent formats for phone numbers, states, countries, and dates
• Value normalization: collapse variations such as "TX," "Tex.," and "Texas" into one picklist value
• Required field completion: supply defaults for fields Salesforce requires
• Relationship repair: link orphaned contacts to the correct accounts
• Inactive record handling: flag or remove records that should not migrate

How Do You Handle Duplicates Safely?

• Define merge rules before merging, including which record survives and which field values win.
• Preserve the legacy ID of every merged record so history stays traceable.
• Review high-value accounts manually instead of relying on automated matching alone.

Step 4: How Do You Map Legacy Fields to Salesforce?

Build a field mapping document that lists every source field, its Salesforce target, its data type, and any transformation rule. This document becomes your contract between business and technical teams.

Each mapping row should include:

• Source object and field name
• Target Salesforce object and field API name
• Data type and length on both sides
• Transformation logic, such as concatenation, splitting, or lookup translation
• Default value for blanks
• Owner approval from the business data steward

What Data Type Issues Cause the Most Problems?

• Dates and time zones: confirm formats and whether times are stored in UTC or local time.
• Currency and decimals: confirm precision and multi-currency settings.
• Multi-select picklists: Salesforce uses semicolon-separated values.
• Long text: check maximum lengths to avoid truncation.
• Boolean values: convert "Y/N" and "1/0" to true and false consistently.

Step 5: How Do You Prepare Salesforce Before Loading Data?

Prepare the target org so every incoming record has a valid place to land. Loading into an unprepared org causes avoidable errors.

Complete these preparation tasks:

• Create external ID fields on each object to store the legacy record ID.
• Create all picklist values, record types, and custom fields the mapping requires.
• Create or reactivate users who will own migrated records.
• Review validation rules, flows, and triggers and plan how to bypass or adjust them during load.
• Enable audit field permissions if you need to preserve original created dates and created-by values.
• Confirm storage capacity for data and files.

Information gain: external IDs are the single most valuable preparation step. They let you use upsert, rebuild relationships by legacy ID, and safely re-run loads without creating duplicates.

Step 6: In What Order Should You Load Salesforce Data?

Load parent records before child records so relationships resolve correctly. A typical order for a sales and service org looks like this:

1. Users and roles
2. Accounts
3. Contacts
4. Leads and campaigns
5. Opportunities and opportunity contact roles
6. Products, price books, and quotes
7. Cases and custom objects
8. Tasks, events, and notes
9. Attachments and files

Which Tools Should You Use to Load Data?

• Data Import Wizard: suitable for small, simple loads of standard objects.
• Data Loader: suitable for larger loads and upsert operations using external IDs.
• Bulk API: suitable for very large volumes and automated pipelines.
• ETL and integration platforms: suitable for repeatable, transformation-heavy migrations.

Tool limits and supported objects change over time, so confirm current record limits and capabilities in Salesforce documentation before choosing your approach.

What Load Best Practices Reduce Risk?

• Use upsert with external IDs so reloads update records instead of duplicating them.
• Load in controlled batches and review error files after every batch.
• Disable non-essential automation during load, then re-enable and test it.
• Log every load with timestamp, record counts, success counts, and failure counts.
• Never overwrite your source data. Keep an untouched backup.

Step 7: How Do You Validate a Salesforce Data Migration?

Validate with record count reconciliation, financial total checks, relationship integrity tests, and business user review. Validation proves nothing was lost.

Run these checks after every mock load:

• Count reconciliation: source count versus loaded count per object
• Financial reconciliation: total opportunity value and closed-won amounts by period
• Relationship checks: contacts without accounts, opportunities without owners, orphaned activities
• Field spot checks: random samples compared line by line to the source
• Duplicate checks: run duplicate reports on key fields
• Report parity: key legacy reports recreated in Salesforce and compared

What Does User Acceptance Testing Look For?

• Findability: can reps locate their top accounts and open deals?
• Accuracy: do contact details, owners, and stages match expectations?
• History: are notes, activities, and attachments visible and correct?
• Automation: do flows and approvals still behave correctly with migrated data?

Step 8: How Do You Cut Over Without Downtime or Data Loss?

Use a freeze window, a final delta load, a go or no-go checkpoint, and a tested rollback plan. A zero-downtime commitment means users can keep working with a clear, communicated transition.

A reliable cutover sequence:

1. Announce the freeze to all users with exact dates and times.
2. Complete the final extract from the legacy system.
3. Load the delta of records changed since the last mock load.
4. Run validation reports and obtain business sign-off.
5. Switch users to Salesforce and set the legacy CRM to read-only.
6. Monitor closely for errors, missing data, and user questions.
7. Keep the legacy system available in read-only mode for a defined fallback period.

What Does a Phased Salesforce Data Migration Roadmap Look Like?

A phased roadmap breaks migration into stages with clear exit criteria. This reduces risk and shows progress early.

1. Discovery and data audit (1–3 weeks): inventory, profiling, and scope decisions.
2. Cleansing and mapping (2–6 weeks): deduplication, standardization, and mapping sign-off.
3. Mock load one (1–2 weeks): first end-to-end load and error analysis.
4. Mock load two and UAT (2–4 weeks): refined load, reconciliation, and user testing.
5. Cutover and hypercare (1–3 weeks): final load, go-live, and close monitoring.

Timelines are typical planning ranges and vary with data volume, quality, and complexity.

What Mistakes Should You Avoid in a Salesforce Data Migration?

The costliest mistakes are migrating everything without scope decisions, skipping mock loads, and ignoring user adoption.

• Migrating dirty data: it creates a dirty new system.
• Skipping external IDs: it makes reloads and relationship rebuilds painful.
• Ignoring validation rules and automation: they can reject or alter records during load.
• No reconciliation: you cannot prove completeness without it.
• Forgetting file migration: attachments often arrive late and break user trust.
• No rollback plan: every cutover needs a defined fallback.
• Poor communication: users must know what changed and when.

How Do You Protect Data Security and Compliance During Migration?

Treat migration files as sensitive data and control access, storage, and deletion from start to finish. This matters most for regulated Houston industries such as healthcare and financial services.

• Encrypt files in transit and at rest.
• Limit access to named migration team members.
• Mask or sample production data when using it in non-production environments where policy requires it.
• Delete temporary extracts after validation is complete.
• Maintain an audit trail of who loaded what and when.

How Do You Choose a Salesforce Consulting Partner in Houston for Migration?

Choose a partner with documented migration methodology, certified architects, and proven reconciliation practices. Local Salesforce consulting in Houston also gives you same-time-zone workshops and familiarity with regional industries.

Evaluate partners on:

• A written migration plan with mock loads and exit criteria
• Data quality tooling and experience with your legacy CRM
• Reconciliation reporting delivered to your business owners
• Post-launch support with defined response times
• Transparent estimates that itemize cleansing, mapping, loads, and testing

Frequently Asked Questions

What is Salesforce data migration?

Salesforce data migration is the process of extracting, transforming, and loading records from a legacy CRM or other system into Salesforce. It includes accounts, contacts, opportunities, activities, files, and custom objects.

How long does a Salesforce data migration take?

Most migrations take 4 to 16 weeks depending on data volume, data quality, and complexity. Small, clean datasets can move faster, while multi-source enterprise migrations take longer.

What is the best tool for Salesforce data migration?

The best tool depends on volume and complexity. Data Import Wizard suits small loads, Data Loader suits larger upsert-based loads, and Bulk API or ETL platforms suit very large or repeatable migrations.

How do you avoid losing data during a CRM migration?

Audit and cleanse first, map every field, load with external IDs, and reconcile results after every mock load. Keep an untouched backup of the source data.

What are external IDs, and why do they matter?

External IDs are custom fields that store the legacy system's record ID in Salesforce. They enable upserts, relationship rebuilding, and safe reloads without duplicates.

Should I migrate all my historical data to Salesforce?

No, migrate only data that supports current processes, compliance, or reporting. Archive older records outside Salesforce to reduce cost and clutter.

How do you migrate attachments and notes to Salesforce?

Migrate files into Salesforce Files and notes into the supported notes format, linking them to parent records by ID. Plan file migration separately because it adds volume and processing time.

Can you preserve original created dates during migration?

Yes, with the appropriate audit field permissions enabled for the loading user. Confirm the setup in a sandbox before production.

How many mock loads do I need?

Plan at least two full mock loads before production. The first finds errors, and the second proves fixes and supports user acceptance testing.

How do you handle duplicates during migration?

Define merge rules, preserve legacy IDs, and review high-value accounts manually. Run duplicate reports after loading to confirm results.

How much does Salesforce data migration cost?

Costs vary with volume, source systems, cleansing effort, and testing scope. A simple migration may cost a few thousand dollars, while complex multi-source projects can reach six figures.

Can a migration happen without downtime?

Yes, with a freeze window, a delta load, parallel read-only access to the legacy system, and a tested rollback plan. This is the foundation of a zero-downtime commitment.

Conclusion: Treat Migration as a Business Asset Project

A disciplined Salesforce data migration protects your customer history, shortens time to value, and builds user trust from day one. The organizations that succeed audit early, cleanse thoroughly, load in order, and prove completeness with reconciliation.

For Houston businesses, a consultative partner that delivers phased roadmaps, enterprise system integration expertise, and a zero-downtime commitment turns a risky cutover into a controlled, auditable transition. Start with the audit, rehearse with mock loads, and go live with confidence.

Ready to future-proof your IT infrastructure? Schedule a Digital Transformation Consultation with the certified experts at DESSS today.