Migrate from Dynamics 365 Customer Service to Salesforce Service Cloud

Dynamics 365 CE Contact records migrate directly to Salesforce Contact. Email, phone, address, and parent Account linkage transfer as typed fields. We use the contact's emailaddress1 as the dedupe key. Any Dataverse custom fields on Contact migrate as custom fields on the Salesforce Contact object with type-equivalent mapping.

Dynamics 365 Account records map to Salesforce Account. AccountNumber, Name, Website, Industry, and the address compound fields migrate directly. Parent Account hierarchy (if used) maps to Salesforce's Parent Account lookup with the same parent-child relationship preserved.

Dynamics 365 Incident records migrate to Salesforce Case. Title becomes Subject, incidentid becomes the external reference preserved in a custom field d365_incident_id__c, and customerid (Contact or Account lookup) resolves to the migrated Contact or Account Salesforce ID. Case Priority, Status (Active/Waiting/Resolved/Closed), and Origin (Email/Phone/Web) transfer with picklist remapping. Resolution notes and resolved time migrate to Case Resolution fields.

Dynamics 365 queues migrate to Salesforce Queues. Queue members resolve by matching email to Salesforce User IDs. Queue-scoped record types (Case, Task) map to the equivalent Salesforce object. We flag that Unified Routing skill-based assignment rules and capacity thresholds are routing-logic configuration rather than data and do not migrate; they are documented for rebuild in Salesforce Omni-Channel Routing.

Dynamics 365 Entitlement records (support contracts with allocated hours or case-counts, channel restrictions, and SLA linkage) map to Salesforce Entitlement records as a related list on Contact or Account. We migrate the entitlement name, type (Hours or Cases), total hours or case count, consumed balance, start and end dates, and the applicable SLA term. Channel restrictions and pause conditions are noted in the mapping document because Salesforce Entitlement Processes handle pause conditions differently and may require configuration adjustment.

Active SLA instances on open Cases migrate as Salesforce Entitlement records with their SLA KPI targets (First Response Time, Resolution Time) preserved in the entitlement's terms. The SLA definition itself (business hours, warning thresholds, pause conditions) does not migrate as data because Salesforce's entitlement process model is configuration-based. We deliver a written entitlement process design document so the customer's admin rebuilds SLA logic in Salesforce Setup > Entitlement Processes and Business Hours.

Dynamics 365 Knowledge Articles migrate to Salesforce Lightning Knowledge as Salesforce KnowledgeArticleVersion records. Article title, content (HTML body), language, status, and version number transfer. We flatten nested Dataverse knowledge category assignments to Salesforce Data Category Groups for article taxonomy. If the source uses multi-language articles, each language version migrates as a separate Salesforce article version. Customers choosing Salesforce Knowledge must have Knowledge enabled in their Service Cloud edition (requires Enterprise or above for Lightning Knowledge).

Dynamics 365 ActivityPointer records (Email, Phone Call, Task, Appointment) migrate to Salesforce equivalents. Polymorphic regardingobjectid resolves to the migrated Contact, Account, or Case Salesforce ID at migration time. Email activities land as Salesforce EmailMessage records linked to Tasks; phone calls migrate as Task with TaskSubtype=Call; appointments migrate as Event; standalone tasks migrate as Task with Status, Priority, and ActivityDate preserved.

Omnichannel chat, voice, SMS, and social session transcripts from Dynamics 365 are stored in the msdyn_ocliveworkitem and msdyn_ocsession tables. We export the session transcript text and metadata (channel type, session start/end, agent assigned) and migrate it as CaseComment records appended to the related Case, or as EmailMessage records if the transcript contains structured email threads. Channel attachments (voice recordings, chat files) require re-upload to Salesforce Files or external storage since binary channel assets do not transfer as part of a standard record migration.

Customers who extended the Dynamics 365 data model with custom Dataverse tables and columns migrate these to Salesforce custom objects. We pre-create the destination custom object schema with all custom fields, lookup relationships to standard objects (Contact, Account, Case), and picklist option values before any data import. Option-set values from Dataverse migrate as Salesforce picklist values with matching labels. Many-to-many intersection tables map to Salesforce junction objects with two lookup relationships.

Dynamics 365 Notes stored on the Annotation table migrate to Salesforce Notes linked via ContentDocumentLink to the parent Contact, Account, Case, or custom object. The note body (rich text) transfers as-is; file attachments stored as Annotation's fileattachment migrates as Salesforce ContentVersion and ContentDocumentLink.

Cloud flows that trigger on Case create, update, or status change live in Power Automate outside of Dataverse and cannot be exported as part of a normal record migration. We do not migrate flows as data. We deliver a written inventory of every active cloud flow with its trigger, conditions, actions, and a recommended Salesforce Flow equivalent. The customer's admin or a Salesforce partner rebuilds them post-migration. Flows referencing external Microsoft endpoints (SharePoint, Teams, Power BI) may require re-authentication or alternative connectors in Salesforce.