Migrate from Dynamics 365 Marketing to Salesforce Sales Cloud

Dynamics 365 Marketing Contacts map to Salesforce Lead or Contact based on lifecycle status. Prospects and unqualified contacts from Dataverse msdyn_contact with no related opportunity become Salesforce Leads. Contacts that have an associated opportunity or account become Salesforce Contacts attached to the corresponding Account. We compute the split at migration time using the contact's lifecycle stage and opportunity association from the source data, and preserve the original Dynamics lifecycle status in a custom field d365_lifecycle_stage__c on both Lead and Contact for reporting continuity.

Dataverse Lead records that exist separately from Contacts map directly to Salesforce Lead. Lead status values from Dynamics map to Salesforce Lead Status picklist values. Any lead scoring data from Customer Insights - Data or custom Dataverse fields migrates to a custom field d365_lead_score__c on the Salesforce Lead record.

Dynamics 365 Accounts (Companies) map directly to Salesforce Account. The primary contact relationship is preserved via the primarycontactid lookup when present. Account address, industry, number of employees, annual revenue, and custom account fields migrate to corresponding Salesforce Account fields. Account hierarchies in Dynamics map to Salesforce's parent Account lookup.

Dynamics 365 Opportunities (msdyn_opportunity) map to Salesforce Opportunity. Pipeline stage from Dynamics maps to Salesforce StageName with probability percentages rounded to Salesforce-allowed integer values. Estimated close date, amount, and owner assignment migrate directly. The opportunity-to-account and opportunity-to-contact relationships are resolved at migration time using the Dataverse relationship lookups.

Dynamics 365 Activities stored in the ActivityPointer entity and type-specific child tables (Email, Task, PhoneCall, Appointment) migrate to Salesforce EmailMessage, Task, and Event records. The regarding object lookup (regardingobjectid) is resolved to the target Salesforce record's WhoId or WhatId at migration time. Activity timestamps preserve the original Dynamics createdon date for timeline continuity. Large activity histories (over 200,000 records) are migrated via Salesforce Bulk API 2.0 with chunking and exponential backoff.

Dynamics 365 Annotations (notes with file attachments) are exported individually and mapped to Salesforce Note records with associated ContentDocument records for file attachments. The objectid and objecttypecode from Dynamics are resolved to the target Salesforce record ID at migration time, and the notetext body migrates as rich text to the Salesforce Note body field.

Dynamics 365 Marketing Lists (msdynmkt_marketinglist) containing member records map to Salesforce Campaign objects. List membership records migrate as Salesforce CampaignMember records linked to the Campaign, with the member type preserved (Contact or Lead) and the member's status mapped to CampaignMember Status. Marketing List name and description become Campaign Name and Description.

Dynamics 365 Campaigns and Campaign Activities are legacy marketing model entities. We export campaign structure, objective, and budget information as Salesforce Campaign records. Campaign Activities are mapped to Salesforce Tasks or Notes linked to the Campaign depending on the activity type, since Salesforce has no direct Campaign Activity equivalent. We sequence Campaign import after Accounts and Contacts to ensure the parent record exists before CampaignMember records are written.

Marketing emails stored in the msdynmkt_email Dataverse table (Customer Insights - Journeys) are exported via the Configuration Migration Tool as content reference documentation. Salesforce Sales Cloud has no direct equivalent for marketing email assets; we document the email name, subject line, body content, and Dynamic Content blocks as a reference guide for the customer's admin to rebuild in Salesforce Marketing Cloud Account Engagement, Marketing Cloud Content Builder, or Sales Cloud Email Templates depending on the marketing automation strategy chosen during scoping.

Customer Journey definitions stored in msdynmkt_journey and related tables are extracted as configuration reference documentation. Dynamics 365 Journeys reference segment memberships, email content, trigger conditions, and wait logic that have no direct Salesforce Sales Cloud equivalent. We deliver a written journey inventory that lists each Journey's name, trigger type, segment membership, email assets, and flow logic so the customer's marketing team can rebuild using Salesforce Marketing Cloud Account Engagement Engagement Studio or Marketing Cloud Journey Builder. Journey automation logic does not migrate as code.

Customer Insights segments are stored in a separate service from the core CRM Dataverse database and require a dedicated export pass. Segment definitions (criteria-based or static) and membership records are documented as a reference guide for the customer's admin to recreate in Salesforce. If the destination includes Marketing Cloud Account Engagement, segments map to Pardot Lists; for Sales Cloud-only destinations, segments map to Salesforce Campaigns with static membership. Segment membership data cannot be imported directly into Salesforce without a target list equivalent being defined first.

Custom entities created within a Dataverse solution are supported for migration but require the customer to provide the managed solution ZIP or schema file exported via the Configuration Migration Tool before we can define the destination Salesforce custom object. We do not infer custom entity structure from UI exports because they omit relationship metadata, field security profiles, and managed property settings. We create the Salesforce custom object (with __c API name matching the Dataverse entity logical name where feasible), define all custom fields, establish lookup relationships, and import the data once the schema is deployed and validated in the destination org.

Dynamics 365 User records and owner assignments on all entity types are migrated as User lookups in Salesforce. We match Dynamics users by email address against the Salesforce destination org's User table. Any Dynamics User without a matching Salesforce User is placed in a reconciliation queue for the customer's admin to provision before record migration continues. Owner assignments on Contacts, Leads, Accounts, and Opportunities are resolved at migration time using the pre-validated User mapping.