Migrate from Microsoft Dynamics 365 Sales to Salesforce Sales Cloud

Dynamics 365 Accounts map directly to Salesforce Account. The AccountID in Dataverse (accountid GUID) is the primary key for cross-referencing all child records. We use accountid as the external ID field during Salesforce Bulk API upserts so that child Contact and Opportunity records can resolve the AccountId lookup at insert time without a separate lookup pass. Address fields (address1_line1, address1_city, address1_stateorprovince, address1_postalcode, address1_country) map to the Account's shipping address fields. If the Dynamics environment uses multiple address records per account, we migrate the primary address and flag multi-address records for the customer's admin to handle in Salesforce.

Dynamics 365 Contacts map to Salesforce Contact with a required lookup to Account via the parentcustomerid field. We resolve parentcustomerid to the AccountId of the matching Salesforce Account at migration time. Email address (emailaddress1) maps to Contact.Email and is used as the deduplication key. The contact's preferredcontactmethodcode (Email, Phone, Mail, Fax) has no direct Salesforce equivalent; we store it in a custom field preferredcontactmethod__c. Mobile phone (mobilephone) maps to Contact.MobilePhone. Birthdate (birthdate) maps to Contact.Birthdate only if the field exists as a standard or custom field in the destination schema.

Dynamics 365 Leads map directly to Salesforce Lead. The lead's statecode (Open, Qualified, Disqualified) and statuscode map to Salesforce Lead Status values. Lead scoring fields (leadqualityscore,leadsource) map to custom fields or standard Lead Source. If the Dynamics Lead has been disqualified and the customer wants to preserve that history, we set Lead Status to Closed-Not Converted with a Disqualified reason custom field rather than importing as an open Lead. The lead's parentcontactid reference is preserved as a custom field lead_parentcontactid__c for post-migration reconciliation.

Dynamics 365 Opportunities map to Salesforce Opportunity with the accountid reference resolved to the Salesforce AccountId and the owning user reference resolved to a Salesforce UserId. The estimatedvalue field maps to Amount; closeprobability maps to Probability; actualclosedate maps to Close Date; stepname maps to StageName. Loss Reason and Win Reason from Dynamics custom fields map to custom Salesforce fields. Pipeline and territory assignments from Dynamics map to Salesforce Record Types and the Opportunity's sales_team__c custom field. We validate that every Opportunity has a resolved AccountId before insert to avoid orphaned opportunities.

Dynamics 365 Quotes map to Salesforce Quote with the customerid reference (account) and opportunityid reference (opportunity) resolved to Salesforce IDs at migration time. The quotenumber, name, effectivefrom, effectiveto, totalamount, and discount fields map directly. Quote line items (quotedetail) map to QuoteLineItem with the productid reference resolved to a Salesforce Product2 ID. We pre-create all Salesforce Pricebook2 records matching the Dynamics price list names before Quote migration begins so that Pricebook2Id is available at QuoteLineItem insert.

Microsoft Dynamics 365 Sales Orders map to Salesforce Order with the accountid resolved to Salesforce AccountId and the opportunityid resolved to Salesforce OpportunityId. The ordernumber, name, datefulfilled, and totalamount fields map directly. Order products (salesorderdetail) map to OrderProduct with the productid resolved to a Salesforce Product2 ID. The order's status (Pending, Invoiced, Cancelled, Completed) maps to Salesforce Order Status with a pre-configured StatusCode mapping in the transformation layer.

Dynamics 365 Invoices map to Salesforce Order (type=Invoice) or to a custom Invoice object depending on whether the destination org uses Salesforce Invoicing (Order-based). For standard Salesforce, we migrate Invoices as Order records with record type Invoice and a totalamount field preserved. Invoice line items map to OrderProduct. The invoicenumber, datedelivered, and paymenttermscode fields are preserved as custom fields. If the destination org uses Salesforce Billing, we coordinate the Invoice object schema during scoping.

Dynamics 365 Products map to Salesforce Product2 records with the productnumber and name fields preserved. The defaultuomscheduleid reference (unit of measure) maps to Salesforce's QuantityUnitOfMeasure on Product2. We create Standard Pricebook entries for each Product2 during migration so that PricebookEntry records exist at the time OpportunityLineItem or QuoteLineItem records are inserted. Product bundles (productAssociations) are translated into Salesforce Product Bundles via the PricebookEntry hierarchy.

Dynamics 365 Price Lists map to Salesforce Pricebook2 records. Each price list item (productpricelevel) maps to a PricebookEntry linked to the corresponding Product2 and Pricebook2. The amount (price) field and quantitysellingcode (quantity-based discount tiers) are preserved. We create the Pricebook2 records before any Quote or Order migration begins so that Pricebook2Id can be resolved at line-item insert time. The IsStandard flag on Pricebook2 must be set via the Salesforce API by FlitStack AI during migration.

Dynamics 365 Activities (ActivityPointer, Task, Email, PhoneCall, Appointment) map to Salesforce Task and Event records. Task records preserve the subject, description, scheduledstart, scheduledend, actualdurationminutes, and statecode/statuscode fields. Email activities map to Salesforce Task with TaskSubtype=Email and the email body in Description. PhoneCall activities map to Task with TaskSubtype=Call and CallDurationInSeconds preserved. Appointment activities map to Salesforce Event with StartDateTime and EndDateTime preserved. The regardingobjectid (lookup to any CRM entity) maps to WhatId on Task and Event. OwnerId resolution uses the email-matched User mapping; inactive owner references are remapped to a designated migration admin placeholder.

Dynamics 365 Notes (Annotation entity) store as plain text or HTML in the notetext and documentbody fields. We migrate them to Salesforce Note records with the Title from subject, Body from notetext, and ParentId pointing to the related Account, Contact, Lead, or Opportunity resolved via the objectid reference. HTML-formatted notes are converted to plain text during transformation to avoid XSS issues in Salesforce's rich text rendering.

Dynamics 365 file attachments stored in SharePoint or Dataverse blob storage migrate to Salesforce ContentDocument via the Salesforce Files feature. We download the file from the SharePoint URL or Dataverse documentbody, create a ContentVersion record (the file itself), and create a ContentDocumentLink record linking it to the parent Account, Contact, Lead, or Opportunity via the related Entity. File names and original created dates are preserved in ContentVersion's Title and CreatedDate fields.

Dynamics 365 custom tables (beyond the 15-table cap on Professional tier) map to Salesforce custom objects with __c API names matching the original table names. We detect the exact count of custom tables during scoping, flag any above the 15-table threshold, and present the customer with a list to merge, drop, or map to existing Salesforce standard objects before migration begins. Custom table columns map to custom fields on the destination custom object with equivalent data types (string to text, integer to number, decimal to currency or number, datetime to datetime). Lookup relationships between custom tables map to Salesforce lookup fields.

Dynamics 365 Users map to Salesforce Users via email address as the matching key. We extract all distinct ownerid values from Dynamics records (Account, Contact, Lead, Opportunity, Activity) and cross-reference against the destination Salesforce User table. Any owner without a matching Salesforce User is placed in a reconciliation queue; the customer's admin provisions the missing User before record migration continues. Inactive Dynamics users are mapped to a designated migration admin User in Salesforce to prevent orphaned record ownership.

Dynamics 365 Territory hierarchy (available on Enterprise tier only) maps to Salesforce Territory2 if the destination org has Territory Management enabled. Each Dynamics Territory becomes a Territory2 record with the territoryid GUID preserved in a custom field. Territory assignment on Accounts maps to the Salesforce Account's Terr__c or Territory2Assignment object depending on the destination model. If the destination org does not use Territory Management, territory names migrate as a text field on Account or a multi-select picklist on User.

Dynamics 365 Connections (representing partner, reseller, or affiliate relationships between records) map to Salesforce AccountContactRelation if the relationship involves Contacts, or to a custom Junction object if it involves Accounts or custom objects. Connection roles (connectionrole) migrate as roles on the AccountContactRelation. We detect the full connection graph during scoping and create the junction records during the Account and Contact migration phase.