Salesforce to Dynamics 365 Migration: A Step-by-Step Checklist

Switching CRMs is one of the more intimidating projects a business can take on — and switching from Salesforce, where years of data, customisation, and habit have accumulated, feels especially daunting. But thousands of businesses make the move to Dynamics 365 every year, usually for sound reasons, and with a clear process it is far less risky than it appears. This is a practical, step-by-step checklist for migrating from Salesforce to Dynamics 365 without losing data, momentum, or your team’s sanity.

Why Businesses Move from Salesforce to Dynamics 365

People rarely switch CRMs on a whim — it is usually driven by a few recurring frustrations. Cost is the big one: Salesforce’s per-user pricing and add-on model can climb steeply, and Dynamics 365 often delivers comparable capability for noticeably less. Integration is another: businesses living in Microsoft 365, Outlook, and Teams want a CRM that is part of that world rather than bolted alongside it. Some want CRM and ERP on one platform, which Dynamics offers natively. We cover the full comparison in our guide on Dynamics 365 vs Salesforce; here we focus on how to actually make the move.

The Step-by-Step Migration Checklist

Phase 1: Audit and plan. Before touching anything, document your current Salesforce setup — every object, custom field, workflow, integration, and report you actually use. Most orgs have accumulated plenty that nobody uses; migration is the perfect moment to leave the junk behind. Define what success looks like and set a realistic timeline.

Phase 2: Map data and logic. Map every Salesforce object to its Dynamics 365 equivalent (Accounts, Contacts, Opportunities all have natural homes in Dataverse), field by field. Plan how Salesforce automations — Apex, Flows, validation rules — will be rebuilt using Power Automate and Dynamics’s native tools. This mapping document is the backbone of the whole project.

Phase 3: Build and configure Dynamics 365. Set up Dynamics to match your mapped design — entities, fields, security roles, forms, and the rebuilt automations. Configure it around how your team actually works, not the out-of-the-box defaults, because configuration is where adoption is won or lost.

Phase 4: Migrate the data — in rehearsals. Never migrate live data once and hope. Run trial migrations into a sandbox, cleaning and deduplicating as you go. Reconcile record counts between source and target so nothing is silently lost. Repeat until the migration runs clean and your team has validated the results.

Phase 5: Test thoroughly. Have real users work through real scenarios in the new system — create a lead, build a quote, run a report — and fix what breaks before go-live, not after. This is your safety net.

Phase 6: Cutover and train. Do a final delta migration to catch everything changed since the last trial, switch over (often a weekend), set Salesforce to read-only as a safety archive, and train your team by role. Then support them closely through the first weeks.

Common Migration Pitfalls to Avoid

Most migration horror stories trace back to the same handful of mistakes. Migrating everything. Hauling years of dead leads, duplicate accounts, and obsolete fields into the new system just relocates the mess — decide what is worth bringing and leave the rest behind. Skipping the trial runs. The single biggest risk-reducer is rehearsing the migration into a sandbox several times; teams that migrate live once, with no rehearsal, are the ones that discover problems too late. Forgetting the automations. Data is the easy part; the Apex triggers, Flows, and validation rules that ran your Salesforce processes need thoughtful rebuilding in Dynamics, or your team inherits a CRM that holds their data but does not do their work. No reconciliation. Always compare record counts and key fields between source and target so you can prove nothing was silently dropped. Underestimating training. A perfectly migrated system that nobody knows how to use is still a failed migration. Avoid these five and you have avoided the vast majority of migration pain.

How Long Does It Take, and What Does It Cost?

Timelines and budgets vary with the complexity of your Salesforce org, but there are useful benchmarks. A straightforward migration — standard objects, modest customisation, clean-ish data — typically runs four to eight weeks. A complex org with heavy customisation, many integrations, and large data volumes can take two to four months. Cost follows the same logic, generally landing somewhere from the low tens of thousands for a standard move to considerably more for an enterprise org with extensive rebuilding. The cost-saving twist most businesses miss is that the migration usually pays for itself: many are switching precisely because Salesforce’s ongoing licence costs were climbing, so the lower Dynamics 365 running costs often recover the one-time migration investment within the first year or so. Viewed over three years, the move is frequently cheaper, not more expensive.

Helping Your Team Make the Switch

The technical migration is only half the battle — the other half is human. Your team has years of muscle memory in Salesforce, and even a flawless migration can stumble if people resist the change. The businesses that switch smoothly treat adoption as seriously as data. Involve a few respected users early, so they help shape the new setup and become its champions rather than its critics. Train by role on the tasks people actually do, not a generic tour of every feature. Be honest that the first week or two will feel slower as everyone learns — and resource extra support for exactly that window. Crucially, configure Dynamics 365 to be at least as easy as Salesforce was for the daily tasks reps care about; if logging a deal becomes harder, adoption suffers no matter how good the migration was. The same principles that determine whether any CRM project succeeds apply here, which is why it is worth reading our piece on why CRM implementations fail before you start — the failure patterns it describes are exactly the ones a migration must avoid.

What to Do With Your Salesforce Data and History

A common worry is losing the history built up in Salesforce — the closed deals, the activity logs, the years of customer interactions. You do not have to. The right approach migrates the data that remains genuinely useful (open opportunities, active accounts, recent history) into Dynamics 365 where the team works with it daily, while keeping a complete archive of everything for reference and compliance. Setting the old Salesforce org to read-only for a transition period gives everyone a safety net — if anyone needs an old record that was not migrated, it is still there. Over time, as confidence in the new system grows and the archived data ages out of relevance, the Salesforce subscription can be retired entirely, ending its cost. The key point is that “migrating” does not mean “abandoning” — it means moving what matters and safely retaining the rest, so you keep your institutional memory without paying indefinitely for a system you no longer use.

Do You Need a Partner, or Can You DIY It?

It is fair to ask whether you can run a migration in-house. For a very small, simple Salesforce org with little customisation and a technically capable team, a careful DIY migration is possible. But the moment you have meaningful customisation, integrations, large data volumes, or business-critical processes riding on the CRM, the risk calculus shifts hard toward using an experienced partner. The reason is not the data movement itself — it is the hundred small decisions around it: how to rebuild a complex automation, how to handle a field with no clean equivalent, how to reconcile records that do not match, how to sequence the cutover with minimal disruption. These are exactly the places where inexperience turns a manageable project into a costly one, and where someone who has done it many times moves quickly and avoids the traps. A botched migration that loses data or breaks processes costs far more to fix than doing it right the first time, which is why even technically strong teams often bring in help for the migration specifically, then take the running of the system back in-house afterward.

The Bottom Line

A Salesforce to Dynamics 365 migration is a serious project, but it is a well-trodden, predictable one when approached in phases: audit and plan, map data and logic, build and configure, migrate through rehearsals, test thoroughly, then cut over and train. The fear most businesses feel — losing data, breaking processes, disrupting the team — is almost entirely a function of skipping the rehearsal and testing phases. Do those properly and the move is far smoother than the anxiety suggests, with your history intact and your team productive from day one.

The difference between a clean migration and a painful one is almost always the process and the partner running it. Our Dynamics 365 migration services follow exactly this checklist — trial runs, reconciliation, weekend cutover, and proper training — so nothing is lost and your team barely skips a beat. Book a free migration assessment and we will map your Salesforce org and quote a fixed price.