Migration route

    Salesforce→Microsoft Dynamics 365

    Salesforce to Microsoft Dynamics 365 Data Migration

    Migrate accounts, contacts, leads from Salesforce to Microsoft Dynamics 365 using a controlled process for extraction, mapping, transformation, validation, loading and reconciliation.

    Discuss Your MigrationAll Migration Routes

    Migration overview

    Salesforce to Dynamics 365 Sales is usually driven by Microsoft estate consolidation rather than a Salesforce capability gap — licensing, Teams and Power Platform integration, and a preference for one vendor across productivity and CRM.

    Both platforms generate their own keys, so the migration is again an identity problem before it is a field-mapping problem.

    Typical data scope

    Scope is agreed in discovery. On this route it usually covers:

    Accounts

    Domain in scope for a typical Salesforce to Microsoft Dynamics 365 programme.

    Contacts

    Domain in scope for a typical Salesforce to Microsoft Dynamics 365 programme.

    Leads

    Domain in scope for a typical Salesforce to Microsoft Dynamics 365 programme.

    Opportunities

    Domain in scope for a typical Salesforce to Microsoft Dynamics 365 programme.

    Activities

    Domain in scope for a typical Salesforce to Microsoft Dynamics 365 programme.

    Migration architecture

    One controlled pipeline, run as repeatable cycles.

    Salesforce→DataMove→Transformation & validation→Microsoft Dynamics 365→DataVault reconciliation→DataLens

    Extracting from Salesforce

    What the source platform makes available, and the constraints that shape the extraction design.

    15 vs 18 character record IdsSalesforce exposes a 15-character case-sensitive Id and an 18-character case-safe version of the same key. Mixing them, or letting a process change the case of the 15-character form, collapses distinct records onto each other. Extracts standardise on the 18-character Id.
    Bulk API 2.0 and SOQLBulk API handles volume; SOQL defines what is selected, including relationship traversal. Governor limits and batch behaviour shape how a large extract is staged.
    Lookup vs master-detailThe two relationship types behave differently on deletion and ownership and do not map to one target construct, so each is resolved explicitly rather than treated as a generic foreign key.
    RecordType drives validityRecordType decides which picklist values and layouts apply. A value valid under one RecordType is rejected under another, so RecordType is part of the mapping key, not an attribute beside it.
    Formula and rollup fieldsThese are calculated, not stored. They must be recreated in the target rather than migrated, or the target inherits frozen numbers that stop updating.
    Files, attachments and notesContent lives in its own objects with its own relationships. Carrying the parent record without them loses the evidence trail sales and service teams rely on.

    Source-to-target mapping

    A mapping workbook carries every field in scope from its Salesforce source through its transformation rule to the Microsoft Dynamics 365 target object and field. It is reviewed and approved with the business before the production migration, and applied identically in every cycle so a decision made once is not re-made under cutover pressure.

    Transformation challenges on this route

    The differences between Salesforce and Microsoft Dynamics 365 that create most of the work.

    Both ends generate keys

    Salesforce 18-character Ids and Dataverse GUIDs are both meaningless in the other system. Relationships are rebuilt through a source-to-target cross-reference map.

    Alternate keys make reloads safe

    Loading against a Dataverse alternate key turns a second cycle into an update rather than a duplicate population.

    RecordType to business process flows

    Salesforce RecordTypes and page layouts do not map onto one Dynamics construct; the equivalent behaviour is expressed through forms, business rules and process flows.

    Option sets versus picklists

    Coded values validate against option sets defined in the Dataverse model and are crosswalked explicitly.

    Formula and rollup fields

    Calculated in Salesforce, they must be rebuilt as calculated or rollup columns rather than migrated as values.

    How Microsoft Dynamics 365 accepts the data

    Load order is part of the design, not an implementation detail.

    1. 1Data Management Framework for Finance and OperationsData entities, data projects and staging tables. Import runs into staging first, then into target tables, with errors surfacing per entity at each step.
    2. 2Dataverse loads for Customer EngagementBulk loads through the Web API or dataflows, with alternate keys used so a reload updates rather than duplicates.
    3. 3Number sequencesF&O assigns many keys from number sequences. Whether the legacy key is preserved or regenerated is decided per entity before mapping.
    4. 4Entity dependency orderReference and setup entities, then masters, then transactions — the same shape as any ERP load, against a target where entity definitions rather than tables set the contract.
    5. 5Work the staging-table errorsRows can pass into staging and still fail promotion into target tables, so both stages are reconciled rather than just the file load.

    Validation and reconciliation

    Validation before load

    Mandatory fields, referential integrity, format checks, business-rule validation and duplicate detection run on the prepared data, so problems surface as reportable exceptions rather than as failed loads in Microsoft Dynamics 365.

    Reconciliation after load

    Source counts, transformed counts, rejected records and target counts, with control totals where the data supports them. Every discrepancy is categorised so the migration is approved on evidence rather than assertion.

    Migration cycles

    The pipeline is run end to end more than once before anything touches production. A typical structure is a first rehearsal that surfaces the bulk of mapping and data-quality corrections, a second that applies them and demonstrates production readiness, and the production cutover itself. How many cycles a programme needs depends on data quality and scope, which is established during discovery.

    1. 1Mock / PPR 1First full extract, transform, load, reconcile and exception analysis. Expect the largest correction list here.
    2. 2Mock / PPR 2Corrections applied, re-extract, re-run. Intended to closely replicate the production migration.
    3. 3Production cutoverFinal extract, data freeze, load, reconciliation, business validation and sign-off.

    Common risks on this route

    Relationships reconciled by count only

    Every record can load and the CRM still be wrong if children hang off the wrong parents.

    Files and notes deferred

    They carry the evidence trail and have their own volume profile.

    Ownership and security model mismatch

    Owner drives visibility on both sides but through different models; unmapped owners need an explicit fallback.

    How Syntra ETL supports this route

    DataMove

    Extraction, mapping, transformation and load preparation for Microsoft Dynamics 365.

    Explore DataMove →

    DataVault

    Source-to-target reconciliation, migration lineage and audit evidence for every cycle.

    Explore DataVault →

    DataLens

    Migration status, data quality and exception visibility across cycles.

    Explore DataLens →

    Related enterprise migration experience

    We have not published a case study for this exact route. These delivered projects are the closest relevant experience.

    Salesforce→Oracle Fusion CX

    Salesforce to Oracle Fusion CX data migration

    Accounts, Contacts, Leads, Opportunities

    Case study available →

    Related migration routes

    Microsoft Dynamics 365→Salesforce

    Microsoft Dynamics 365 to Salesforce data migration

    Accounts, Contacts, Leads, Opportunities

    View route →    Salesforce→Oracle Fusion CX

    Salesforce to Oracle Fusion CX data migration

    Accounts, Contacts, Leads, Opportunities

    Case study available →    SAP CRM→Salesforce

    SAP CRM to Salesforce data migration

    Business Partners, Accounts, Contacts, Opportunities

    View route →    Oracle Fusion CX→Salesforce

    Oracle Fusion CX to Salesforce data migration

    Organizations, Persons, Leads, Opportunities

    View route →    Microsoft Dynamics 365→Oracle Fusion

    Microsoft Dynamics 365 to Oracle Fusion data migration

    Financials, Procurement, SCM, Master data

    View route →

    Planning this migration?

    Tell us your source system, target platform, modules, data volumes and timeline. We can discuss the closest relevant migration experience and the recommended approach.

    Discuss Your MigrationSee Delivered Projects