You migrate CRM data from Microsoft Dynamics or DealCloud into Salesforce automatically by connecting both systems to a pipeline that extracts records on a schedule, maps fields to Salesforce's object model, transforms the data to match Salesforce's validation rules, and loads it through the Bulk API instead of manual exports. This guide is for data analysts and solution engineers handling client or company-wide CRM migrations into Salesforce. After reading, you'll be able to build a repeatable migration pipeline instead of a one-off manual export/import cycle.
The reason most CRM migrations stay manual is that Dynamics and DealCloud don't share Salesforce's object structure or field names. Accounts, contacts, and opportunities exist in some form in each system, but custom fields, record types, and relationship structures rarely line up, which is why teams default to CSV exports and Salesforce's Data Loader rather than a direct connection.
The Problem
Manually migrating CRM data typically means exporting from Dynamics or DealCloud to a flat file, opening it in a spreadsheet or SQL tool to clean and remap fields, then uploading through Salesforce's Data Loader. That last step alone can max out the CPU and RAM of whatever machine runs it while a person waits for the job to finish. For a single client migration, that's a few hours of manual work. For a services company running dozens of client migrations onto Salesforce, it's the same manual cycle repeated with slightly different source structures each time.
What You'll Need
- API or export access to the source system (Dynamics 365 Web API, or a DealCloud data export)
- A target Salesforce org with API access enabled and a defined object/field schema
- A field mapping document: source field to Salesforce field, including any type conversions
- A pipeline tool with connectors for both the source CRM and Salesforce, such as Integrate.io, if you want to avoid building custom API integration code
How to Migrate CRM Data into Salesforce: Step-by-Step
Step 1: Extract the Source Schema
Before mapping anything, get a full inventory of what exists in the source system, including custom fields and objects that don't have an obvious Salesforce equivalent.
What to do:
- Pull a full field list for every object you're migrating (accounts, contacts, deals/opportunities)
- Note field types, especially picklists, lookups, and custom objects unique to that CRM
- Identify fields with no direct Salesforce equivalent; these need a decision, not a default mapping
- Export a sample of real records (50-100 rows) to see actual data shapes, not just the schema definition
Output of this step: A documented source schema with field names, types, and sample values for every object in scope.
Step 2: Build the Salesforce Target Schema
Confirm what the destination actually looks like, including any custom objects or fields already in place from a prior migration or configuration.
What to do:
- Pull the Salesforce object schema via Setup or the Metadata API for every target object
- Note required fields, validation rules, and picklist value sets that will reject bad data on load
- Check for existing custom fields that may already serve the same purpose as a source field
- Flag any Salesforce validation rule that could block records with missing or malformed source data
Output of this step: A documented Salesforce target schema, including required fields and validation constraints that the migrated data must satisfy.
Step 3: Create the Field Mapping
This is the step that determines migration quality. A rushed mapping here produces bad data that surfaces as support tickets weeks later.
What to do:
- Map every source field to its Salesforce equivalent, one row per field
- Mark fields with no direct match as either "drop," "combine with another field," or "create new custom field"
- Define type conversions explicitly (e.g., Dynamics option set values to Salesforce picklist values)
- Get sign-off on the mapping from someone who understands both systems before building the pipeline
Output of this step: A finalized field mapping document that the pipeline transformation step will implement directly.
Where Integrate.io helps: Integrate.io's visual mapping interface lets you connect source and target fields without writing transformation code for standard mappings, and its 220+ built-in transformation functions handle common conversions like picklist remapping and date format changes inline.
Step 4: Build and Test the Transformation Layer
Raw source data rarely loads cleanly. Phone numbers, state names, and date formats usually need standardization before Salesforce will accept them.
What to do:
- Apply format standardization to fields like phone numbers, addresses, and dates so they match Salesforce's expected formats
- Handle picklist value translation (source system's option set values to Salesforce's picklist API names)
- Build a validation step that flags records missing a required Salesforce field before load, rather than letting Salesforce reject them at insert
- Run the transformation against your sample dataset from Step 1 and manually review the output
Output of this step: A transformation layer that converts source records into Salesforce-ready format, tested against real sample data.
Where Integrate.io helps: Integrate.io's AI Transformation component can apply natural-language rules to messy fields, for example standardizing inconsistent phone number formats or state abbreviations across records without writing separate conditional logic for every format variation encountered.
Step 5: Load Through the Bulk API, Not Manual Upload
Once transformed data is ready, the load method matters as much as the mapping. Manual, file-based loading tools don't scale past a few thousand records without becoming a resource bottleneck.
What to do:
- Use Salesforce's Bulk API (or Bulk API 2.0) for the actual insert/upsert rather than a desktop loading tool
- Use External IDs on source records to support upserts, which makes reruns idempotent instead of creating duplicates
- Load in batches sized to avoid governor limit issues (typically 2,000-10,000 records per batch depending on object complexity)
- Capture and log any row-level load errors with enough detail to fix and reload just the failed rows
Output of this step: Migrated records live in Salesforce, loaded through an API-based method that scales without maxing out a local machine's resources.
Where Integrate.io helps: Integrate.io's Salesforce connector loads through the Bulk API by default and can be scheduled to run unattended, with error notifications sent automatically instead of requiring someone to babysit a running job.
Step 6: Reconcile and Template the Migration for Reuse
The final step turns a one-off migration into a repeatable process for the next client or business unit on the same source system.
What to do:
- Run a record count reconciliation between source and target for every migrated object
- Spot-check a sample of migrated records against the source system for field-level accuracy
- Document the mapping, transformation rules, and any manual exceptions as a reusable template
- Strip out client-specific customizations from the template so the next migration only needs the last-mile configuration
Output of this step: A verified migration with a documented, reusable template that cuts the setup time for the next Dynamics-to-Salesforce or DealCloud-to-Salesforce migration.
Common Mistakes to Avoid
- Mapping fields without reviewing sample data first; schema definitions don't show real-world exceptions like inconsistent formatting or unexpected nulls.
- Using a desktop data loading tool for migrations over a few thousand records, which ties up the machine running it and slows the whole process down. Use an API-based bulk load instead.
- Skipping the reconciliation step and assuming a "successful" load means every record migrated correctly; always compare record counts and spot-check field values.
- Building a one-off migration script instead of a reusable template, which forces the team to redo mapping work from scratch on every new client.
- Not handling picklist value mismatches before load; Salesforce will reject records with invalid picklist values rather than silently truncating them.
- Ignoring format inconsistencies in fields like phone numbers and state names until after load, which then requires a separate cleanup pass inside Salesforce.
Conclusion
Migrating CRM data from Microsoft Dynamics or DealCloud into Salesforce automatically means replacing the export-clean-upload manual cycle with a pipeline that extracts on a schedule, maps and transforms fields against Salesforce's validation rules, and loads through the Bulk API. Once that pipeline exists, the same template can be cloned and adjusted for the next client's migration instead of rebuilt from scratch, cutting setup time from days to hours. Platforms like Integrate.io handle the connector, mapping, transformation, and scheduled Bulk API load in one place, which removes the need to maintain separate scripts for each part of the process. With a repeatable migration pipeline in place, onboarding the next CRM source becomes a configuration exercise rather than a new engineering project.