Salesforce migration often starts with a simple question. How do we move the records? For enterprise teams considering Microsoft Dynamics 365 Customer Engagement (CE/CRM), another decision comes first. Which records and processes should move at all?
Years in Salesforce often leave duplicate contacts, unused fields, and old custom objects. Some automation also exists only because of constraints in the original platform. Copying those elements into Dynamics 365 CE/CRM brings their maintenance burden along.
At New Dynamic, we treat the period before detailed mapping as a simplification window. Teams often discover that a field, automation, or integration everyone assumed was required is really supporting an old report, exception, or workaround.
Clean first. Migrate second. Moving technical debt efficiently still leaves technical debt in the target environment.
Salesforce Migration Should Start Before Data Moves
Microsoft’s Dynamics 365 CE/CRM covers data ownership, architecture, quality controls, testing, and cutover planning. Dynamics 365 Activate, currently in preview, can inspect Salesforce objects and their dependencies. That includes relationships, automation, and custom code that may need review.
That visibility helps teams understand the source environment, but the migration team still has to decide what belongs in the future one. Microsoft Learn’s explains the migration stages, while New Dynamic’s looks more closely at those design decisions.
What Should You Audit Before a Salesforce to Dynamics 365 CE/CRM Migration
An audit should go beyond simple record counts. Each part of the existing Salesforce environment should be evaluated against the business process the organization wants to operate in Microsoft Dynamics 365 Customer Engagement.
Audit Area |
What to Review |
Migration Decisions |
| Data quality and record hygiene | Duplicates, stale records, missing values, inactive accounts, ownership | Clean, consolidate, archive, or migrate |
| Custom fields and objects | Usage, dependencies, reporting value, original business requirement | Map, simplify, redesign, or retire |
| Workflows and automation | Current process, exceptions, approvals, hidden manual steps | Rebuild natively, redesign, or remove |
| Integrations | Direction of data, dependencies, ownership, error handling | Reconnect, replace, consolidate, or retire |
| Security and ownership | Users, access patterns, record ownership, business boundaries | Redesign for the Dynamics 365 CE/CRM security model |
| Historical data | Closed records, activities, old leads, audit history, attachments, retention requirements | Migrate, archive, retain elsewhere, or retire |
| Reporting | KPI definitions, source fields, legacy reports, spreadsheets | Preserve the business measure, not necessarily the old report |
Before detailed mapping begins, each major area should have a clear disposition: migrate, clean, consolidate, redesign, archive, or retire.
Clean the Data Based on Future Use
Data cleanup gets difficult when technical facts collide with business history. Duplicate contacts are straightforward. Seven years of dormant leads or an unused field with reporting history are not.
Technical teams can identify stale records and incomplete fields, but business owners still need to decide what supports current Sales, Service, reporting, or compliance requirements. recommends defining ownership, data architecture, use cases, and cleanup effort before migration.
Question Custom Fields and Objects Before Mapping Them
One custom field may support an important sales requirement. Another may exist because a limitation from years ago required a workaround. Both can look equally important in a metadata export.
Before mapping custom fields or objects to Microsoft Dataverse, trace each one to a current business requirement. Then determine whether a native Dynamics 365 table, relationship, business rule, Power Automate capability, or other supported pattern can handle it with less custom development.
New Dynamic's looks more broadly at how architecture, governance, workflow, and Microsoft ecosystem fit differ between the platforms. Those differences matter during migration because the target system should reflect Dynamics 365 Customer Engagement architecture rather than recreate Salesforce terminology and structure.
Rebuild the Business Process, Not the Salesforce Workaround
Start with the business rule the automation supports, then decide how Dynamics 365 CE/CRM and Power Platform should implement it. Do not treat every Salesforce Flow, Workflow Rule, Process Builder process, or Apex trigger as a separate migration requirement.
Salesforce automation can reflect years of accumulated process decisions. Flow, Workflow Rules, Process Builder, Apex triggers, validation rules, approvals, and custom code may all support what users experience as one process.
Dynamics 365 Activate can inventory that automation and code for assessment, but Microsoft does not automatically convert it during migration. The implementation team still has to decide which logic belongs in the future process.
For each significant automation, document:
- The business event that starts it.
- The decision or rule it supports.
- The systems and data it touches.
- The exception path when something fails.
- The person or team responsible for the process.
This review often reveals that several Salesforce components are supporting one business rule. A Flow may call Apex, rely on a validation rule, and feed an approval process. Users still experience that chain as one step.
Documenting the business rule first prevents the migration team from treating each technical component as a separate requirement. Once the business rule is understood, decide whether it belongs in Power Automate, Dataverse, native Dynamics 365 CE/CRM configuration, or a custom extension.
Which Salesforce Integrations Should Move to Dynamics 365 CE/CRM
A long-running Salesforce environment may connect to marketing platforms, finance applications, service systems, data warehouses, custom applications, and point solutions introduced at different points in the platform’s history.
Before reconnecting each integration, ask:
- Which system should own the data after migration?
- Does the integration still support a current business process, or is it compensating for an old platform boundary?
- Who monitors failures and owns changes after go-live?
Reporting needs the same scrutiny. Preserve the business question and KPI definition, then decide whether the future report belongs in Dynamics 365 CE/CRM, Power BI, Fabric, or another governed reporting layer. The target architecture may also eliminate or change integrations that existed primarily because of Salesforce.
What Salesforce History and Security Should Move to Dynamics 365 CE/CRM
Keep the history users need in Dynamics 365 CE/CRM. Archive other records when retention or reporting needs do not justify placing them in the active system. Design Dataverse security around future access requirements instead of copying Salesforce permissions.
Historical migration becomes more complicated when activities and related records must retain their context. Tasks, meetings, emails, notes, and attachments may depend on links to contacts, accounts, opportunities, or cases. Before migration, decide which relationships, dates, owners, and attachments users need to preserve. Test representative records to confirm the history remains useful in Dynamics 365 CE/CRM.
Salesforce profiles, permission sets, role hierarchies, sharing rules, and field-level permissions do not translate one-for-one to Dataverse. Audit who can view, edit, assign, and share records before designing the target access model. Then test roles, business units, teams, record sharing, and column-level security against real Sales and Service scenarios. Pay special attention to sensitive fields and users who work across business units.
Historical access and operational access are different requirements. Decide which one each data set needs before migration.
Why Should the Dynamics 365 CE/CRM Target Be Designed Before Migration Mapping
Define the target Dynamics 365 CE/CRM environment before detailed migration mapping begins. Document the intended data model, security boundaries, ownership, integrations, reporting, solution structure, and application lifecycle management approach. treats these as connected project disciplines. Migration tools should follow those decisions.
When Does a Salesforce Migration Service Add Value
External expertise becomes more useful as the source environment adds complex data relationships, customization, integrations, multiple business units, regulatory requirements, or significant process redesign.
New Dynamic helps organizations plan and execute Salesforce-to-Dynamics 365 migrations when the work extends beyond moving records. That includes evaluating source-system complexity, designing the target Dynamics 365 CE/CRM data and security model, reviewing integrations and reporting dependencies, and identifying Salesforce-specific customization that can be simplified with native Microsoft capabilities.
One pattern we look for is source-platform logic that has quietly become treated as a business requirement simply because it has existed for years. Separating the requirement from the Salesforce implementation helps determine what should survive the platform change and what can be redesigned.
Key Takeaways
- Challenge custom objects, fields, and Salesforce-specific automation before recreating them in Dataverse.
- Review integrations and reporting around the business process and KPI they support today.
- Decide which historical data belongs in production, which should be archived, and how security should work in the Dynamics 365 CE/CRM target environment.
- A migration partner should help simplify the target environment, not only transfer data.
If a Salesforce-to-Dynamics 365 CE/CRM migration is being scoped, start by inventorying the data, schema, automation, integrations, reporting dependencies, history, and security model. New Dynamic provides Salesforce-to-Dynamics 365 CE/CRM migration planning and implementation for organizations that need help simplifying that environment and defining the target architecture before migration begins.
The best migration is not the one that reproduces Salesforce most accurately. It is the one that leaves the organization with a Dynamics 365 CE/CRM environment that is easier to operate, easier to change, and better aligned with the business it needs to support next.
Travis South – Director of Marketing
