More in
Data Migration Guide
Exporting Cleanly from Salesforce: The Migration-Ready Export Guide
Apr 18, 2026 · Currently reading
Exporting Cleanly from HubSpot: What the Native Export Misses
Apr 18, 2026
Exporting Cleanly from Pipedrive: Deals, Contacts, and Activity History
Apr 18, 2026
Escaping Spreadsheets: The 5-Step Migration to a Real CRM
Apr 18, 2026
Handling Historical Activities, Notes, and Emails During CRM Migration
Apr 18, 2026
Post-Migration Data Audit: What to Verify and When
Apr 18, 2026
User Access During CRM Migration: The Least-Privilege Approach
Apr 18, 2026
Communicating the CRM Migration to Your Sales Team
Apr 18, 2026
Rollback Planning for CRM Migrations: Hope You Don't Need It
Apr 18, 2026
Long-Term Archiving of Legacy CRM Data: What to Keep and How
Apr 18, 2026
Exporting Cleanly from Salesforce: The Migration-Ready Export Guide
A Sales Ops team at a mid-market SaaS company spent six weeks preparing for their CRM migration. They exported Contacts and Accounts, spot-checked a few records, and called the export done. Three days after go-live, their new CRM showed zero activity history for 4,200 contacts. The team hadn't exported Tasks or Events — the two Salesforce objects where every call log, email, and meeting lived. Three years of interaction history, gone.
The export itself took 20 minutes. The recovery took three weeks of manual reconstruction from email archives and rep memory. Not every record came back.
This guide walks through the Salesforce export process that actually preserves everything: objects, relationships, custom fields, and activity history. Follow it in order. The sequence matters.
What Salesforce Data Maps to What
Before you touch the export tools, you need to understand what you're extracting. Salesforce organizes data into objects. Most teams know the obvious ones. The ones teams miss are the ones that cause pain. This mapping work connects directly to field mapping between legacy and new systems — you can't build a reliable field map without first knowing what objects you're extracting.
According to Gartner research on CRM data quality, poor data quality costs organizations an average of $12.9 million per year — and CRM migrations are one of the highest-risk moments for data quality degradation.
Objects you must export:
| Object | What it holds | Common mistake |
|---|---|---|
| Account | Company records, the parent for most relationships | Exported last, breaking Contact links |
| Contact | Individual people linked to Accounts | Exported without the Account relationship |
| Lead | Unqualified prospects, separate from Contacts | Forgotten entirely if the team "doesn't use Leads" |
| Opportunity | Deals, linked to Accounts and Contacts | Opportunity contacts (junction object) often missed |
| Task | Logged calls, to-dos, follow-ups | Almost always forgotten |
| Event | Meetings, calendar events | Treated as optional, rarely exported |
| Case | Support tickets, if used | Skipped by sales teams who don't own Support |
| Custom objects | Whatever your org has built | Completely invisible unless someone documents them |
The relationship graph runs Account → Contact → Opportunity, with Tasks and Events attaching to all three. If you export Contacts without Accounts, every Contact loses its company association. If you skip Tasks and Events, you lose the activity timeline entirely.
Write out every object your org uses before you start. Check with your Salesforce admin if you're not certain.
Step 1: Use Data Export or Data Loader — and When Each Is Right
Salesforce gives you two primary export tools. They're not interchangeable.
Data Export (Setup > Data Export)
- Scheduled weekly or run on-demand through the UI
- Exports everything in a single zip file by object
- Hard limit: ~512MB per file; large orgs hit this on Contacts or Opportunities
- No filtering — you get every record in each object
- Good for: Small to mid-size orgs, initial full export, teams without Salesforce admin depth
Data Loader
- Standalone desktop application (Windows/Mac)
- Handles large volumes: tested up to tens of millions of records
- Requires SOQL queries — you control exactly what fields come out
- Lets you filter by date range, record type, or any field value
- Good for: Large orgs, selective exports, custom objects with complex relationships
For most migrations, Data Loader is the right choice. Data Export is fine for orgs under 50,000 records per object, but the moment you're dealing with complex field relationships or large activity histories, Data Loader gives you the control you need. If you're unsure whether your org qualifies as a complex migration, preparing your data before you migrate anything helps you scope the work before the export begins.
A note on API rate limits: Data Loader uses Salesforce's API. If your org has other integrations running simultaneously, you can hit rate limits mid-export. Schedule large exports during off-hours or check with your Salesforce admin about your API allocation. The Salesforce Data Loader developer documentation covers batch size configuration and API usage limits in detail.
Step 2: Export in the Right Order
Object dependencies in Salesforce mean that some records can't be meaningfully imported into a new system unless the records they reference already exist there. Export in the wrong order and you'll have CSV files full of orphaned records.
Required export order:
- Account
- Contact (references Account)
- Lead (independent, but export early)
- Opportunity (references Account)
- OpportunityContactRole (the junction object linking Opportunities to Contacts)
- Task (references Contact, Lead, Opportunity, Account)
- Event (same as Task)
- EventRelation (if your org uses shared meetings with multiple attendees)
- Case (if used)
- Custom objects (export in their own dependency order)
Why does Account come first? Because Contacts reference AccountId. When you import into the destination system, Contacts need to reference existing Account records. Export Accounts first, import them first, then handle Contacts with the correct Account associations.
OpportunityContactRole is the silent killer. It's a junction object that stores which Contacts are associated with which Opportunities. Skip it and your Opportunities arrive in the new CRM with no contact relationships. Most teams forget it exists. The same principle applies to handling historical activities, notes, and emails — relationship data and activity history both require deliberate export decisions, not just a default "export all."
Step 3: Handle Lookups and IDs
This is where the export gets technically important. Every lookup field in Salesforce contains a Salesforce record ID — an 18-character alphanumeric string that means nothing outside of Salesforce. When you open a Contact record, the AccountId field contains something like 001A000001B2cDEFAB. That ID doesn't exist in your new CRM.
What to do:
For every lookup field, export the related record's meaningful identifier alongside the Salesforce ID. For Contacts, this means exporting both AccountId and Account.Name in the same row. For Opportunities, export both AccountId and Account.Name, plus OwnerId and Owner.Name.
In Data Loader, your SOQL query looks like:
SELECT Id, FirstName, LastName, Email, Phone, AccountId, Account.Name,
OwnerId, Owner.Name, LeadSource, CreatedDate
FROM Contact
The dot notation (Account.Name) pulls the related field inline. This gives your cleaning and import steps a human-readable reference alongside the Salesforce ID.
External IDs: If your org uses custom external ID fields (common in orgs that integrate with ERP or billing systems), export those fields too. They become the join key in the destination system.
ID translation reference table:
| Export field | What it is | What you need alongside it |
|---|---|---|
| AccountId on Contact | Salesforce Account record ID | Account.Name |
| OwnerId on any object | Salesforce User record ID | Owner.Name, Owner.Email |
| ContactId on Opportunity | Salesforce Contact record ID | Contact.FirstName, Contact.LastName, Contact.Email |
| WhoId on Task | Contact or Lead ID | WhoId.Name (the "Who" field) |
| WhatId on Task | Account, Opportunity, or Case ID | WhatId.Name (the "What" field) |
Export these relationship names alongside every ID. You'll use them during field mapping in the next stage.
Step 4: Export Activities Correctly
Tasks and Events live in their own objects. They're not embedded in Contact or Opportunity records. And they have their own relationship fields that need the same treatment as the lookup fields above.
For Tasks (SOQL via Data Loader):
SELECT Id, Subject, Description, Status, Priority, ActivityDate,
WhoId, Who.Name, Who.Type,
WhatId, What.Name, What.Type,
OwnerId, Owner.Name, CreatedDate
FROM Task
WHERE ActivityDate >= 2022-01-01
The WhoId is the person the task is about (Contact or Lead). The WhatId is the related record (Opportunity, Account, or Case). Export both the IDs and the names.
For Events:
SELECT Id, Subject, Description, StartDateTime, EndDateTime, Location,
WhoId, Who.Name, WhatId, What.Name, OwnerId, Owner.Name, CreatedDate
FROM Event
WHERE StartDateTime >= 2022-01-01T00:00:00Z
Date range filtering: Most teams don't need every Task and Event from the beginning of time. Filter to the last 2-3 years unless there's a specific business reason to go further back. Unfiltered activity exports from mature Salesforce orgs can run into millions of records — many of them auto-generated system events with no actual content. See handling historical activities, notes, and emails for the decision framework on what's worth migrating versus what to archive.
The WhoId.Type field tells you whether the task is linked to a Contact or a Lead. Export it so you can route correctly during import.
Step 5: Validate Your Export Before You Close Salesforce
Don't start cleaning until you've verified the export is complete. This check takes 30 minutes and catches the problems that would otherwise surface six weeks after go-live.
Row count validation:
| Object | How to get Salesforce count | Expected behavior |
|---|---|---|
| Account | Reports > New Report > Accounts | CSV rows should match ± 1% |
| Contact | Same method | Large gaps indicate export filtering issues |
| Opportunity | Same method | Check Open + Closed counts separately |
| Task | Use Salesforce developer console: SELECT COUNT() FROM Task |
Export should match |
| Event | Same console query | Export should match |
Spot-check process:
Pick 20 random Contact records from your export. For each:
- Open the record in Salesforce
- Verify key fields match the CSV row
- Check that Account.Name is populated
- Check that at least one Task or Event appears in the related activity timeline
- If any record fails, investigate before continuing
Custom field completeness:
Pull your org's field list from Setup > Object Manager > [Object] > Fields & Relationships. Compare it to your export column headers. Missing columns mean you'll need to re-export with additional fields in your SOQL query.
The Salesforce Export Checklist
Use this before signing off on the export:
- All required objects identified and listed
- Export order follows Account → Contact → Lead → Opportunity → OpportunityContactRole → Task → Event
- Every lookup field includes the related record's human-readable name alongside the Salesforce ID
- WhoId and WhatId fields on Tasks and Events include .Name and .Type
- Row counts validated against Salesforce Reports or developer console queries
- 20 random records spot-checked per object
- Custom fields verified against object field list
- Activity history filtered to an appropriate date range
- Export files stored in a controlled location with access limited to the migration team
Common Pitfalls
Exporting only Contacts and missing Accounts. Contacts reference Accounts. Without Accounts, every Contact loses its company association on import. Always export Accounts first.
Losing formula field values. Salesforce formula fields calculate dynamically — they don't store a value. When you export them, you get the calculated value at export time. If the formula references another object that changes, the exported value won't update. Export formula fields as-is and note which fields they are in your field map.
Forgetting record types. If your org uses Record Types (different page layouts and picklist values for different record categories), the RecordType.Name field must be in your export. Record type distinctions often affect how records should be categorized in the destination CRM.
Hitting API rate limits mid-export. Data Loader makes API calls in batches. A large export — say, 2 million Tasks — can exhaust your org's daily API allocation. Monitor the batch progress and export large objects overnight if needed.
Not exporting deleted records. If you need to migrate records that were soft-deleted (in the Recycle Bin), you need a separate query using ALL ROWS in SOQL. Most teams don't need this, but it's worth confirming with stakeholders before export. The NIST guidelines on data integrity provide a useful framework for defining which records must be preserved during system transitions. Records you don't migrate but still need to retain belong in a long-term archive of your legacy CRM data — not in the destination system, and not just forgotten.
What to Do Next
Your validated export is the raw material for everything that follows. But raw export files aren't ready to import — they need to be cleaned, deduplicated, and field-mapped before touching the destination CRM.
The next step is data cleaning: deduplication, normalization, and enrichment. Run your exported CSVs through that process before opening the import tool in your new system. A McKinsey report on data strategy found that companies with strong data governance discipline see 23x higher rates of customer acquisition — starting migration with clean, validated exports is the foundation of that discipline.
If you're working from a field mapping that isn't finalized yet, mapping fields between legacy and new systems covers the decisions you need to make before cleaning starts.
And if you haven't yet decided what to do with all those Tasks and Events, preparing your data before you migrate anything covers the strategic decisions that shape every export and import decision downstream.
Learn More
- Data cleaning: deduplication, normalization, enrichment
- Mapping fields between legacy and new systems
- Preparing your data before you migrate anything
- Testing the migration with a shadow import
- CRM data model design: custom fields, objects, and relationships
- Pipeline hygiene culture: keeping your CRM clean after go-live

Head of Enterprise Solutions
On this page
- What Salesforce Data Maps to What
- Step 1: Use Data Export or Data Loader — and When Each Is Right
- Step 2: Export in the Right Order
- Step 3: Handle Lookups and IDs
- Step 4: Export Activities Correctly
- Step 5: Validate Your Export Before You Close Salesforce
- The Salesforce Export Checklist
- Common Pitfalls
- What to Do Next
- Learn More