To migrate from Dynamics 365 to Salesforce, redesign rather than copy. Map each Dynamics entity to a Salesforce object and rebuild plugins and Power Automate flows from their business rules. Translate business units and security roles into Salesforce's sharing model. Then plan Outlook, Power BI and ERP connections, run test loads in a sandbox, and cut over in one planned window. Scope and integrations, not record volume, decide how long it takes.
Why companies move from Dynamics 365 to Salesforce
Most moves start with a business change, not a feature list. Common triggers include a merger with a company that runs Salesforce, or a sales team that has stopped using the CRM. Another is a Dynamics org so heavily customized that every change is slow.
Others want Salesforce's partner ecosystem, its AgentExchange (formerly AppExchange) catalogue, or a specific cloud such as Service Cloud or Field Service. The case for staying is real too. If your finance, collaboration and reporting all run on Microsoft and your CRM works, the cost of switching may outweigh the gain. Our comparison of Salesforce and Microsoft Dynamics 365 covers that decision in more depth.
How do Dynamics entities map to Salesforce objects?
Most standard Dynamics tables have a direct Salesforce counterpart, but the automation and customization layers do not. Treat the table below as a starting point for design conversations, not a field-for-field recipe.
| Dynamics 365 | Salesforce | Decision to make |
|---|---|---|
| Accounts | Accounts | Parent account hierarchy, and whether any B2C customers need person accounts |
| Contacts | Contacts | How to handle contacts linked to several accounts through connections |
| Leads | Leads | Which qualified leads to load as contacts and opportunities instead |
| Opportunities and opportunity products | Opportunities, products and price books | Stage mapping, forecast categories and whether history needs line items |
| Cases | Cases | Status, priority and queue mapping, plus how many closed cases to keep |
| Activities (email, phone call, appointment, task) | Tasks, events and email messages | How far back to load, and how to handle activities with many participants |
| Notes and attachments | Notes and Files | Which attachments are worth the storage, and which stay in an archive |
| Custom tables and columns | Custom objects and fields | Which are still used; many will not survive review |
| Option sets | Picklists | Agreeing values and cleaning records to match |
| Business rules and form scripts | Validation rules and Dynamic Forms | Which rules protect data and which only hide fields |
| Business Process Flows | Path, record types and screen Flows | Whether each stage needs guidance, required fields or a separate process |
| Classic workflows and Power Automate flows | Record-triggered and scheduled Flows | Which flows are CRM logic and which are really integrations |
| Plugins and custom workflow activities | Apex triggers and invocable Apex | Whether declarative Flow can now do the job instead of code |
Two areas need extra care. Dynamics activities can list many parties in the To, CC and regarding fields. Salesforce tasks and events relate to records differently, so decide which relationships reporting actually needs before loading years of history.
Power Automate flows also hide integration logic. A flow that posts to Teams, writes to SharePoint or calls an ERP is not CRM automation. It belongs in your integration plan, not in Salesforce Flow.
How does the Dynamics security model translate?
The concepts overlap, but they are split differently. Dynamics bundles object permissions and record access into security roles scoped by business unit. Salesforce separates what a user can do from which records they can see.
| Dynamics 365 | Salesforce | Notes |
|---|---|---|
| Security roles (privileges) | Permission sets and permission set groups, with a minimal profile | Build permissions around job functions rather than copying each role |
| Access levels (user, business unit, organization) | Org-wide defaults and sharing rules | Start private where needed, then open access with rules |
| Business units | Role hierarchy, often with sharing rules | Business units partition data; the role hierarchy grants upward visibility |
| Hierarchy security | Role hierarchy | Managers see their team's records through the hierarchy |
| Owner teams | Queues and public groups | Queues own work; public groups receive shared access |
| Access teams | Account teams and opportunity teams | Confirm the team roles and access levels before loading members |
| Field security profiles | Field-level security in permission sets | Review sensitive fields one by one |
A direct copy of business units usually produces a role hierarchy that is too deep. Start from who needs to see what, test with real users in a sandbox, and document the result. Our Salesforce security review checklist is a useful check once the model is built.
What happens to Outlook, Teams, Power BI and the ERP?
Each Microsoft connection needs a deliberate plan: a Salesforce equivalent, a rebuilt integration, or a decision to retire it. List every connection before you set dates, because integrations drive the timeline more than data does.
- Outlook: replace the Dynamics App for Outlook with Salesforce's Outlook integration and decide whether emails and meetings are logged manually or captured automatically.
- Teams: Salesforce offers a Teams integration for sharing records in chats. Some companies use the migration to evaluate Slack instead.
- Power BI: Power BI can report on Salesforce through its Salesforce connectors. Decide which dashboards move into Salesforce reports and which stay in Power BI.
- SharePoint documents: decide whether files move into Salesforce Files or stay in SharePoint, linked from the record.
- ERP, such as Business Central: rebuild the account, product, order and invoice sync through middleware or a maintained connector. Agree which system owns each field.
ERP integrations deserve the most testing. Order and invoice data affect revenue reporting, so run end-to-end tests with finance before cutover. Our Salesforce ERP integration guide covers system-of-record decisions and error handling.
What are the data migration steps?
The steps are the same as any Salesforce migration: scope, cleanse, map, load in dependency order, and reconcile. Our Salesforce data migration checklist covers each one, so here we focus on what is specific to Dynamics.
- Extract from Dataverse with a tool that preserves GUIDs, and store each GUID in an external ID field in Salesforce.
- Resolve Dynamics customer lookups, which can point to an account or a contact, into separate Salesforce relationships.
- Convert option set integer values into their labels before mapping them to picklists.
- Map every Dynamics user and team owner to a Salesforce user or queue, including people who have left.
- Decide which activity history and attachments to load, and archive the rest in a format you can search.
Run at least one full test load into a sandbox, time it, and reconcile record counts and totals. Users who test on real migrated data find mapping problems that sample records never show.
Migration works best inside the wider project. A compliance-software company we worked with moved its accounts, contacts, leads, opportunities, tasks and activities from HubSpot to Salesforce in 4-6 weeks. The source was different, but the approach was the same: migration planned as part of the implementation.
How should cutover and a parallel run work?
Cut over in one planned window, and keep any parallel run short and read-only. Two live CRMs split the truth, and users will keep working in whichever one feels familiar.
- Freeze configuration changes in both systems before the final load.
- Turn off Dynamics workflows, Power Automate flows and plugins that send emails or update other systems.
- Run a delta load for records changed since the last full load, then reconcile.
- Repoint forms, Outlook add-ins and ERP integrations in the same window.
- Set Dynamics to read-only for a defined period, then export a full archive before licences lapse.
How do you win over Outlook-centric users?
Bring Salesforce into Outlook before you ask people to leave it. Dynamics users often worked almost entirely from the Outlook app, so the Salesforce Outlook experience must be ready and tested on day one.
Train by role, using the tasks each person does daily, and show where email logging and meeting capture now happen. Simplify page layouts so the first screens are shorter than the Dynamics forms they replace. One manufacturer we worked with started from zero Salesforce usage. It combined Outlook integration with consolidated record types, and all 99 reps were active within 30 days.
What breaks when moving from Dynamics to Salesforce?
What breaks is usually hidden logic and hidden connections, not records. These are the mistakes we see most often.
- Copying every entity, field and business unit instead of redesigning around current processes.
- Missing plugins and JavaScript that silently set values, so Salesforce data arrives incomplete after go-live.
- Treating Power Automate flows as CRM automation when they are really integrations.
- Rebuilding security roles one to one, which creates dozens of overlapping permission sets.
- Loading every activity and attachment, then running short of storage.
- Leaving Outlook setup to the last week, so email capture fails for the users who matter most.
- Running a long parallel period with both systems open for editing.
How long does a Dynamics to Salesforce migration take?
It depends on scope, customization and integrations far more than on record count. A lightly customized sales org moves much faster than one with years of plugins, flows and ERP connections.
- The number of custom entities, plugins and Power Automate flows that need to be analysed and rebuilt.
- How many integrations exist, and whether each is rebuilt, replaced or retired.
- The complexity of business units and security roles, and how much access redesign is needed.
- Data quality in Dynamics, and how much history and how many attachments you keep.
- Whether the project includes new capability, such as Service Cloud or marketing automation, alongside the move.
- How quickly business owners can make mapping and design decisions.
- Whether you roll out to all teams at once or in phases.
A short discovery phase that inventories customizations and integrations is the fastest way to a timeline you can trust. Ask any partner to show that inventory before committing to dates.
