How to prepare Salesforce CRM exports for customer data onboarding

Salesforce is often where a customer’s commercial history lives before they move into a new SaaS product: accounts, contacts, leads, opportunities, owners, stages, activities, notes, files, and custom fields that have accumulated over years of process changes.

That makes the Salesforce export step easy to underestimate. A customer can send a CSV quickly, but the implementation team still has to answer harder questions: which objects are in scope, which IDs preserve relationships, which custom fields actually matter, which values need cleanup, and which records are ready for import.

For customer data onboarding, the goal is not just to get data out of Salesforce. The goal is to turn the export into a reviewed, validated, import-ready handoff that CSMs, implementation teams, and customer admins can trust before launch.

Start with the onboarding outcome, not the export menu

Before anyone clicks export, define what the first launch needs to support. A full Salesforce backup can be useful for reference, but it is rarely the best working file for implementation review.

For a sales-led onboarding workflow, the launch scope might include accounts, contacts, active opportunities, owners, current stages, lifecycle fields, renewal dates, segments, and a short list of custom fields. For a customer success or support workflow, it may include account ownership, contact roles, open cases, health fields, subscriptions, and key dates.

Write the scope in plain language:

• Which Salesforce objects are needed for launch?
• Which record relationships must be preserved?
• Which fields drive customer workflows in the new product?
• Which historical records are useful context but not needed on day one?
• Which test, inactive, archived, or duplicate records should stay out of the import file?

This keeps the team from preparing a giant export and then spending the onboarding project deciding what the export was supposed to mean.

Choose the right Salesforce export path

Salesforce supports several export paths, and the right choice depends on the job.

Salesforce’s own documentation for the Data Export Service describes exporting an org’s data into CSV files. That can be useful when the team needs a broad backup or a complete reference set.

Salesforce Data Loader is different. Salesforce describes Data Loader as a client application for bulk import or export of Salesforce records, with CSV output when exporting. For onboarding preparation, Data Loader can be useful when the team needs a focused object export, selected fields, or a query-driven pull that is easier to review than a full backup package.

Do not treat the export method as a minor admin detail. Document it in the handoff:

• Export method used.
• Export date and time.
• Objects exported.
• Filters or queries used.
• Whether archived, deleted, historical, attachment, or activity data was included.
• Person who produced or approved the export.

Those details matter when a customer later asks why a record, activity, or field did not appear in the launch file.

Preserve Salesforce IDs until the relationships are proven

Salesforce exports often contain IDs that look like implementation noise. They are not noise. They are often the safest way to keep account-contact, opportunity-account, lead-owner, case-account, and activity-parent relationships intact while the team prepares import-ready data.

Keep source IDs in the working file until mapping and validation are complete. That does not mean every Salesforce ID should appear in the final customer-facing product. It means the implementation team should avoid deleting the columns that explain how records connect.

For Salesforce CRM exports, the relationship review should answer:

• Does every contact that should launch have the right account link?
• Are opportunities tied to the right accounts and owners?
• Are leads intentionally separate, or should some convert into contacts or accounts before import?
• Do cases, tasks, events, notes, or activity history need a parent record in the new system?
• Are custom lookup fields in scope for launch?
• Are duplicate accounts or contacts creating conflicting relationships?

Relationship issues are expensive to fix after import because they can affect ownership, reporting, routing, permissions, customer history, and workflow automation. Treat them as launch blockers when the destination product depends on them.

Build a field map around required import fields first

A Salesforce export can contain hundreds of standard and custom fields. The implementation team does not need to debate all of them at once.

Start with the required import fields for the new SaaS product. Then map Salesforce source fields to those import fields, using example values so customer reviewers can confirm meaning.

A practical Salesforce field map should include:

• Salesforce object.
• Salesforce field API name and field label when both are available.
• Example values from the export.
• Import field in the destination product.
• Required or optional status.
• Cleanup rule, if values need to be standardized.
• Relationship dependency, if another object must be present first.
• Review owner.
• Approval state.

Example values are especially important with Salesforce custom fields. A field label may be friendly, while the API name may preserve an old process name. A column called Customer_Status__c could contain sales lifecycle, onboarding stage, billing state, support tier, or a value that only one customer admin understands.

Check picklists, stages, and owner fields early

Salesforce exports often carry process language from the customer’s current business. That language may not match the allowed values in the product receiving the import.

Review these fields before lower-priority descriptive columns:

• Account type, industry, segment, region, territory, or plan.
• Lead status and source.
• Opportunity stage, type, forecast category, amount, close date, and owner.
• Contact role, title, department, opt-in state, and email.
• Case status, priority, reason, and owner.
• Custom picklists that drive routing, reporting, onboarding, billing, or customer success workflows.

The readiness question is simple: can the destination product accept these values as-is, or do they need a cleanup rule before import?

Do not bury invalid values in a generic “data quality” note. List the exact values, count affected records, assign an owner, and show the proposed replacement. Customer admins can usually approve a value-mapping table faster than a vague request to clean the file.

Separate core records from history and attachments

Core records and historical context should not be treated as one export problem.

Accounts, contacts, leads, opportunities, cases, and custom objects may be part of the first import. Activity history, notes, files, attachments, emails, and older closed records may need a different export path, review process, or launch decision.

This is an important expectation-setting point with customers. Some customers hear “Salesforce migration” and assume every historical note, email, file, task, and closed opportunity will appear in the new product exactly as it did in Salesforce. That may not match the new product’s import requirements or the project’s launch scope.

Define the history plan separately:

• Which historical objects are in scope?
• How far back should history go?
• Which history needs to be searchable in the new product?
• Which history can live in an archive or backup?
• Which attachments or files require separate handling?
• Which historical records should be excluded from the first launch import?

That clarity prevents the implementation team from discovering late in the project that the customer expected a full activity migration while the team prepared only core account and contact records.

Validate the Salesforce export before cleanup work begins

Validation should happen before the team spends hours editing a spreadsheet. Otherwise, the team may clean fields that are not launch-critical while required import fields are missing.

Use a first-pass validation checklist:

• Required import fields are present for each in-scope object.
• Unique identifiers are available for matching or deduplication.
• Account-contact and other required relationships are present.
• Email, phone, URL, date, number, currency, and ID formats are usable.
• Required owner or assignment fields are populated.
• Picklist and stage values can be mapped to allowed import values.
• Duplicate accounts, contacts, leads, or opportunities are flagged.
• Blank values in required fields have an owner and resolution path.
• Excluded records are marked with a reason.
• Open customer questions are attached to the affected field or record group.

This moves the conversation from “the export looks messy” to “these specific issues block import readiness.”

Create a reviewable handoff package

The final handoff should be more than a cleaned CSV. It should let the next person understand what changed, what remains open, and why the file is safe to use.

For a Salesforce CRM export, include:

• Cleaned working file or import-ready file.
• Original export reference or backup.
• Field map with example values and approval status.
• Relationship notes for accounts, contacts, opportunities, cases, activities, or custom objects.
• Cleanup rules for picklists, stages, dates, owners, and duplicate handling.
• Records changed, excluded, deferred, or blocked.
• Customer questions and answers.
• Export date, filters, query notes, and review owner.

Aformity is built around this kind of customer data onboarding work: inspecting messy customer files or exports, validating records against import requirements, mapping source fields to import fields, and preparing data into an import-ready shape. The useful habit is keeping the file, validation issues, mapping decisions, cleanup rules, and customer review state connected instead of scattering them across spreadsheets and messages.

A simple Salesforce export readiness rule

Call a Salesforce CRM export ready only when the launch-critical objects are in scope, required import fields are present, values are valid, relationships are preserved, history expectations are clear, unresolved questions have owners, and customer-facing decisions have been reviewed.

That is the difference between “we exported Salesforce” and “we have import-ready customer data for onboarding.”