Migration
Salesforce to Microsoft Dynamics 365 migration: data, automation and permissions
Short answer
MS Dynamics Guys moves CRM (customer relationship management) data and processes from Salesforce to Microsoft Dynamics 365 Sales or Customer Service. We map objects and relationships, move activities and files, and redesign automation and permissions for Dataverse instead of copying them. Each load is rehearsed and reconciled, and users are trained before cutover, so the switch does not stop sales or service work.
Why a Salesforce move is more than a data export
A CSV (comma-separated values) export moves rows. It does not move the relationships, owners, history and rules that make CRM data useful. These are the main differences between the two platforms:
- Data model: standard objects map well, but record types, picklists, lookups and custom objects need design decisions in Dataverse.
- Automation: Salesforce Flows and Apex triggers do not convert. Each one is redesigned as a Power Automate flow, a business rule or a C# plug-in, depending on when it must run.
- Security: profiles, permission sets, the role hierarchy and sharing rules have no one-to-one equivalent. Dataverse uses security roles, business units, teams and column-level security.
- History: created dates, owners, activities and email threads need explicit handling, or users lose the context behind each account.
Treat the move as a focused Microsoft Dynamics 365 implementation with a data migration inside it. The target processes come first; data then loads into a working system.
How Salesforce objects map to Microsoft Dynamics 365
Most standard objects have a natural home. The decisions in the right-hand column are where migrations go wrong.
| Salesforce | Microsoft Dynamics 365 | Decisions to make |
|---|---|---|
| Account | Account | Parent account hierarchy, account record types and which inactive accounts move |
| Contact | Contact | Contacts linked to several accounts; consent and email preferences |
| Lead | Lead | Open leads only or converted history too; how qualification creates accounts, contacts and opportunities |
| Opportunity and opportunity products | Opportunity and opportunity products | The product catalog, price lists and units must exist first; sales stages map to the business process flow |
| Case | Case in Customer Service | Queues, entitlements, status reasons and how much closed-case history moves |
| Task, Event and logged email | Task, appointment and email activities | Links to the right account, contact or opportunity; owners; how much activity history moves |
| Notes, Files and attachments | Notes with attachments, file columns or SharePoint document libraries | Storage cost and where users expect to find documents |
| Custom objects | Custom tables | Whether each object is still used; relationships and naming |
| Users, queues and groups | Users, queues and teams | Who owns each record after the move; mapping of inactive users |
How Salesforce automation is rebuilt in Microsoft Dynamics 365
We inventory every automation first. Some exist only to work around a process the new design removes; others are already covered by standard Microsoft Dynamics 365 features.
| Salesforce | Microsoft Dynamics 365 option | When we choose it |
|---|---|---|
| Record-triggered Flow that runs after save | Power Automate cloud flow | The logic can run moments later and needs connectors, approvals or notifications |
| Before-save Flow or validation rule | Business rule or C# plug-in | The rule must apply in the same transaction, from every entry point |
| Apex trigger or Apex class | C# plug-in or custom API (application programming interface) | Complex logic, calculations or integrations that need code and tests |
| Approval process | Power Automate approvals | Approvals with notifications in Outlook or Teams |
| Case assignment and escalation rules | Customer Service routing rules and SLA (service-level agreement) rules | Cases routed by queue, priority or customer, with response targets |
| Scheduled Apex or scheduled Flow | Scheduled Power Automate flow or a hosted job | Batch work that runs on a timetable |
How the security model maps to Dataverse
| Salesforce | Dataverse | What to know |
|---|---|---|
| Profiles and permission sets | Security roles | Roles add up: a user gets the broadest access granted by all roles and team memberships |
| Role hierarchy | Business units | Business units set data boundaries; they do not have to copy the organization chart |
| Sharing rules and manual sharing | Owner teams, access teams and record sharing | Use record sharing for exceptions only; it is slower and harder to troubleshoot |
| Field-level security | Column-level security profiles | A profile grants column access only to users who already have access to the record |
| Public groups and queues | Teams, Microsoft Entra group teams and queues | Group teams follow membership of Microsoft Entra security groups |
How MS Dynamics Guys runs a Salesforce to Microsoft Dynamics 365 migration
Inventory Salesforce
Objects, record counts, file volumes, automations, reports, integrations and the people who own each of them.
Design the target
Microsoft Dynamics 365 is configured for the agreed processes first, so data loads into a working system rather than an empty copy of Salesforce.
Map, transform and sign off
Every field gets a target and a rule. Process owners approve the mapping before the first full load.
Rehearse with full volumes
Loads run in batches that stay within Dataverse service protection limits, and each rehearsal is timed.
Reconcile
Record counts, open pipeline value and open case counts must match between the systems after each load.
Train and cut over
Users train on their own migrated data. Salesforce becomes read-only, the final changes load, and the team reconciles before the go or no-go call.
Retire integrations and Salesforce
Integrations move to Microsoft Dynamics 365, and Salesforce stays read-only until the agreed retention date.
Testing, acceptance and handover follow how we work. Integrations are rebuilt as described on Microsoft Dynamics 365 integration services.
Can MS Dynamics Guys keep our Salesforce history when we move?
Most of it, if the decisions are made early. Here is what moves and what needs care:
- Created dates: imported records can keep their original creation date in Dataverse through the overriddencreatedon column.
- Modified dates and authors: Dataverse does not import the original modified date, creator or last editor. We copy them into custom columns when people need them.
- Owners: records reach the right owners only if every Salesforce user is mapped to a Microsoft Dynamics 365 user or team before the first load.
- Activities and email: tasks, events and logged emails move as activities linked to the right account, contact, case or opportunity.
- Files: documents move to notes, file columns or SharePoint. Large volumes affect storage costs, so we size them during the inventory.
- Field history: Salesforce field history does not carry over into Dataverse auditing, which records changes made after go-live. Export it to an archive if you need it.
To answer precisely, we need read access to your Salesforce org or a full export. We also need the list of users with their future roles, and each team's decision on how much history it uses.
Running the Salesforce move with your own team?
Many companies plan the move themselves or with an implementation partner. Their plan may be sound and still miss one skill. MS Dynamics Guys can add that specialist to your team without taking over the project:
- A Microsoft Dynamics 365 CRM consultant maps your Salesforce sales and service processes to Microsoft Dynamics 365 configuration before the first load. The consultant also marks the rules that need code.
- A data migration engineer owns the load scripts, the alternate keys that make reruns safe, and the reconciliation report after every rehearsal.
- A Microsoft Dynamics 365 CRM developer rebuilds Apex triggers, and other logic that must run inside the save, as C# plug-ins with unit tests.
This is staff augmentation: your project lead directs the specialist day to day, and the cutover date stays your decision.
When MS Dynamics Guys fits
MS Dynamics Guys fits companies that have chosen Microsoft Dynamics 365 Sales or Customer Service and want their Salesforce data, automation and permissions moved with a design, not a copy.
A good fit when
- You have years of accounts, opportunities, cases and activities that people rely on.
- Salesforce automation and Apex logic must keep working in a new form.
- Permissions need to be redesigned and tested before users log in.
- You want the mappings and load scripts kept, so every load can be rerun and audited.
Choose another route when
- You are still choosing a CRM product. Start with Microsoft Dynamics 365 consulting.
- You only need a few hundred contacts imported once.
- You want Salesforce rebuilt screen for screen in Microsoft Dynamics 365.
- You need changes inside Salesforce itself. A Salesforce specialist is the right contact for that.
Salesforce to Microsoft Dynamics 365 migration questions
Is there a tool that migrates Salesforce to Microsoft Dynamics 365 automatically?
No tool converts automation, permissions and processes. Data loading tools and integration platforms move records, but the mapping, transformation rules and redesign are the real work. We keep the load process repeatable, so every rehearsal uses the same scripts.
Can we run Salesforce and Microsoft Dynamics 365 in parallel?
For a short period, usually with Salesforce read-only. Running both for active work doubles data entry and creates conflicts. We plan a firm cutover date and a read-only retention period instead.
What happens to our Salesforce integrations?
Each one is listed during the inventory and then rebuilt against Microsoft Dynamics 365, replaced by a standard connector, or retired. Integrations are often on the critical path, so that work starts early.
How do you handle duplicate records during the move?
We find duplicates during the inventory and agree merge rules with your teams before the first load. Storing the Salesforce record ID in an alternate key lets reruns update existing records instead of creating new ones.
Do users need retraining?
Yes. Microsoft Dynamics 365 Sales works differently from Salesforce, and the Microsoft Dynamics 365 App for Outlook and Microsoft Teams integration change daily habits. Training uses the users' own migrated data, which shortens adoption.
How long does a Salesforce to Microsoft Dynamics 365 migration take?
It depends on data volume, the number of automations and integrations, and how many processes change. Timed rehearsals give a reliable cutover window, so we do not quote durations before the inventory.
Plan your move from Salesforce
Send your Salesforce editions, approximate record and file volumes, and your target date. We reply with questions or a proposed next step.
Product documentation referenced on this page
- Ownership-based security in Microsoft Dataverse Microsoft Learn, checked October 2, 2026
- Service protection API limits (Dataverse) Microsoft Learn, checked October 2, 2026
- Use Upsert to create or update a record (Dataverse) Microsoft Learn, checked October 2, 2026
- Run data import (Dataverse) Microsoft Learn, checked October 2, 2026
- Use SharePoint and Microsoft Dynamics 365 apps to manage your documents Microsoft Learn, checked October 2, 2026
- Plug-ins and supported customizations in Dataverse Microsoft Learn, checked October 2, 2026
- Microsoft Dynamics 365 App for Outlook overview Microsoft Learn, checked October 2, 2026