You’ve decided to move from Salesforce to Dynamics 365. The business case is solid. The budget is approved. Then you look at your actual Salesforce setup, five years of customisation, bespoke validation logic, dozens of custom fields and workflows, and reality hits.
Not everything translates cleanly. Some custom logic has no direct equivalent in Dynamics 365. Some data structures that made sense in Salesforce become awkward in Dynamics 365. And some things that work fine in testing fail when you’re live and the business is pushing data through at real volume.
This guide covers what actually breaks during a Salesforce to Dynamics 365 migration, why it breaks, and what you need to plan for before you start.
What Usually Migrates Cleanly
Start with what’s straightforward. Most standard Salesforce functionality maps reasonably well to Dynamics 365:
- Standard objects and fields. Accounts, Contacts, Opportunities, standard fields on those objects. These move across with minimal friction. Field types mostly translate: text to text, picklists to option sets, lookups to lookups.
- Workflow logic that’s simple. A workflow that updates a field based on a condition, sends an email notification, or creates a record when something happens. That usually becomes a Power Automate flow with minimal redesign.
- Basic validation rules. “This field is required when status equals X” becomes business rules in Dynamics 365 with straightforward configuration.
- Simple custom fields. If you’ve added a dozen fields to Track custom data, they move across as new columns in Dynamics 365 tables.
- Standard reports and dashboards. While the UI is different, the underlying logic (filter, group, aggregate) translates to Power BI or Dynamics 365 native reports.
The migration complexity comes from what sits beyond the standard platform.
Where Things Break: Apex Logic
Salesforce Apex is a proper programming language. Dynamics 365 has no direct equivalent. That’s the single biggest source of surprises in migrations.
Custom Apex typically falls into a few categories:
Apex with no clean equivalent
Some Apex logic has no direct translation. Common examples:
- Complex algorithmic processing. If your Apex does heavy computation (calculating commissions with multi-tier logic, running complex forecasting algorithms, or processing data through a series of rules that depend on external APIs), that usually needs custom code in Dynamics 365 too. You can’t avoid the complexity; you can only move it.
- Batch jobs that reshape data. Salesforce Apex batch jobs often run nightly to recalculate fields, consolidate data or clean up old records. Dynamics 365 can do similar things through Power Automate and plugins, but the patterns are different. Your batch job logic often needs redesign rather than translation.
- Callouts to external systems with complex orchestration. If your Apex calls external APIs and orchestrates responses across multiple Salesforce objects based on the results, that logic is usually complex enough to need rebuilding rather than copying.
Apex that CAN migrate but needs rebuilding
Some Apex does things that Dynamics 365 can do, but the implementation path is different:
- Triggers that update related records. A Salesforce trigger that fires when an Opportunity closes and updates Account fields is common. Dynamics 365 can do this through plugins or Power Automate flows, but the structure is different. Your trigger code doesn’t port; you rebuild the logic in the new platform.
- Validation logic embedded in Apex. If you’ve written Apex to validate data across multiple objects or enforce complex rules, Dynamics 365 business rules and plugins can replace it. But the code doesn’t translate. You’re rewriting the logic.
- Complex field calculations. Salesforce Apex often calculates derived fields (totals, averages, flags based on related records). Dynamics 365 can do rollup fields, calculated columns and Power Automate automations for similar outcomes. But again, you’re translating intent, not copying code.
Apex that’s straightforward to replace
Some Apex is simple enough that the migration is genuinely low-friction:
- Basic CRUD operations. Apex that creates, reads, updates or deletes records in a straightforward way becomes a plugin or Power Automate flow with minimal friction.
- Simple notifications. Apex that sends emails or posts to Chatter becomes Power Automate actions.
- Straightforward calculations. If your Apex calculates a single derived value from a few fields, a calculated column or a simple plugin usually replaces it without much complexity.
The challenge is that you won’t know which category your custom Apex falls into until someone actually reviews it. That’s a common surprise point in migrations: “We thought we had fifty custom Apex classes, but only ten of them need rebuilding. The other forty do things we can replace with configuration or simple flows.” Or the opposite: “Three Apex classes handle business-critical logic that’s way more complex than we realised.”
Data Mapping and Custom Objects
Standard object migration is straightforward. Custom objects are where things get awkward.
Custom object structures that don’t map cleanly
Salesforce lets you create custom objects with relationships: many-to-many through junction objects, hierarchical relationships, or master-detail relationships where the child record can’t exist without the parent.
Dynamics 365 tables work similarly, but the details matter:
- Master-detail relationships in Salesforce become different in Dynamics 365. In Salesforce, a master-detail relationship means the child record is tightly coupled to the parent. Delete the parent, the children are automatically deleted. Dynamics 365 supports this through parental relationships, but the cascade behaviour is configured differently and the UI works differently. Developers who have relied on the specific cascade behaviour of Salesforce master-detail relationships sometimes hit surprises.
- Many-to-many relationships. Salesforce junction objects are common. “Projects” and “Team Members” with a junction object to track who’s on which project. Dynamics 365 supports this through many-to-many relationships, but the data structure under the hood is different, and custom logic that relied on the junction object working a certain way often needs adjustment.
- Lookup density. Some Salesforce orgs have complex webs of lookups. Records linked to five or six other objects. That’s technically possible in Dynamics 365, but it gets unwieldy. The performance characteristics are different, and the user experience of navigating those relationships changes.
Custom fields that don’t translate
Most custom field types translate: text, numbers, dates, picklists, checkboxes. Some don’t:
- Formula fields. Salesforce formula fields are read-only calculated fields. Dynamics 365 has calculated columns, but the formula language is different. Simple formulas translate; complex ones often don’t. You usually rewrite them, sometimes as plugins or Power Automate flows if the formula is complex.
- Roll-up summary fields. Salesforce roll-up fields aggregate data from child records (sum quantities, count related records, find the max date). Dynamics 365 has rollup columns, but they work differently. The calculation triggers are different, and the performance implications are different.
- Encrypted fields. If you’ve encrypted sensitive fields in Salesforce, Dynamics 365 has its own encryption approach. The encrypted data doesn’t migrate cleanly; you usually decrypt it in Salesforce, migrate it, and re-encrypt it in Dynamics 365.
Validation rules that need rebuilding
Salesforce validation rules prevent saves based on conditions. “Opportunity can’t be closed without a close date.” “If account type is ‘Partner’, the account must have a partner level field filled.”
Dynamics 365 has business rules that do similar things. But:
- Validation rules that check related data. If your rule checks a field on the parent Account when you’re saving an Opportunity, that rule crosses a relationship boundary. Dynamics 365 business rules can do this, but the syntax is different and the performance implications are different (cross-table validations can be slower).
- Complex multi-condition rules. Salesforce lets you stack conditions in a single validation rule. Dynamics 365 business rules are simpler, and complex logic often needs multiple rules or a plugin to replicate.
- Error messages. Salesforce validation error messages are simple text. Dynamics 365 business rule error messages are also straightforward, but the way they’re presented to the user is different. Some users find Dynamics 365 error handling less obvious than Salesforce’s.
What Breaks in Practice: The Real Migration Gotchas
These aren’t technical impossibilities. They’re the places where migrations hit friction, timeline slips, or rework.
Data quality reveals itself mid-migration
You don’t usually know your data is dirty until you try to migrate it. Common discoveries:
- Inconsistent lookup values. A lookup field in Salesforce that should only point to active records is pointing to inactive ones. When you migrate, do you keep the invalid lookups (and break referential integrity in Dynamics 365), or do you fix them (and risk losing historical relationships)?
- Unpopulated required fields. In Salesforce, you marked a field as required, but there are records with that field blank. Usually because the requirement was added after data already existed. In Dynamics 365, those records can’t be created with a blank required field. You need a data cleanup before you go live.
- Denormalised data. Salesforce lets you store the same information in multiple places. You’ve got an Account name field on the Account and also on the related Opportunity for historical tracking. Dynamics 365 would typically use a single source of truth. Do you keep the denormalisation (and manage consistency going forward), or normalise it (and potentially lose historical context)?
Custom logic runs into governor limits
Salesforce has governor limits: hard caps on how many database queries, how many records you can update, how much CPU you can use in a transaction. Apex code that works fine in testing sometimes hits those limits under real load.
Dynamics 365 also has limits, but they’re different. A plugin that worked in your sandbox might timeout in production when real volume runs through it. Or it might work fine but run so slowly that it stalls the user interface.
The gotcha is that you don’t always discover this until you’re live.
Scheduled jobs don’t map one-to-one
Salesforce scheduled Apex jobs run on a schedule. “Every night at 2am, run this job to recalculate forecasts.”
Dynamics 365 uses Power Automate cloud flows or plugins for similar work. The execution model is different. A scheduled job that takes 15 minutes in Salesforce might take an hour in Dynamics 365 if it’s implemented as a flow (because flows are less efficient for bulk processing). Or it might run fine but cost more in API calls, which affects your licensing.
Integrations need rebuilding
If your Salesforce setup is integrated with other systems (your ERP, your accounting platform, a custom application), those integrations usually need rebuilding for Dynamics 365.
The gotcha is that you often discover integration logic that nobody documented. “We have a nightly sync with the ERP that pulls updated pricing. Nobody remembers who built it, but it’s critical.” That integration needs rebuilding, and if the original developer isn’t around, there’s detective work involved.
User adoption hits expectations about the UI
Salesforce and Dynamics 365 have different user interfaces. Features that were one click in Salesforce might be three clicks in Dynamics 365, or might be in a different place. Users trained on Salesforce sometimes struggle with the Dynamics 365 navigation, even though the underlying capability is the same.
This isn’t a technical blocker, but it’s a real source of “the migration is done, but adoption is slower than we expected” problems.
Realistic Migration Approach
Given these gotchas, what actually works?
Audit your Apex before you commit. Spend a week reviewing what custom code you have. Categorise it: “This is simple and rebuilds easily.” “This is complex and needs careful planning.” “This is critical and risky.” That costs time upfront but saves surprises later.
Plan for data cleanup. Don’t assume your Salesforce data is clean. Budget time to audit it, decide what to keep and what to fix, and validate the migration data before you go live.
Don’t assume validation rules can be complex. Salesforce validation rules can be intricate; Dynamics 365 business rules are simpler. Expect to rebuild some validation logic as plugins if it’s complex.
Test integrations early. If you have integrations, rebuild them early and test them thoroughly. Don’t leave integration testing until the last week.
Plan for custom logic rebuilding. Even straightforward custom Apex usually needs rebuilding, not copying. Budget time for that. Don’t assume you can migrate it as-is.
Accept that the user experience will be different. The migration is successful when the same business process works in Dynamics 365. It might work differently than in Salesforce, and that’s okay. Users adapt, but they need training and patience.
Your Next Step
If you’re planning a Salesforce to Dynamics 365 migration, the first conversation should focus on your custom logic. What Apex do you have? What validation rules? What integrations? Once you know what you’re dealing with, migration planning becomes a matter of categorising the work, not discovering surprises mid-project.
Book a discovery call to audit your Salesforce setup and plan a realistic migration approach, or explore how Dynamics 365 compares to Salesforce to understand the broader strategic context.
