Migrate from Cordial to Microsoft Dynamics 365 Sales

Cordial Contacts map to Microsoft Dynamics 365 Sales Contact. Standard fields (email, firstname, lastname, phone) migrate directly. Every custom contact attribute is inventoried during discovery: string and number attributes map to typed Dynamics custom fields (new Text, Number, or Decimal fields in the target organization); array-type attributes (e.g. favorite_colors, tag lists, behavioral history) are normalized to delimited strings in a custom field or to a related custom entity, per the normalization strategy agreed during scoping. The Contact's _channel_preferences.email and SMS opt-in status map to HasOptedOutOfEmail and a custom SMS_opt_in__c boolean.

Cordial Lists are static contact collections. We export list membership as a boolean custom field per list (e.g. vip_customer__c = true) or as a lookup table mapping contact email to list name, depending on how many lists exist and whether Dynamics field limits are a concern. If more than 20 lists exist, we use a related CordialListMembership__c custom entity with a Contact lookup to avoid hitting the per-object custom field ceiling.

Cordial Products store variants as nested JSON arrays under a single record (with fields like color, size, material per SKU). We unpack the variant array and generate one Product2 record per SKU, preserving the parent product ID as a custom field parent_product_id__c for relationship reconstruction in Dynamics. Each Product2 gets a Standard Pricebook entry created at import time. ProductCode maps from Cordial's productID field.

Cordial Channels (email, SMS, push) are stored as sub-attributes on contacts indicating opt-in status and preferences per channel. We export these as separate boolean or string fields on the Dynamics Contact: email_opt_in__c, sms_opt_in__c, push_opt_in__c. Channel-level preference timestamps (when the contact last gave consent) migrate to consent datetime fields if tracked in Cordial.

Cordial behavioral events (opens, clicks, purchases, custom events) export via the Contact Activity Export API with time-range and event-type filters. We map purchase events to Task records with custom fields event_type__c = 'purchase', event_data__c carrying the JSON payload, and ActivityDate set to the original Cordial timestamp. Opens and clicks map to Task records with event_type__c values for reporting segmentation. Large event histories (over 100,000 records) are chunked and loaded via the Dynamics 365 Data Export Service or Azure Data Factory.

Orders are not a native first-class object in Cordial's core schema but are often stored as custom contact attributes or linked via purchase event data. We identify order-related attributes and custom event types during schema discovery, extract order records, and map them to Microsoft Dynamics 365 Sales Order (SalesOrder) if the destination org has the Sales module, or to a custom Order__c entity with line items if the edition does not include Order management. Order date, total amount, currency, and status are mapped to the corresponding Dynamics fields.

Cordial Segments are dynamic rules-based audiences built from contact attributes and event conditions. We export segment definitions as rule summaries in a written inventory document and flag which contacts currently match each segment by writing the segment name to a custom field (e.g. segment_membership__c) on the Contact record. Segment rules themselves cannot be exported via API and require rebuild in Microsoft Dynamics 365 Sales via Advanced Find queries, Power Automate flows, or a Dynamics marketing module.

Cordial Owners map to Dynamics 365 User records by email match. Any Cordial Owner without a matching Dynamics User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Owner-based routing and team assignments migrate as OwnerId references on Contact, Account, and Opportunity records.