Dynamics 365 to Salesforce migration:
process and checklist
Last reviewed:
A Dynamics 365 to Salesforce migration moves Dataverse tables into Salesforce objects and rebuilds Power Automate flows, plugins and reports. For high volumes Microsoft documents an export through Azure Synapse Link for Dataverse and Azure Data Factory. The Microsoft environment around CRM (Outlook, Teams, Power BI) decides much of the work, so it starts with an audit.
When does moving make sense?
These are the situations in which a move usually pays off:
- The business wants a CRM platform that is independent of the Microsoft stack.
- Industry or partner capabilities on Salesforce match the requirements better.
- The business is consolidating onto Salesforce after an acquisition.
- The team plans to use Agentforce on CRM data.
What Dynamics 365 lets you export
The Dynamics 365 documentation sets limits that shape the plan. The points below come from the vendor's own help pages:
- For high data volumes where real-time data is not needed, Microsoft documents scheduled exports from Dataverse to CSV using Azure Synapse Link for Dataverse, Azure Data Lake, Synapse and Azure Data Factory. For a small amount of data, Data Factory can connect to Dataverse directly. Source: Microsoft Learn
- Microsoft states that Azure Synapse Link for Dataverse is part of Dynamics 365 licenses and can be used at no extra cost; storage, query and pipeline services are billed separately. Source: Microsoft Learn
- The Data Import Wizard imports up to 50,000 records at a time; Data Loader complements the web-based import wizards for larger loads. Source: Salesforce Help
How the data maps to Salesforce
Where Dynamics 365 data normally lands in Salesforce. The final mapping is agreed field by field in the design phase and signed off before any data moves.
| In Dynamics 365 | In Salesforce | Note |
|---|---|---|
| Lead | Lead | Map lead source and status; keep the Dataverse GUID in an external ID field. |
| Account | Account | Map parent account hierarchy in a second pass. |
| Contact | Contact | Map the account lookup and primary contact relationships. |
| Opportunity and business process flows | Opportunity, sales process and stages | Business process flow stages become sales process stages and guided steps. |
| Case (incident) | Case | Map case types, priorities and entitlements. |
| Product, price list, quote, order | Product, price book, Quote, Order | Create products and price books before quotes and orders. |
| Activities (tasks, phone calls, appointments, emails) | Task, Event, Email Message | Decide the history cut-off; relink to parent records. |
| Notes and attachments | Content Note and Files | Plan the file load separately because of volume. |
| Owners, teams and business units | Users, roles, queues, sharing | Business-unit security maps to roles, profiles and sharing rules. |
| Custom tables and columns | Custom objects and fields | Review choice, lookup and calculated columns; calculated columns become formula fields or Flow. |
What does not move automatically
Some things cannot be copied across and are rebuilt, replaced or retired. These are agreed during the audit so that nothing surprises the business on go-live day:
- Power Automate flows and classic workflows (rebuilt as Flow)
- Plugins and custom code (rebuilt as Apex or replaced)
- Power BI reports and dashboards (rebuilt or re-pointed to Salesforce data)
- Outlook and Teams integrations (replaced with Salesforce equivalents)
- Model-driven app layouts (rebuilt as Lightning pages)
The plan, phase by phase
A migration runs in seven phases. Each phase ends with a deliverable that is reviewed before the next one starts.
1. Discover and audit
- List the Dynamics 365 objects, custom fields, automations, integrations and reports in use
- Count records per object and flag duplicates and stale data
- Agree what is migrated, archived or left behind
- Include Dataverse security roles, business units and environments in the inventory
Deliverable: Scope document and data inventory
2. Design the Salesforce model and the mapping
- Choose standard and custom objects, record types and the sales or service process
- Write the field-by-field mapping with transformation rules
- Design security: profiles, permission sets, sharing
- Define record ownership and user mapping
Deliverable: Target data model and signed mapping sheet
3. Prepare Salesforce
- Configure objects, fields, page layouts, validation and automation in a sandbox
- Set up integrations that must exist on day one
- Create users and permissions
Deliverable: Configured sandbox
4. Clean and transform the data
- Deduplicate and standardise values
- Resolve relationships between records before loading
- Prepare load files in dependency order and resolve Dataverse lookups to Salesforce IDs
Deliverable: Load-ready files and transformation scripts
5. Trial loads and reconciliation
- Load into the sandbox, compare record counts and sample values with the source
- Fix mapping errors and repeat until counts reconcile
- User acceptance testing with real scenarios
Deliverable: Reconciliation report and test sign-off
6. Cutover
- Freeze changes in the source system for the agreed window
- Run the final load into production and reconcile again
- Switch Outlook, Teams and mail integrations to Salesforce
Deliverable: Production go-live and rollback plan on record
7. Hypercare and retire the old system
- Support users and fix defects after go-live
- Keep the source data read-only for an agreed period
- Cancel or downgrade the old subscription only after sign-off
Deliverable: Closure report and decommission checklist
The audit in phase 1 produces the plan with dates, effort and owners for the specific case. Techila does not quote a duration before the audit, because record volumes, automation and integrations differ for every business.
Risks and how they are handled
Every migration has the same handful of risks. This is how each one is controlled:
| Risk | How it is handled |
|---|---|
| Lookup relationships break | Store the Dataverse GUID on every record and rebuild lookups from it after loading parents. |
| Business-unit security not reproduced | Map roles and sharing in the design phase and test with real users. |
| Automation and plugin gaps | Inventory flows and plugins in the audit and decide rebuild, replace or retire for each. |
| Reporting dependency on Power BI | List every dashboard in use and agree the replacement before cutover. |
| Large volumes exceed simple exports | Use the documented Synapse Link and Data Factory route for high volumes. |
| Microsoft 365 integration forgotten | Include Outlook, Teams and shared mailboxes in discovery and in the cutover plan. |
[ FAQ ]
Frequently asked questions
Can Dynamics 365 data be exported to CSV?
Yes. For high volumes Microsoft documents a scheduled export using Synapse Link for Dataverse and Azure Data Factory.
Do Power Automate flows transfer?
No. They are rebuilt as Salesforce Flow or replaced.
Can the two run together during the move?
Yes. A phased move with a freeze window at cutover is common.
How long does a migration take?
It depends on volumes, customisation, automation and integrations. The audit produces a plan with dates for the specific case.
[ Next step ]
Talk to a Salesforce architect
Techila starts with an audit of the Dynamics 365 set-up and a mapping to Salesforce. Share the objects in use, the record counts and the integrations to get started.
[ Related ]
Related
[ Evidence ]
Sources
- Microsoft: scheduled data exports from Dynamics 365 to CSV
- Salesforce: how many records can be imported with the Data Import Wizard
- Salesforce Data Loader guide (Winter '27)
Product names are trademarks of their owners. Microsoft and Dynamics 365 are trademarks of the Microsoft group of companies. Techila is not affiliated with Microsoft. Information on this page was checked on 26 October 2026; vendor limits and prices change, so confirm on the vendor pages linked in the sources.