Moving your CRM is never just a data export and import. Here's what actually needs to happen - and how to get there without writing a migration script from scratch.
In short: Migrating from Salesforce to Dynamics 365 means more than moving records across. It means re-mapping objects (accounts, contacts, opportunities, and custom objects) to their Dynamics equivalents (accounts, contacts, opportunities, and entities), rebuilding automation that lived in Salesforce workflows or Apex, and deciding whether the move happens in one cutover or in a phased run where both systems operate side by side for a period. Many organisations never fully retire one system - they end up running Salesforce and Dynamics 365 permanently in parallel after a merger or acquisition, which makes ongoing, bidirectional sync between the two platforms just as important as the one-time migration itself. An iPaaS like CONVAYR handles both the initial data move and the long-term sync without custom integration code.
Nobody migrates CRMs for fun. By the time "Salesforce to Dynamics 365" becomes a live project, it's usually one of a few specific triggers: an acquisition where the acquiring company standardises on Dynamics, a Microsoft enterprise agreement that makes Dynamics effectively bundled and Salesforce's renewal suddenly looks expensive by comparison, or a parent company consolidating subsidiaries onto one CRM after years of each running its own.
What's rarely true is a clean, single-day cutover. Sales teams can't stop selling while records move. Support can't lose ticket history. Finance needs opportunity and revenue data to reconcile across the transition. So the real question usually isn't "how do we migrate" - it's "how do we migrate without a six-month freeze on one of the two systems," and often, "how long do we actually need to keep both running, and what has to stay in sync while we do."
Salesforce and Dynamics 365 cover the same ground - accounts, contacts, leads, opportunities, activities - but they don't model it identically, and the gaps are where migrations go wrong.
Accounts and contacts map reasonably cleanly, but field-level differences add up: Salesforce's record types versus Dynamics's business process flows, different default field sets, and custom fields that exist in one org with no equivalent in the other until someone creates it.
Opportunities and the sales pipeline are the highest-risk area. Salesforce opportunity stages and Dynamics 365 sales process stages are rarely a one-to-one match, and if stage definitions aren't reconciled before the first sync, forecasting breaks immediately - deals appear "stuck" in stages that don't mean what they used to, or skip stages that didn't exist on the other side.
Custom objects and entities are the long tail of the project. Every org has a handful of custom objects built for a specific internal process, and each one needs a decision: rebuild as a custom entity in Dynamics, fold into a standard entity, or retire if nobody actually uses it anymore.
Automation and workflow logic doesn't migrate at all - it has to be rebuilt. Salesforce flows, process builder rules, and Apex triggers have no direct Dynamics equivalent; the underlying business logic needs to be re-implemented in Power Automate or in whatever's orchestrating the sync.
Activity history and attachments are often the most underestimated part of the scope. Years of emails, call logs, notes, and file attachments need a plan - not every migration approach preserves them with full fidelity, and "we'll deal with historical data later" tends to become "we never migrated it."
There are really two different projects hiding under one question, and it's worth being explicit about which one an organisation is actually doing.
A full cutover treats Dynamics as the destination and Salesforce as a source to be retired. Data moves once (or in a short series of batches), automation gets rebuilt in Dynamics, and Salesforce is eventually switched off. This is the simpler end state, but it demands getting the mapping and automation rebuild right before go-live, because there's no "keep both updated" safety net once Salesforce is turned off.
Running both in parallel is the more common reality for organisations that grew through acquisition - a business unit on Salesforce, another on Dynamics, neither migrating any time soon. Here the goal isn't a one-time move at all; it's continuous, bidirectional sync so that an account created in one system shows up in the other, opportunity updates flow both ways, and sales and support teams on either platform are working from the same picture. Deduplication matters enormously in this scenario, since the same account or contact can easily exist in both systems independently.
The tooling decision depends heavily on which of these two an organisation is actually solving for - and many projects start as a "temporary" parallel run that quietly becomes permanent, which is worth planning for rather than discovering.
A one-time CSV export and import can work for a small, simple org with few custom objects and no ongoing sync requirement. For most real migrations, it falls short in a few predictable ways.
Native marketplace apps built for this kind of migration tend to help with the data move itself but leave the ongoing sync problem unsolved - fine for a clean cutover, less useful if any part of the organisation ends up running both systems for longer than planned. Generalist automation and workflow tools can move individual records between systems on trigger, but weren't built for bulk historical migration, complex field mapping across custom objects, or the deduplication logic that parallel-running CRMs need. And a hand-built script solves the problem as scoped on day one, but every schema change on either side afterwards becomes a maintenance request to whoever wrote it - which doesn't scale well if the parallel run lasts longer than expected.
| Native marketplace migration tools | Generalist automation/workflow tools | iPaaS (e.g. CONVAYR) | |
|---|---|---|---|
| Bulk historical data migration | Yes, built for this | Limited - built for ongoing triggers, not bulk moves | Yes |
| Custom object/entity field mapping | Basic | Manual, per-field | Visual, built-in |
| Ongoing bidirectional sync after migration | Not the focus | Possible but fragile at scale | Core capability |
| Deduplication across both systems | Minimal | Build-your-own | Built-in matching logic |
| Maintains itself through schema changes | Varies | No | Yes |
CONVAYR connects to both Salesforce and Dynamics 365 and handles the parts of this project that are easy to underestimate: mapping custom objects to custom entities without writing transformation code, running the historical data migration in controlled batches rather than a single risky cutover, and - for organisations that end up running both CRMs long-term - keeping accounts, contacts, and opportunities in sync bidirectionally with deduplication logic that prevents the same customer existing as two disconnected records. Automation logic that lived in Salesforce workflows can be rebuilt as sync rules in CONVAYR rather than requiring a parallel rebuild effort in Power Automate on day one, and the same connection that handled the initial migration keeps running afterwards if a parallel period turns out to be permanent.
Q: How long does a Salesforce to Dynamics 365 migration usually take?
It depends almost entirely on the number of custom objects and the amount of automation that needs rebuilding, not on record volume. A straightforward org with mostly standard objects can move in a matter of weeks; one with years of custom objects, Apex triggers, and integrations can take several months, particularly if activity history and attachments are in scope.
Q: Can we migrate in phases instead of one cutover?
Yes, and for most organisations this is the lower-risk approach - migrate by business unit, by object type, or by region, keeping both systems in sync for the records that haven't moved yet so nothing falls through the cracks mid-migration.
Q: What happens to Salesforce automation (flows, Apex) during the move?
It doesn't transfer automatically. Each flow or trigger needs to be reviewed and rebuilt, either natively in Dynamics 365/Power Automate or as a sync rule in the integration layer handling the migration, depending on where the logic makes more sense to live long-term.
Q: Do we need to keep both Salesforce and Dynamics 365 running after migration?
Often, yes, at least temporarily - sales teams need a transition window, and acquired business units frequently keep their original CRM for longer than the integration project originally planned. Building the sync to handle this from the start avoids a second project later.
Q: Is it possible to avoid data loss on activity history and attachments?
It's possible, but it has to be planned for explicitly rather than assumed. Activity history and attachments are frequently the part of a migration scope that gets cut when timelines slip, so confirming up front whether they're in scope - and testing that they actually transfer with fidelity - is worth doing early rather than discovering gaps after Salesforce is decommissioned.
Planning a migration or running both CRMs? Start with a 30-day free trial of CONVAYR to explore the capabilities risk-free.