Migrate from monday CRM to Mailchimp

monday CRM People records map directly to Mailchimp Audience members. The monday person name becomes First Name and Last Name merge fields (or a combined Name field if the source uses a single-name format). Email address serves as the Mailchimp subscriber hash dedupe key. We preserve any CRM property values (phone, company, title, location) as additional merge fields. Subscriber status in Mailchimp defaults to subscribed for all migrated contacts unless the monday CRM record has an explicit unsubscribe or bounced status that we carry over.

monday CRM custom column values of text, number, date, phone, and currency types map to Mailchimp merge field equivalents. TEXT columns become text merge fields, numeric columns become number merge fields, date columns become date merge fields, and phone columns become phone merge fields. We pre-create the merge field schema in the destination Mailchimp audience before import. Column types with no Mailchimp equivalent (formulas, dependencies, links) are flagged in the mapping document for manual note addition or exclusion.

monday CRM Deals attached to a Pipeline do not have a direct Mailchimp equivalent because Mailchimp does not have a deal value or weighted pipeline concept (unless the customer licenses Mailchimp CRM Premium). We map deal data as tags on the subscriber record: the pipeline name becomes a tag prefix (e.g., Sales Pipeline), the deal value is stored as a tag value or merge field (deal_value__c), and the stage name becomes a tag (e.g., Stage: Qualified). If the customer has Mailchimp CRM, we evaluate mapping Deals to Mailchimp Deals instead.

Each monday CRM Pipeline Stage maps to a Mailchimp tag with a consistent naming prefix (e.g., Pipeline Stage: Discovery, Pipeline Stage: Proposal, Pipeline Stage: Closed Won). Tags allow the customer to segment audiences by deal stage for targeted re-engagement campaigns. We preserve the original stage probability percentage as a merge field (stage_probability__c) if the customer requests it for campaign personalization.

monday CRM CRM boards do not map to a single Mailchimp object. We document each CRM board as a written inventory item recommending whether to create a separate Mailchimp audience (for boards representing distinct business units or client lists) or to use tags for board-level segmentation within a single audience. The customer decides the audience strategy during scoping.

monday CRM Items on a non-CRM board (i.e., contacts stored as Items rather than People) are enumerated and merged into the contact migration. We flag Item-sourced contacts versus People-sourced contacts during scoping so that the customer understands whether the bulk export covers their full contact list or whether an additional API enumeration step is required. Item name becomes the contact Name; any person-type column on the item captures email and phone.

monday CRM Subitems are not included in the bulk account export or per-board Excel export. We enumerate subitems via the monday.com API using each parent Item's ID, which multiplies API call volume. Subitems (commonly used for line items, related activities, or task breakdowns) do not have a native Mailchimp equivalent. We map subitem names as tags on the parent contact (e.g., Related Activity: Proposal Call) or document them in a written inventory for manual follow-up if the information is not mission-critical.

monday CRM Users assigned as owners of People records or Deals are enumerated during scoping. We match by email and apply a tag to each owned contact (e.g., Owner: [email protected]) so that the customer can segment by account owner in Mailchimp for owner-specific campaigns. Mailchimp does not have a user or team member object; ownership is represented through tagging only.

monday CRM Updates on People records (comment threads, internal notes) can be exported per person via the monday.com API. Mailchimp does not have a native comment or note object on individual members. We migrate update text as Mailchimp notes on the member record, preserving the original timestamp. High-volume update threads (many comments per contact) are summarized rather than fully replicated to avoid API bloat.