Migrate from Dynamics 365 Marketing to Microsoft Dynamics 365 Sales

Dynamics 365 Marketing shares the msdyn_contact table in Dataverse with the CRM layer, so Contacts map directly to Microsoft Dynamics 365 Sales Contact. Standard fields (fullname, emailaddress1, telephone1, address) are identical between source and destination. We flag contacts that had Marketing Contact billing status during scoping and carry the original billing classification in a custom field mktg_contact_flag__c on the destination Contact so that the admin team has full visibility into which records triggered tenant-level marketing charges in the source environment.

Leads are a native Dataverse entity in both the Marketing and Sales environments. Lead lifecycle stages (leadstatus, leadsource, statecode) map directly. We preserve any lead scoring values from Customer Insights - Data as a custom field ci_lead_score__c if the destination admin wants to retain those values for prioritization after migration. Owner lookup resolves by email against the destination User table.

Accounts are the org-level parent records in both source and destination and map 1:1. Industry, address, and custom account fields transfer directly. Account hierarchies are preserved where the source had parent-account relationships. We resolve the primary contact lookup during the Account import pass so that the parent-account chain is intact before any Contact import that references it.

Opportunities in Dynamics 365 Marketing and Sales share the msdyn_opportunity table in Dataverse. Pipeline stage, estimated close date, amount, probability, and owner assignment transfer directly. The opportunity-to-contact and opportunity-to-account lookups resolve at migration time using the contact and account IDs written in earlier passes. We validate that the destination Sales Process whitelists the imported stage values before the opportunity batch is committed.

Activities in Dynamics 365 Marketing live in the ActivityPointer entity with type-specific child tables. Emails, tasks, phone calls, and appointments map to the corresponding Microsoft Dynamics 365 Sales activity objects. The regarding object lookup (regardingobjectid) re-associates each activity with its parent Contact, Account, or Opportunity in the destination. We preserve the original ActivityDate for timeline ordering. High-volume activity migration uses the Dataverse Bulk API with exponential backoff and batch chunking to avoid timeout errors on large engagement histories.

Note records with file attachments stored as Annotation entries are exported individually. We preserve the objectid and objecttypecode to re-associate each Note with its parent Contact, Account, Lead, or Opportunity in Microsoft Dynamics 365 Sales . File attachments migrate as Salesforce ContentDocument equivalents in Dataverse, with ContentDocumentLink maintaining the parent relationship. We run this pass after the parent records exist in the destination to avoid orphaned notes.

User records and owner assignments on all CRM entities resolve by email match between the source and destination User tables. Dynamics 365 Marketing and Sales share the same Azure AD-backed identity layer, so most active users resolve automatically. Any source owner without a matching destination User goes to a reconciliation queue; the admin provisions the missing user before record migration resumes. Inactive source owners are preserved as inactive User records in the destination with the original ownerid for audit integrity.

Custom entities created within a Dataverse solution export as managed solution schema files from the Configuration Migration Tool or as unmanaged solution ZIPs. We pre-create the destination schema in Microsoft Dynamics 365 Sales before any custom entity data is imported, including all custom fields, lookup relationships to standard entities, and validation rules. The customer must provide the managed solution file or schema export; we do not infer custom entity structure from UI exports because those omit relationship metadata and field security profiles.

Journey definitions stored in the msdynmkt_journey table have no direct equivalent in Microsoft Dynamics 365 Sales . Customer Insights - Journeys uses trigger-based logic, segment membership conditions, and AI-assisted content selection that do not exist in the Sales Campaign model. We extract Journey configuration (trigger type, segment references, email asset IDs, delay logic, and goal metrics) and deliver it as a written asset inventory document. The customer's admin uses this to rebuild equivalent Campaigns with Quick Campaign activity sequences in Microsoft Dynamics 365 Sales . The emails referenced in Journey definitions are inventory-only and must be rebuilt as Sales-email templates.

Marketing Lists contain member records and are associated with Campaigns in Dynamics 365 Marketing. We export the list membership and recreate each list as a static Campaign in Microsoft Dynamics 365 Sales , with CampaignMember records carrying the same contact or lead associations. Dynamic Marketing List logic (query-based membership) cannot be replicated in Sales without rebuilding the query criteria manually. We document the original query logic for the admin to evaluate which lists warrant a static rebuild versus a manual segmentation approach in Microsoft Dynamics 365 Sales .

Segment definitions and membership data live in the Customer Insights - Data service, a separate Dataverse instance from the core CRM. Migrating segment membership as static CampaignMember records is possible but the segment criteria that drive dynamic membership have no equivalent in Microsoft Dynamics 365 Sales . We export the segment criteria and deliver a written segment inventory with recommended Sales-based segmentation equivalents (using Contact fields, Account industry, or Lead source as the segmentation basis). If the customer is also licensing Dynamics 365 Customer Insights after migration, segment recreation in Customer Insights - Data is a separate engagement.