Migrate from Cordial to Mailchimp

Cordial Contacts map directly to Mailchimp contacts within an audience. Standard fields (email, first name, last name, phone) map to their Mailchimp equivalents. We export all custom contact attributes and map each to a Mailchimp merge field by key name. Array-type attributes (tags, color preferences, behavioral history) are normalized to delimited strings or tags during export. We flag any custom attributes that exceed Mailchimp's 40-merge-field limit and agree on consolidation strategy during scoping.

Cordial custom attributes of type string, number, and geo map to Mailchimp merge fields of corresponding type (text, number, address). We preserve the attribute key as the merge field tag and map the type to the closest Mailchimp-supported type. If the customer has more than 40 custom attributes, we identify the most business-critical ones for merge field mapping and document the remainder for tag-based tracking.

Cordial array-type attributes (favorite colors, tag lists, behavioral event arrays) require normalization. We discuss the strategy during scoping: small fixed-length arrays (e.g., color swatches) normalize to delimited text strings stored in a single merge field; larger or variable-length arrays (e.g., behavioral history) convert to Mailchimp tags where each array element becomes a tag on the contact. The customer chooses the strategy before migration.

Cordial Lists are sub-collections within the Contact collection representing static segmented audiences. In Mailchimp, lists are audiences. We either create one Mailchimp audience per Cordial list (if the customer prefers strict separation) or migrate all contacts to a single audience and apply Cordial list membership as tags (if the customer prefers consolidation). The choice affects how segment rules translate to Mailchimp filters.

Cordial Products store variants as nested JSON arrays under a single product record. Mailchimp has no native product variant concept. We unpack the variant array and generate one Mailchimp product row per SKU, preserving the parent Cordial product ID as a custom field (cordial_parent_product_id) to maintain the relationship. Variant-specific attributes (color, size, SKU code) become text fields on the product row.

Cordial stores channel opt-in status as sub-attributes on contacts. Email opt-in maps to Mailchimp's global unsubscribe flag (Contacts who opted out in Cordial are unsubscribed in Mailchimp). SMS opt-in, if the customer activates Mailchimp SMS, maps to the SMS-specific consent flag. We export all channel preferences and map them to the appropriate Mailchimp subscription status field.

Cordial Segments are dynamic rules-based audiences built from contact attributes and event conditions. Cordial's API does not export segment definitions or the segment rules logic. We export which contacts currently match each segment (the membership snapshot) and document the rule definition for the customer's team to recreate in Mailchimp as a Group or an audience filter-based segment. Dynamic event-triggered segments have no direct Mailchimp equivalent and require rebuilding in Customer Journey Builder.

Cordial Programs organize campaign automation sequences. The API does not export workflow logic, triggers, or delay rules. We document the Program structure, trigger conditions, step sequence, delay rules, and action types for each active Program. The customer rebuilds them in Mailchimp's Customer Journey Builder using this documentation. We do not migrate automations as executable code.