Migrate from Atomic CRM to Mailchimp

Atomic CRM Contacts map to Mailchimp Members via the Marketing API Members endpoint. Email address is the dedupe key. Standard fields (first name, last name, email, phone) map to FNAME, LNAME, EMAIL, PHONE merge fields. Any additional columns in the contacts Postgres table that are not standard Mailchimp fields are created as custom merge fields during migration setup. Status (subscribed/unsubscribed/cleaned) is inferred from the source record's email_verified and unsubscribed_at flags in Supabase.

Company records in Atomic CRM have no direct Mailchimp equivalent. We map Company name to the COMPANY merge field, and Company sector, size, website, and linkedin_url into additional merge fields or Tags. If a Contact has multiple associated Companies, we use the primary Company as the merge field source and add secondary company names as Tags for reference. Company-based segmentation in Mailchimp is achieved through tag filtering or group assignment rather than a native relationship.

Mailchimp has no Deals or Opportunities object. Deal records from Atomic CRM are encoded as Tags on the associated Contact member — for example, Tag: deal-stage=proposal-sent, Tag: deal-value=4500, Tag: deal-owner=alex. The actual deal amount and stage are not native fields; they live as tag metadata. If multiple Deal pipelines exist in Atomic CRM, we namespace tags by pipeline name (pipeline-saas:stage=negotiation) to preserve context. This encoding is documented during migration and the customer can choose to build a complementary external pipeline tracker if deal management is mission-critical.

Atomic CRM Notes are free-text records linked to Contacts or Deals. Mailchimp has no native Notes object. We capture Notes as formatted Tags on the Contact (e.g., Tag: note=discussed-renewal-terms, Tag: note-date=2026-03-01) or as a written note attachment that the customer reviews post-migration. For migrations where note content is business-critical, we export a separate JSON sidecar file containing note text, timestamp, and author so the customer can load it into a wiki, Notion, or document management system alongside Mailchimp.

Task records from Atomic CRM (Call, Email, Meeting types configured in CRM component props) have no Mailchimp equivalent. Task type and status are encoded as Tags on the Contact member: e.g., Tag: task-type=call, Tag: task-status=completed. The actual task body, due date, and assignee do not map natively. For task-heavy migrations, we recommend a separate project management integration or a written task export for manual review in Mailchimp.

Every non-standard column discovered in the Postgres contacts, companies, deals, notes, or tasks tables during schema audit is created as a Mailchimp merge field before data import. Merge field types are inferred from Postgres column types: text columns become text merge fields, boolean columns become text (Yes/No), date columns become date merge fields. Mailchimp allows up to 40 merge fields per audience on Standard and Premium plans, and 20 on Essentials; we flag any migration that exceeds this limit and propose a consolidation strategy (combining related fields into tags).

Atomic CRM Owner references (hubspot_owner_id or auth UUID) on Contacts, Deals, and Tasks are resolved to the owner's email address during scoping. Owner identity is encoded as a Tag on the Contact member (e.g., Tag: [email protected]) so that deal and task attribution is preserved even without a native user management model in Mailchimp. The customer should map these owner tags to Mailchimp Groups if they need team-based campaign targeting.

Atomic CRM attachments stored in Supabase Storage buckets are not migrated into Mailchimp's file hosting. We export the Supabase Storage bucket contents separately (if present during scoping) and deliver a file inventory with a reference index linking each file to its source Contact record. The customer can host files externally and link to them from Mailchimp campaigns or the external reference document we deliver. Files stored outside Supabase (custom S3 buckets) require separate coordination and are outside standard migration scope.