Salesforce to Dynamics 365 Sales Migration
Salesforce to Dynamics 365 Sales Migration moves your sales organization off Salesforce and onto Dynamics 365 Sales in a planned, reconciled way: every Salesforce object and field mapped to Dataverse, data migrated with its history — original created dates preserved, owners re-mapped, activities and files attached to the right records — sales processes rebuilt as Dynamics business rules, business process flows, and Power Automate flows, users trained by role, and a coexistence window in which Salesforce goes read-only while the new system proves itself. Pricing is by written quote after discovery, because object count, customization depth, and history volume drive the effort; a typical mid-market migration runs about six weeks. What we assess honestly rather than promise: an org built on heavy Apex or Lightning components is a custom application, not a CRM, and the discovery report says so before you commit.
What this engagement is
The case for moving a sales team from Salesforce to Dynamics 365 Sales is consolidation, not ideology. Salesforce is a capable CRM, and plenty of organizations have no reason to leave it. This service exists for the ones that have decided one platform vendor is enough and want the CRM that lives inside the stack they already run: the same Microsoft Entra ID sign-in and Conditional Access, Outlook and Teams as the working surface, SharePoint for documents, Power BI for reporting, Power Automate for automation, and one admin center. Microsoft publishes phased-migration guidance for exactly this move, and the engagement follows that shape — inventory, map, build, trial, cut over — with the quote built from what discovery finds rather than from a brochure. Discovery is where honesty happens. We inventory the Salesforce org read-only: standard and custom objects, fields and picklists, record types and page layouts, the automation estate — Flows, any Workflow Rules and Process Builder processes still running (Salesforce ended support for both at the end of 2025, and many orgs still have them), Apex triggers and classes, validation rules — reports and dashboards, AppExchange packages and integrations, profiles, roles and sharing rules, data volumes, and file storage. Every item is classified: maps cleanly to Dynamics 365 Sales, needs redesign, or is really a custom application built on the Salesforce platform. That third category is the one we refuse to bury in a migration quote. A sales org with a few hundred lines of Apex migrates; an org whose business runs on thousands of lines of Apex and custom Lightning components is an application rebuild, and the discovery report says so with options — a separately scoped Power Platform rebuild, a phased approach, or a referral — before you have spent anything on the move. The migration itself is engineering with reconciliation at every step. Objects and fields map to Dataverse tables — Leads, Accounts, Contacts, Opportunities, Products and Price Books, Quotes, Campaigns, activities, and your custom objects as custom tables. Data is extracted in full from Salesforce, including files, transformed with the agreed deduplication, owner, and picklist rules, and loaded with Microsoft tooling — Power Query dataflows with the Salesforce Objects connector, Dataverse import, or Azure Data Factory for larger volumes. History is handled the way Dataverse actually allows rather than the way a sales deck implies: original created dates are preserved through Dataverse's created-on override, owners are re-mapped to Dynamics users and teams, the original created-by and last-modified values land in reference columns because Dataverse does not let an import set them, field-history tracking is migrated as a read-only history table, and Salesforce Files move into SharePoint through Dynamics 365's document management so they open from the record without consuming Dataverse capacity. At least one full trial load precedes cutover, with counts and totals reconciled per object. Then the people and the processes. Salesforce automation is rebuilt, not copied: business process flows for stage-gated pipelines, business rules for field logic, Power Automate flows for the rest, assignment and routing rules, email templates. Salesforce's Outlook integration is replaced by the Dynamics 365 App for Outlook and server-side synchronization. Reports and dashboards are rebuilt as Dynamics views, charts, and dashboards, with Power BI for the ones that deserve it. Users are trained by role before cutover, not after. Cutover runs a delta load, Salesforce goes read-only for an agreed coexistence window, hypercare follows, and you receive the final Salesforce export archive and a decommission checklist. Ending the Salesforce subscription is your commercial step; we get you to the point where it is safe. If you are already running both CRMs and need them to coexist for a while rather than migrate, that is the Salesforce + Dynamics 365 Sales integration service — the two are deliberately separate.
Success criteria
What you receive
How the work unfolds
Read-only review of the Salesforce org: objects, fields, automation, Apex, reports, packages, integrations, security model, data and file volumes, and your contract dates. Every item is classified and sized. Output: the migration workbook and your fixed quote.
Dataverse data model, field and picklist mapping, security design, process design, integration and package dispositions, and the license-tier recommendation. You approve the design before anything is built.
Configure Dynamics 365 Sales, rebuild the in-scope automation, set up SharePoint document management and Outlook integration, and build the repeatable migration tooling against a Salesforce sandbox or full-copy extract.
Run at least one full mock load, reconcile counts and totals per object, execute process test cases, and put the pilot group on the trial environment. Fix what surfaces; repeat the load if mapping changed.
Role-based training, then the cutover window: Salesforce data freeze, delta load, final reconciliation, Salesforce set to read-only, and go-live on Dynamics 365 Sales with hypercare.
Salesforce stays read-only for the agreed window while users work in Dynamics; the final export archive is taken, the decommission checklist is completed, and documentation is handed over. Ending the Salesforce subscription is your call, made safe.
Prerequisites
Who does what
IT Partner
- Inventory and classify the Salesforce org and deliver the migration workbook and fixed quote.
- Design and build the Dynamics 365 Sales target: data model, security, processes, document management, Outlook integration.
- Build and run the migration tooling, execute trial loads and the cutover delta, and reconcile every load with your data owner.
- Rebuild in-scope automation and reports, and test them against cases written from the Salesforce behavior.
- Deliver role-based training and the pilot, and run hypercare through the agreed window.
- Provide the export archive, decommission checklist, and administrator handover.
Your team
- Provide Salesforce and Microsoft access, licensing confirmation, and package and integration owner availability.
- Make the process, mapping, and data-quality decisions the workbook asks for, on the agreed schedule.
- Purchase Dynamics 365 Sales licensing for users in scope and any Dataverse capacity the design calls for.
- Test business-critical scenarios in UAT using your own acceptance criteria, and complete the pilot with real users.
- Send the user communications through your channels on the agreed schedule (we draft, you send), and enforce the Salesforce data freeze at cutover.
- Approve the design, the cutover window, and the Salesforce decommission, and execute the Salesforce contract termination — the commercial exit is yours.
What's not included
Limitations & technical notes
Frequently asked questions
Why do organizations move from Salesforce to Dynamics 365 Sales?
Usually consolidation rather than dissatisfaction. An organization running Microsoft 365 already has Entra ID, Outlook, Teams, SharePoint, Power BI, and Power Automate; Dynamics 365 Sales sits inside that stack with the same sign-in, the same admin center, and native Outlook and Teams integration, so a second platform vendor becomes a cost and an administration surface rather than a capability. The honest question is whether Dynamics 365 Sales covers what Salesforce does for you specifically — and discovery answers it before you commit.
How is the project priced?
By written quote after discovery, because the effort is driven by what is in your org: object count, custom objects, automation and Apex depth, integrations, and how much history you want to carry. Discovery produces the migration workbook — every item classified and sized — and the fixed quote is built from it, in writing, before any build begins. You pay after you approve delivery.
What data can be migrated, and does the history come with it?
Standard objects — Leads, Accounts, Contacts, Opportunities, Products and Price Books, Quotes, Campaigns — activities such as tasks, events, emails, and notes, files, and your custom objects as custom Dataverse tables. History comes with it within Dataverse's rules: original created dates are preserved, owners are re-mapped, activities stay attached to their records, and field-history tracking is migrated as a read-only history table. Last-modified and created-by values cannot be set by an import, so they are carried in reference columns rather than lost.
Do created dates, owners, and activities survive the move?
Yes. Dataverse allows an import to set the original created date through its created-on override, so an opportunity opened in 2021 still shows 2021. Owners are mapped user-by-user to Dynamics 365 users or teams, including departed users mapped to an agreed placeholder. Activities are migrated with their relationships intact and appear on the record timeline. What Dataverse does not allow — setting last-modified or created-by — we carry in reference columns and say so in the workbook.
What happens to our Salesforce automation — Flows, Workflow Rules, Process Builder, Apex?
It is inventoried in full and rebuilt, not copied. Stage-gated processes become business process flows, field logic becomes business rules, and the rest becomes Power Automate flows or Dynamics workflows. Workflow Rules and Process Builder — unsupported by Salesforce since the end of 2025 but often still running — are treated the same way. Apex is assessed class by class: some of it turns out to be configuration in Dynamics, some becomes flows or plug-ins, and some is the signal that your org is really a custom application, which brings us to the next question.
Our org has a lot of Apex and custom Lightning components. Can you still migrate us?
We can assess you honestly, which is the useful answer. A sales org with a few hundred lines of Apex migrates as a CRM. An org whose business runs on thousands of lines of Apex, custom Lightning Web Components, or an Experience Cloud portal is a custom application built on the Salesforce platform, and moving it is an application rebuild — on Power Apps and Power Pages, in phases, or not at all. The discovery report says which case you are in, with options and honest effort, before you spend anything on the move. Sometimes the right outcome is a referral or a decision to stay.
What happens to our reports and dashboards?
They are rebuilt — Salesforce report definitions do not transfer. The agreed core set becomes Dynamics 365 views, charts, and dashboards, which cover most operational reporting; pipeline analytics and anything cross-system go to Power BI, which is where they usually belonged anyway. Discovery lists every report and marks which are used; orgs routinely find that a large share of their Salesforce reports have not been opened in a year.
Where do our files and attachments go?
Into SharePoint, through Dynamics 365 Sales document management, linked to the migrated records so they open from the account or opportunity as before. That choice is deliberate: Dataverse file capacity is a metered, comparatively expensive resource, and SharePoint gives you retention, permissions, and search you already own. Salesforce Files and legacy attachments are both handled; volume is sized in discovery because it drives the timeline.
How does email and Outlook work after the move?
Through the Dynamics 365 App for Outlook and server-side synchronization with Exchange Online — emails, appointments, contacts, and tasks tracked to Dynamics records from the Outlook your users already have, on desktop, web, and mobile. It replaces Salesforce's Outlook integration and Inbox, and because it runs on Exchange Online rather than a plug-in, it tends to be the part of the migration users notice least.
Which Dynamics 365 Sales license do we need?
It depends on what discovery finds. Sales Professional suits straightforward pipelines with light customization, but it caps custom tables and automation; Sales Enterprise removes those caps and is the usual fit for an org migrating from a customized Salesforce; Sales Premium adds Microsoft's advanced sales-intelligence capabilities. We recommend the tier per user group in the target design, verify entitlements against Microsoft's published licensing at that time, and you buy at Microsoft's published prices — our license audit can size the whole Microsoft estate first if you want the complete picture.
Can we run both systems for a while?
Yes, with Salesforce read-only. After cutover, Salesforce stays available for lookup during the agreed coexistence window while everyone works in Dynamics 365 Sales; that is what makes cutover reversible in practice and reassures users that nothing was lost. What a migration does not include is two-way synchronization between live CRMs — if your business genuinely needs both platforms active for an extended period, that is a coexistence integration, which is a different service, and we will tell you which one you need.
We also use Marketing Cloud, Pardot, or Service Cloud. Are those covered?
Not on this page, deliberately. Marketing Cloud and Account Engagement (Pardot) map to Microsoft's marketing products, Service Cloud cases map to Dynamics 365 Customer Service, and CPQ and Experience Cloud have their own counterparts — each is its own project with its own discovery. Folding them into a sales migration is how quotes become fiction. We scope them as parallel engagements with shared discovery where that helps.
How are users trained?
By role, before cutover. Sales users get sessions built around their actual pipeline in the trial environment, managers get forecasting and dashboards, administrators get the environment walkthrough and the mapping workbook. Quick-start guides cover the daily tasks — logging activity from Outlook, moving an opportunity through the process, finding a migrated file. A pilot group works in the trial environment first, and what they trip over gets fixed before everyone else arrives.
Is Dynamics 365 Sales simply better than Salesforce?
That is not a claim we make. Salesforce is a mature platform, and organizations without a Microsoft footprint often have no economic reason to move. The case we do make is narrower and factual: if your organization runs on Microsoft 365, Dynamics 365 Sales lives inside that stack, and consolidating removes a vendor, an identity boundary, and an integration seam. Discovery exists to test whether that holds for your specific org — including telling you if the answer is no.
Who turns Salesforce off, and when?
You do — after the coexistence window, once the decommission checklist is complete: every object migrated or dispositioned, processes live in Dynamics, users working, and the final Salesforce export archive in your hands. Take that export before the subscription ends; Salesforce's post-termination retention is short and on Salesforce's terms. The contract termination is a commercial step between you and Salesforce; our job is to make it boring.