Migrate from Cordial to Twenty CRM

Cordial Contacts map directly to Twenty CRM Person records. We extract all standard fields (email, firstName, lastName, phone) plus every custom contact attribute stored as a string or number type. Each attribute becomes a custom field on the Person object in Twenty CRM. Array-type attributes (tags, favorite colors, behavioral lists) are flagged during scoping and normalized to delimited strings or held as a separate lookup table pending customer preference. Cordial's channel preferences (email opt-in, SMS opt-in) become custom boolean fields on Person.

Cordial Contacts with matching domain-level company data map to Twenty CRM Company records. We extract the domain from each Contact's email address, deduplicate by domain, and create one Company record per unique domain. Company name, website, and industry attributes from Cordial's company-level custom fields migrate as typed Company fields. If Cordial stores no explicit company data, we infer it from email domain and flag the Company records for enrichment after cutover.

After creating Company records, we resolve the Person-to-Company relationship by matching the email domain. Each Person record receives a link to its corresponding Company via the Remote domain lookup in Twenty CRM. This link enables the Person-Company relationship model that powers Twenty's activity attribution and account-level reporting. If a Contact has no inferable domain (personal email), it remains as a Person without a Company link and is flagged for manual review.

Cordial Products are stored as JSON objects with nested variant arrays. Twenty CRM has no native Product object, so we configure a custom object (e.g. Product_v2__c) to hold SKU, productName, price, and variant-level data. Each variant in Cordial's nested array generates a separate custom object record linked to its parent product record via a self-referential lookup. Alternatively, for simpler migrations, product data maps to custom fields on Company if the product catalog is small. The customer chooses the strategy during scoping.

Cordial does not have Order as a native first-class object; order data typically lives as a custom contact attribute or a custom purchase event type. We identify all order-related attributes and event types during discovery, then generate a Twenty CRM Opportunity record per order. Order amount maps to Amount, order date maps to CloseDate, and the Opportunity stage is set to Closed Won by default since orders represent completed transactions. The Opportunity is linked to the Person (buyer) and Company (seller or brand) via Twenty's relationship fields. If multiple orders exist per contact, multiple Opportunity records are created.

Cordial tracks behavioral events (opens, clicks, purchases, custom events) per contact via the Contact Activity Export API. Each distinct event type generates a custom Activity type in Twenty CRM or is mapped to a generic Note attached to the Person record. We preserve the event timestamp and event name as typed Activity fields. High-volume event types (e.g. page views) may be aggregated into summary records to avoid generating tens of thousands of individual Activity rows; the customer defines the aggregation threshold during scoping.

Cordial Lists are static sub-collections within the Contact collection. List membership does not map to a native Twenty CRM object, so we generate Tags for each list name and apply TopicAssignment records linking each Person to the relevant Tag. This preserves list membership data as a filterable attribute without requiring a custom list object. If the customer uses Cordial Lists as a segmentation proxy for campaigns, we note this and advise that campaign segmentation requires rebuilding in Twenty's filter UI or via the n8n integration.

Cordial Segments are dynamic rules-based audiences built from contact attributes and event conditions. Segment definitions have no export API, so we cannot migrate them as active filters. We document each active Segment as a written rule summary (attributes, operators, event conditions) and identify the contact count currently matching each segment. The customer uses this document to rebuild segments as saved filters or Views in Twenty CRM. This is an information handoff, not an automated migration.

Cordial stores channel-level opt-in status (email, SMS, push) as sub-attributes on each Contact. We extract these as separate boolean fields (e.g. emailOptIn__c, smsOptIn__c) and apply them to the Person record in Twenty CRM. Any non-standard channel type in Cordial (e.g. WhatsApp, push notifications) is flagged during scoping and mapped to a custom field with the appropriate label. We verify that opt-in timestamps are preserved where available.

Cordial Owners map to Twenty CRM User records by email address match. We extract every distinct owner referenced on Contact records and cross-reference against the destination Twenty instance's User table. Owners without a matching User in Twenty go to a reconciliation queue for the customer's admin to provision before record import resumes. Inactive Cordial owners map to inactive Twenty users so that historical attribution is preserved even if the user no longer has system access.