Key takeaways
- Treat the migration as a rebuild of your model on Salesforce, with the old data as an input rather than the spec.
- Standard sales entities map cleanly; activities, the ownership model, and option sets are the three areas that fight you.
- Migrate open records plus a defined trailing window of closed ones, and archive the rest instead of loading it into the live org.
- Run both systems in parallel and only cut over once record counts, ownership, and open pipeline reconcile between them.
Most Dynamics 365 to Salesforce migrations get sold as a data-copy exercise. Move the Accounts, move the Contacts, remap the picklists, done. That framing is where the projects go wrong, because the two platforms disagree about how a CRM should be shaped, and copying tables just reproduces the shape you already outgrew.
This playbook treats the move as a rebuild of your model on a new platform, with the old data as an input, not the spec. We name the entities that map cleanly, the three that fight you, and the decisions that are hard to reverse once records land.
Why teams replatform, honestly
Dynamics 365 Sales is a capable CRM. Teams rarely leave it because it stopped working. They leave because the rest of the business standardized elsewhere: the marketing team runs Salesforce Marketing Cloud, the service org wants Service Cloud, or an Agentforce roadmap needs everything on one platform with one data model.
Sometimes the reason is licensing and Microsoft consolidation politics rather than product fit. That is a legitimate driver, and you don’t need to invent technical faults to justify the move. Being honest about the “why” matters, because it sets the scope. A platform-standardization move is a chance to fix the model. A pure cost move tempts teams to lift and shift, which carries every old problem across for the price of the project.
Either way, the migration is a one-time window to reshape ownership, activities, and reference data. Waste it and you are running a cleanup project in eighteen months.
How do you migrate from Dynamics 365 to Salesforce?
Migrate in five phases: map Dynamics entities to Salesforce objects, decide what data to leave behind, build and test the target org, run both systems in parallel to reconcile records, then cut over integrations and users. Treat the migration as a rebuild of your model, not a lift-and-shift of tables.
Each phase has a gate. You do not start the build until the object map is agreed and the “leave behind” list is signed off, because both decisions change the target schema. You do not cut over until the parallel run proves that record counts, ownership, and open pipeline reconcile between the two systems. Skipping the gates is the most common reason a migration slips from weeks into quarters.
What maps cleanly, and what fights you
Standard sales entities have close Salesforce equivalents. The friction lives in three places: activities, the ownership model, and option sets. Dynamics stores activities as one polymorphic entity with a “regarding” link. Salesforce splits them into Task and Event with WhatId and WhoId, so a single Dynamics activity type has to be routed to the right Salesforce object during load.
Ownership is the second trap. Dynamics supports owner teams and access teams as first-class owners. Salesforce ownership is a single User or Queue, with everything else expressed through the sharing model. You cannot copy team ownership across, you have to redesign it as roles, sharing rules, and queues.
Option sets are the third. Dynamics stores picklist values as integers behind a label. Salesforce picklists key on the API name string. Map on the label and the underlying value, not the display text, or historical records land on the wrong value.
| Dynamics 365 entity | Salesforce object | Migration note |
|---|---|---|
| Account | Account | Clean. Watch account hierarchy field differences. |
| Contact | Contact | Dynamics allows parentless contacts; decide the Account default. |
| Lead | Lead | Clean. Re-map lead status and rating option sets. |
| Opportunity | Opportunity | Stage model differs; Business Process Flows have no direct equal. |
| Quote / Quote Product | Quote / Quote Line Item | Requires a Price Book and Product setup first. |
| Product / Price List | Product2 / Pricebook2 + PricebookEntry | Price list item model does not match one-to-one. |
| Order / Invoice | Order / (no standard Invoice) | Invoicing needs Revenue Cloud or a dedicated object. |
| Activity (Task, Phone Call, Appointment, Email) | Task / Event / EmailMessage | Polymorphic “regarding” splits into WhatId / WhoId. Bites. |
| Owner team / Access team | OwnerId (User or Queue) + sharing | No direct equal; redesign as roles, sharing rules, queues. Bites. |
| Option Sets (global / local) | Picklists / Global Value Sets | Map on integer value plus label, not display text. Bites. |
| Connection / Connection Role | Account Contact Relationship or junction | No direct equal; model the relationships you actually use. |
| Note (annotation) + Attachment | ContentDocument (Files) / Notes | Annotations store attachments inline; split them on load. |
| Case | Case | Clean if you are moving Customer Service too. |
Data migration strategy: what not to migrate
The most valuable decision in the whole project is what you refuse to bring across. Every closed Dynamics record you migrate is data you now own, index, and back up in Salesforce forever. Most of it never gets read again.
Set a hard rule per object and defend it. A workable default: migrate all open records regardless of age, migrate closed records for a defined trailing window, and archive the rest to a data lake or read-only export. For example, bring open Opportunities and any closed in the last 24 months, and export the older closed pipeline rather than loading it.
Use the move as a cleanup gate, not a bulk copy. Deduplicate before load, not after. Standardize the reference data (countries, industries, currencies) at the mapping stage so the new org starts consistent. This is also where a data quality pass earns its place: Data Quality Sense runs batch scans against the migrated data set and reports completeness, duplicates, and formatting gaps so you validate the load against evidence rather than spot checks. It reports and never auto-fixes, so an architect decides what to correct before cutover.
Re-pointing the integrations
A CRM is never alone. Before cutover, inventory every system that reads from or writes to Dynamics: the ERP, marketing platform, telephony, document generation, BI. Each one is a re-pointing job, and each has its own timeline and owner.
Decide the pattern per integration rather than defaulting to one. Point-to-point re-wiring is fine for one or two low-volume feeds. For anything with several consumers or high volume, put an integration layer between the CRM and the rest so future changes touch one place. Where SAP or Oracle stays as the system of record, the master-data ownership question outranks the transport question: decide which system owns customer, product, and pricing before you write a single mapping.
Keep the Dynamics integrations live during the parallel run. You want both systems fed until you trust the new one, so nothing downstream goes dark during the switch.
Parallel run and cutover
A parallel run means both systems carry production data for a bounded window while you reconcile them. It is not a soft launch. Pick the reconciliation metrics up front: record counts per object, open pipeline value, activity volume per owner, and integration message counts. When those line up across both systems for the agreed window, you have earned the cutover.
Cut over by function, not all at once, where the org allows it. Sales users can move while a legacy reporting feed still reads Dynamics for a month. Freeze writes to Dynamics at a announced moment, run the final delta load, verify the reconciliation metrics one last time, then flip integrations and revoke Dynamics write access.
Have a rollback position for the first days. That usually means keeping Dynamics readable and the delta-load scripts ready to re-run, not a full reverse migration. The goal is confidence to move forward, backed by the option to pause.
The don’t-carry-old-problems checklist
Run this list before you sign off the target schema. Each item is a problem migrations reproduce by default unless you decide otherwise.
- Rebuild ownership, don’t copy it. Translate Dynamics owner and access teams into roles, sharing rules, and queues. Do not recreate team-ownership as a lookup field.
- Redesign activities to WhatId / WhoId. Route each Dynamics activity type to Task or Event deliberately; test that “regarding” links land on the right record.
- Map option sets on value, not label. Confirm historical records resolve to the correct picklist API name, including inactive values.
- Leave closed data behind by rule. Archive beyond your trailing window instead of loading it into the live org.
- Deduplicate before load. Fix duplicates at the source or in staging; do not import them and clean up later.
- Do not clone Dynamics’ schema. Skip fields no one uses and Business Process Flow scaffolding you are replacing with Salesforce automation.
- Set the reference data standard once. Normalize countries, currencies, and industries at mapping time so the org starts clean.
- Validate the load against evidence. Reconcile counts, ownership, and pipeline with a data quality scan, not spot checks.
Where this fits, and when you don’t need us
If your Dynamics org is small, one sales team, few integrations, mostly standard entities, a capable admin and a migration tool can handle it, and hiring an architect would be overkill. The point where architecture earns its fee is scale and coexistence: multiple business units, an ERP that stays as system of record, non-trivial sharing, or an Agentforce roadmap that depends on the new model being right.
That is the shape of a CRM Transformation engagement: architect-led, from object mapping through cutover, with the old problems left in the old system. If a migration is on your roadmap, the mapping decisions above are the ones worth pressure-testing first.
For the wider decision and other source platforms, see our guides on CRM replatforming strategy, SAP CRM to Salesforce migration, and HubSpot to Salesforce migration.
Frequently asked questions
How long does a Dynamics 365 to Salesforce migration take?
Timelines are scope-dependent and indicative only. A single-team org with standard entities can move in weeks; a multi-business-unit org with an ERP integration, heavy option-set history, and coexistence requirements runs longer. The variable that moves the timeline most is the object map and the parallel-run reconciliation, not the data copy itself.
Can you migrate Dynamics 365 activities into Salesforce?
Yes, but not by direct copy. Dynamics stores activities as one polymorphic entity linked by “regarding”. Salesforce splits them into Task and Event with WhatId and WhoId. Each activity type has to be routed to the correct Salesforce object during load, and the regarding link remapped, or historical activity attaches to the wrong record.
Should you migrate all historical data from Dynamics?
No. Migrate all open records and closed records within a defined trailing window, then archive the rest to a read-only export or data lake. Every closed record you load is data you index and back up forever, and most is never read again. The migration is your cleanup gate.
What breaks most often in a Dynamics to Salesforce migration?
Three things: activities, because the polymorphic model splits into Task and Event; ownership, because Dynamics owner and access teams have no single Salesforce equivalent and must become roles, sharing rules, and queues; and option sets, because they key on integer values that must be mapped on value rather than display label.
Do you keep Dynamics running during the migration?
Yes, during a bounded parallel run. Both systems carry production data while you reconcile record counts, ownership, and open pipeline. Keep the Dynamics integrations live so downstream systems stay fed, then freeze writes, run a final delta load, verify the metrics, and cut integrations over to Salesforce.
Michał Bajdek
Co-Founder, Tucario
Co-founder of Tucario, a Salesforce consulting and product engineering firm. Works across enterprise Salesforce delivery — architecture, integrations and AppExchange products — and writes about what holds up in production.