Salesforce to Dynamics 365 Migration: A Real-World Playbook with Challenges and Solutions

A Salesforce to Dynamics 365 migration is a proper project, not a data export. For a mid-size company it typically runs three to nine months and succeeds or fails on four things: data mapping, rebuilding automations, deciding what history to bring, and getting the sales team through the change. Done well, it usually pays for itself through lower licensing and a CRM that finally lives inside the Microsoft tools your team already uses all day.

This playbook walks through a realistic migration end to end: a composite use case built from the patterns we see repeatedly in Spanish and European SMEs, the eight challenges that actually cause trouble, and the solutions that work. If you’re weighing up whether to switch at all, start with our comparison of Dynamics 365 vs Salesforce for Spanish SMEs; this article assumes the decision is made and the question is how.

The Use Case: A 120-Person Distributor with a Renewal Deadline

Meet “IndustrialTech”, a composite of several real migrations: a 120-person industrial equipment distributor in Valencia. Six years on Salesforce, Sales Cloud for the 30-person commercial team, Service Cloud for the support desk. The org is heavily customised with Apex code written by a partner that no longer serves them, and nobody in-house can say which automations still matter.

The trigger is familiar: the renewal quote arrived 18% higher, the company already pays for Microsoft 365, sellers live in Outlook and Teams, and management wants reporting in Power BI instead of buying more Salesforce add-ons. Their Oracle ERP holds orders and invoicing, connected to Salesforce through a fragile middleware sync that breaks quietly every few weeks. The contract renews in nine months, and that date, not any technical milestone, drives the whole plan.

What Maps Cleanly (and What Doesn’t)

The good news first: the core Salesforce objects have direct equivalents in Dynamics 365, because both platforms model sales the same way underneath. The mapping workshop for standard data is measured in days, not weeks.

Salesforce	Dynamics 365 / Microsoft equivalent	Mapping effort
Accounts & Contacts	Accounts & Contacts (Dataverse)	Low
Opportunities & Pipelines	Opportunities & Business Process Flows	Low-medium (stage mapping)
Cases (Service Cloud)	Cases (Customer Service)	Low-medium
Reports & Dashboards	Power BI + Dynamics dashboards	Medium (rebuild, don’t copy)
Files & Attachments	SharePoint document integration	Medium (volume-dependent)
Apex code & Flows	Power Automate, business rules, plugins	High (audit first)
Email & activity history	Exchange/Outlook activities	High (see challenge 3)

The three rows at the bottom of that table are where every Salesforce to Dynamics 365 migration earns its complexity. Let’s take the challenges one by one.

Before diving into the individual challenges, here is the complete implementation picture in one view: everything that leaves Salesforce, the pipeline it travels through, and where each piece lands on the Microsoft side. If you only save one image from this article, make it this one.

Challenge 1: The Data Model Doesn’t Match One-to-One

Salesforce record types, custom objects, and six years of field sprawl never map perfectly onto Dataverse tables. IndustrialTech had 240 custom fields on the Opportunity alone; an audit showed sellers actively used fewer than 60. Opportunity stages were also inconsistent, three record types with different stage sets, each reported differently.

Solution: treat the migration as a spring clean, not a removal van. Run a field-usage report in Salesforce, migrate only fields with real data and real users, and define one clean opportunity process in Dynamics 365 with stage-gate criteria agreed by the sales director. Then do a trial migration into a sandbox, twice. The first trial finds the mapping errors; the second proves you fixed them. Our guide to CRM data migration into Dynamics 365 covers the mechanics of staging, deduplication, and validation in more depth.

Challenge 2: Apex Code Nobody Understands Anymore

Custom Apex is the hidden anchor of most long-running Salesforce orgs. IndustrialTech had 47 automations: triggers, scheduled jobs, validation rules, and flows. The partner who wrote them was gone, and documentation consisted of the code itself.

Solution: audit before you rebuild. In practice roughly 40% of aged automations turn out to be dead, supporting processes that no longer exist. Of IndustrialTech’s 47, only 19 survived the audit. Those were rebuilt on the Microsoft side: simple field logic became business rules, approval chains and notifications became Power Automate flows, and two genuinely complex pricing calculations became small plugins. Rebuilding less is the win: every automation you don’t carry over is one you never maintain again.

Challenge 3: Email and Activity History Is Harder Than Anyone Expects

Here’s the trap that catches teams late in the project: if the company used Einstein Activity Capture, much of the email and event history isn’t stored in Salesforce’s database at all and cannot be fully exported. Sales teams discover this during validation and suddenly the project has a trust problem.

Solution: set expectations in week one, not week twenty. Classify activity data honestly: emails logged as records migrate; Einstein-captured history largely doesn’t. IndustrialTech migrated two years of logged activities and notes, archived a read-only Salesforce data export for compliance, and relied on a simple truth, the actual emails still live in Exchange mailboxes, and once Dynamics 365 connects to Outlook, correspondence with every account is a click away anyway. Nobody missed the old activity feed after the first month.

Challenge 4: Files, Attachments, and Storage Costs

Six years of quotes, signed contracts, and photos added up to 180 GB in Salesforce Files. Migrating that volume into Dataverse storage would be expensive; leaving it behind was unacceptable to the service team.

Solution: Dynamics 365’s native SharePoint integration. Documents live in SharePoint, where storage is a fraction of the cost and files get versioning and co-authoring, while remaining visible on the account, opportunity, and case records they belong to. IndustrialTech’s files were migrated folder-per-account with a mapping script, and the service team gained full-text search across every historic document, something they’d never had.

Challenge 5: Integrations Have to Be Re-Pointed

The CRM is never alone. IndustrialTech’s Salesforce talked to the company’s Oracle ERP (orders and invoice status), the website’s quote-request forms, and a newsletter tool. Each connection was built years apart, by different people, with different levels of documentation.

Solution: inventory every integration in week one and classify it: rebuild, replace, or retire. The Oracle sync was rebuilt on standard Dataverse connectors with proper error alerts, replacing the fragile middleware that used to fail silently. Web forms were re-pointed to create leads in Dynamics 365 directly, and the newsletter tool was replaced by native Customer Insights journeys. Oracle stayed exactly where it was: a CRM migration doesn’t require touching the ERP. If the ERP itself ever comes up for review, moving to Business Central would make the whole stack native to one platform, but that’s a separate decision, on a separate timeline.

Challenge 6: 200 Reports Nobody Wants to Rebuild

Salesforce orgs accumulate reports the way drawers accumulate cables. IndustrialTech had over 200; the management team could name eleven they actually looked at.

Solution: rationalise, don’t replicate. The eleven real reports became three Power BI reports and a set of in-app Dynamics dashboards for daily pipeline work. Because Power BI reads Dataverse directly, the reporting layer also became the place where CRM and ERP numbers finally sat side by side, the single view of customer and revenue the company had wanted for years.

Challenge 7: The Sales Team Didn’t Ask for This

Technology migrates in weekends; habits don’t. Sellers had years of muscle memory in Salesforce, and the fastest way to sink the project would have been a surprise cutover with a training PDF.

Solution: IndustrialTech ran a four-week parallel period for a pilot group of eight sellers and four service agents, real work, both systems, gripes collected daily. Training was in Spanish, role-based, and short: three 90-minute sessions beat one full-day marathon. The pilot group’s fixes (renamed fields, a simplified quote form, one restored automation) made them advocates rather than critics by go-live. The practical wins helped too: creating a contact from Outlook, updating a deal from the phone app between customer visits, and Copilot drafting follow-up emails, the kind of daily-friction improvements we describe in our post on the Dynamics 365 CRM features that boost sales performance.

Challenge 8: GDPR Can’t Be an Afterthought

Migrating personal data is processing under GDPR, and six-year-old CRM data always contains records with no remaining lawful basis, former prospects who never consented to anything beyond a cold call in 2020.

Solution: make the migration the retention-policy moment. IndustrialTech purged contacts with no activity in three years and no consent record, mapped consent fields explicitly into Dynamics 365, and documented the whole exercise, turning a compliance risk into evidence of good practice. As a bonus, the move improved their data-residency position: Microsoft’s EU Data Boundary keeps customer data processed within the EU, an easier conversation with auditors than explaining transatlantic transfers.

The Nine-Month Plan, Phase by Phase

1. Months 1-2: Assess and map. Field usage audit, automation audit, integration inventory, GDPR review, and the field-mapping workshop. Output: a migration scope document everyone signs.
2. Months 3-4: Build and first trial. Configure Dynamics 365 Sales and Customer Service, rebuild the 19 surviving automations, first trial data migration into a sandbox.
3. Month 5: Second trial and validation. Fix mappings, re-run, and have real users validate their own accounts and pipelines against Salesforce.
4. Months 6-7: Pilot and parallel run. Twelve users work in both systems; integrations run live against the ERP in test mode; reports signed off.
5. Month 8: Cutover. Final delta migration over a weekend, Salesforce switched to read-only, go/no-go checklist executed. Everyone starts Monday in Dynamics 365.
6. Month 9: Hypercare and exit. Daily issue triage tapering to weekly, Salesforce data archive exported, licences cancelled before renewal. Deadline met with a month to spare.

Two rules made the timeline hold. First, the renewal date was treated as immovable, so scope flexed instead of the deadline, nice-to-have automations moved to a post-go-live backlog. Second, no phase started until the previous one’s exit criteria were met, which is exactly the discipline you should demand when choosing a Dynamics 365 partner to run a migration like this.

What Changed for IndustrialTech

Six months after go-live the picture looked like this: CRM licensing costs down by roughly a third against the renewal quote, one reporting layer instead of three, service agents finding any historic document by search instead of asking colleagues, and an ERP sync that alerts someone when it fails instead of failing quietly. The less measurable change mattered as much, sellers stopped treating the CRM as a separate place to “do admin” because it now lived inside Outlook and Teams, where they already were.

None of this is automatic. The same project without the audits, the trial migrations, or the parallel run produces the opposite story. The difference between the two outcomes is planning, not product.

Six Mistakes That Sink a Salesforce to Dynamics 365 Migration

Reading about IndustrialTech’s project makes it sound orderly, and a well-run migration is. The messy ones share a small set of avoidable mistakes, and we see the same six again and again:

• Migrating everything “just in case”. Every unused field, dead automation, and stale contact you carry over costs mapping time now and maintenance forever. The delete key is the cheapest tool in the project.
• Skipping the second trial migration. One trial proves the script runs; only the second proves the fixes worked. Teams that cut over after a single trial spend hypercare firefighting data issues in front of their users.
• Discovering the activity-history limits late. Check whether Einstein Activity Capture is on in week one. It changes what you can promise the sales team, and promises are hard to walk back.
• Rebuilding Salesforce inside Dynamics 365. Recreating every screen and process one-to-one imports the old system’s clutter into the new one. Configure for how the team should work now, not how the old tool made them work.
• Leaving licensing to the end. Overlapping contracts are a real cost. Confirm your Salesforce renewal and notice-period dates before you plan anything else, and time the cutover to land comfortably before them.
• Treating go-live as the finish line. Adoption is won in the eight weeks after cutover: the hypercare backlog, the quick fixes, the second round of training. Budget for that period or watch usage quietly slide back into spreadsheets.

None of these are technology problems. That’s the quiet truth of a Salesforce to Dynamics 365 migration: the platforms are mature and the tooling is proven, so the risk lives almost entirely in scoping, sequencing, and people.

Frequently Asked Questions

How long does a Salesforce to Dynamics 365 migration take?

For an SME with moderate customisation, three to six months is typical; heavy Apex customisation, large file volumes, or multiple integrations push it toward nine. The renewal date of your Salesforce contract usually sets the deadline, start at least six months before it, and earlier if Einstein Activity Capture or complex integrations are involved.

What does a migration like this cost?

As of 2026, SME projects of IndustrialTech’s shape typically land between €25,000 and €80,000 in services depending on automation count, data volume, and integrations, alongside Dynamics 365 licensing that generally undercuts equivalent Salesforce editions. For the licence-side numbers, see our breakdown of Dynamics 365 implementation costs in Spain.

Do we lose our history?

Core records, accounts, contacts, opportunities, cases, notes, logged activities, migrate fully. The honest exceptions: Einstein Activity Capture history can’t be completely exported, and very old data is often better archived than migrated. A read-only export archive covers compliance for anything you leave behind.

Can we run Salesforce and Dynamics 365 in parallel?

Yes, and for a pilot group you should, four to six weeks of parallel running surfaces mapping errors and workflow gaps while Salesforce is still there as a safety net. Company-wide parallel running, though, is a trap: double data entry breeds resentment and inconsistent data. Pilot in parallel, then cut over decisively.

Where to Go from Here

If a Salesforce to Dynamics 365 migration is on your horizon, start with the two audits you can run this week: the field-usage report and the automation inventory. They’ll tell you more about your project’s real size than any generic estimate. AlishBit plans and runs these migrations for businesses across Spain and Europe, including the awkward parts like Apex rework and activity history, through our Dynamics 365 CRM services.