Migrate from Dynamics 365 Marketing to Twenty CRM

Dynamics 365 Contact records map directly to Twenty CRM Person records. Standard fields (fullname, emailaddress1, telephone1, address) map to Twenty CRM's name, email, phone, and address fields. The Contact-to-Account lookup resolves to a Twenty CRM Organization record that we import first. We apply a marketing contact suppression flag at import time by setting a custom field or tag to prevent any unintended billing exposure from contacts that qualified as marketing contacts in Dynamics 365. The msdy_contacttype property, if used, maps to a custom Person field for reporting.

Dynamics 365 Account records map to Twenty CRM Organization. The Account.Name field maps to Organization.name, Account.industry maps to Organization.industry, and address fields map directly. Account hierarchies (parent account references) are preserved where Twenty CRM's organization model supports hierarchical relationships. We import Organizations before Persons so that the Contact-to-Account lookup resolves at the moment of Person insert.

Dynamics 365 Lead records do not have a direct Twenty CRM equivalent because Twenty CRM uses a unified Person model rather than a separate Lead object. We import Leads as Twenty CRM Person records and preserve the Lead.Status property as a custom Person field (lead_status__c) and Lead.LeadSource as lead_source__c. The customer's admin decides whether to re-engage migrated Leads in Twenty CRM or mark them for follow-up in a separate campaign tool.

Dynamics 365 Opportunity records map to Twenty CRM Opportunity. Fields map as follows: Opportunity.Name to Opportunity.name, Opportunity.EstimatedCloseDate to Opportunity.closeDate, Opportunity.EstimatedValue to Opportunity.amount, Opportunity.StatusCode to Opportunity.stage, and Opportunity.OwnerId to Opportunity.accountId via user lookup resolution. Pipeline stages map to Twenty CRM stage values configured before migration.

Dynamics 365 activities stored in ActivityPointer and its type-specific child tables (Email, Task, PhoneCall, Appointment) map to Twenty CRM Activity records. We preserve the regarding object lookup (objectid and objecttypecode) to re-associate each activity with the correct Person or Organization in Twenty CRM. The activity timestamp (ScheduledStart) maps to Activity.date. Call dispositions and durations migrate as custom activity fields. Email body content migrates as the activity description.

Dynamics 365 Annotations (notes with file attachments) are exported individually. We handle them in a separate pass after parent records (Person, Organization, Opportunity) are confirmed in Twenty CRM. The objectid and objecttypecode from Dynamics map to the target Twenty CRM record ID so attachments re-associate correctly with their parent record. Large binary attachments (>10 MB) require chunked upload handling via the Twenty CRM API.

Dynamics 365 Campaigns and Campaign Activities are part of the legacy marketing model and have no direct Twenty CRM equivalent. We extract campaign structure (campaign name, status, dates, budgeted cost) as a structured data export. The association between campaigns and Marketing List members is preserved as a written target list inventory that the customer's admin recreates in their chosen marketing automation tool. Campaign Activities are not migrated as functional records.

Marketing List membership records are exported as a static list of Person and Organization IDs. Because Marketing Lists in Dynamics 365 reference Campaigns and contain members of a single entity type (Contacts, Accounts, or Leads), we export the list membership and member IDs and deliver a written target list inventory mapping each Dynamics 365 Marketing List to a recommended Twenty CRM target list name. The customer's admin recreates these lists in their marketing automation tool of choice.

Customer Insights segment definitions live in the Customer Insights - Data service, which is separate from the core CRM Dataverse database. A CRM-only export will leave segment memberships behind. We execute a separate export pass for segment memberships, mapping each segment's member Person IDs to a static list in the delivery document. Segments are not recreated as functional automation logic in Twenty CRM; we document the segment criteria and member count for the customer's marketing team to rebuild in their chosen marketing automation platform.

Dynamics 365 Owner assignments on Contact, Account, Opportunity, and Activity records are migrated as user lookups in Twenty CRM. We resolve owners by email match against the Twenty CRM User table. Any Dynamics 365 Owner without a matching Twenty CRM User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Inactive Dynamics 365 users are mapped to inactive Twenty CRM users with the original OwnerId preserved in a custom field for audit.

Custom entities created within a Dataverse managed solution are supported but require a pre-migration schema export (the solution ZIP or Configuration Migration Tool schema file). We do not infer custom entity structure from Dynamics 365 UI exports. The customer must provide the managed solution schema before we can accurately map custom entity imports. Custom fields on standard entities (Contact, Account, Opportunity) are created as Twenty CRM custom fields before data import begins. Custom entities with lookup relationships to standard entities are imported after the parent standard entity is confirmed in Twenty CRM.