Migrate your Dynamics 365 Marketing data

Contacts map directly to the msdyn_contact table in Dataverse. Standard fields (name, email, phone, address) are well-documented and stable. We preserve the full Contact-to-Account relationship during import.

Leads are a native Dataverse entity with lifecycle stages. Where the destination CRM does not have a separate Lead object, we merge Leads into Contacts and preserve the Lead_Status as a custom Contact property. Custom lead fields are handled via schema mapping from the source.

Accounts are the org-level parent records. We maintain the Contact-to-Account lookup relationship and preserve industry, address, and custom account fields. Account hierarchies are preserved where they exist.

Opportunities map to msdyn_opportunity in Dataverse. We preserve pipeline stage, estimated close date, amount, and owner assignment. The opportunity-to-contact and opportunity-to-account relationships are maintained at import.

Marketing emails are stored as msdynmkt_email table entries, specific to Customer Insights - Journeys. These are not part of the standard Dataverse CRM schema. We export via the Configuration Migration Tool and map content blocks, subject lines, and sender profiles to the destination's equivalent marketing email entity.

Journey definitions are stored in the msdynmkt_journey table. They reference segment memberships, email content, and trigger conditions. We extract Journey configuration via the Configuration Migration Tool and remap segment IDs and email references to the destination environment's corresponding records.

Segments are part of Customer Insights - Data, stored in a separate service from the core CRM. Segment definitions (criteria-based or static) require separate export. We handle segment memberships as a distinct import pass after the core contact records are in place.

Custom entities created within a Dataverse solution are supported but require a pre-migration schema export. We do not infer custom entity structure from UI exports. The customer must provide the managed solution or schema file before we can accurately map custom entity relationships.

Activities are stored in the ActivityPointer entity with type-specific child tables (Email, Task, PhoneCall, Appointment). We preserve the regarding object lookup to maintain the relationship between activities and their parent Contact, Account, or Opportunity record.

Annotations (notes with file attachments) are exported individually. We handle them in a separate pass, preserving the objectid and objecttypecode to re-associate attachments with their parent record in the destination environment.

Marketing Lists are specific to the outbound marketing model. They contain member records and are associated with Campaigns. We export the list membership and recreate the list in the destination, mapping member records to the destination's contact or account IDs.

Campaigns and Campaign Activities are part of the legacy marketing model. We preserve campaign structure and the association with Marketing List members. Campaign Activities require separate handling due to their dependency on the activity entity.

User records and owner assignments on records are migrated as user lookups. If the destination has a different user schema, we map owner IDs to the corresponding destination user. Inactive users may need to be provisioned before record imports proceed.

Custom fields on any entity must be defined in the destination environment schema before we can import values into them. We work from the field definitions exported via the solution schema and create a field mapping specification before data import begins.