Migrate from Customer.io to Mailchimp

Customer.io People records map to Mailchimp Subscribers. The userId becomes the subscriber email address as the primary identifier. All Customer.io traits (including nested JSON and arrays) flatten to Mailchimp merge fields (FNAME, LNAME, and custom MERGE1-MERGE8 fields). We map the created_at timestamp to the SUBSCRIBER_CREATED field and the last_seen or last_activity timestamp to the merge field capturing most recent engagement. Any inactive or deleted-within-billing-cycle profiles are excluded from the initial migration scope and reconciled against the billable profile count before cutover.

Customer.io's custom event tracking has no direct Mailchimp equivalent. We flag every distinct event name and property schema during discovery and deliver a written event inventory. The customer's team decides whether to: rebuild event-replacement automations in Mailchimp using tag-based triggers (e.g., tagging a subscriber when they complete a purchase via Shopify integration), accept the event data loss, or maintain a supplementary event-tracking tool. We do not migrate event records to Mailchimp as they cannot be stored natively.

Customer.io segments (dynamic audience definitions based on trait values and event conditions) cannot export as reusable objects. We export the segment criteria as a structured rule set including all condition groups, operator types, and values. A Mailchimp segment is rebuilt using Mailchimp's segment builder with attribute-based conditions (tag membership, merge field values, engagement history). We provide the segment rebuild document mapping each Customer.io segment to its Mailchimp equivalent with the specific builder steps required.

Customer.io multi-step Journeys with branching, wait steps, cross-channel triggers, and A/B testing have no migration path to Mailchimp's automation model. We export the campaign structure including trigger type, step sequence, branching logic, and channel assignments as a written document. Customer Journey Automations in Mailchimp (entry-triggered, with delays and conditional branching) serve as the rebuild target. The customer's marketing team or a Mailchimp partner reconstructs the active campaigns post-migration using the exported structure as a specification.

Customer.io one-time broadcasts map to Mailchimp Regular Campaigns. The broadcast name, target segment, subject line, from name, and content all migrate directly. If the broadcast was API-triggered, we note the trigger condition and whether it should become a Mailchimp Scheduled Campaign or an Automation trigger. Broadcast send timestamps and delivery statistics export as a compliance log.

Customer.io Custom Objects (Companies, Accounts) with their own attributes and relationships to People have no Mailchimp equivalent. We flatten the most relevant Company attributes (name, domain, industry, employee count) into merge fields on the Subscriber record. If the customer needs to preserve company-level data for reporting, we recommend using Mailchimp's built-in CRM features (available on Standard and Premium tiers) to tag and segment by company after migration, or maintaining a supplementary CRM.

Customer.io transactional messages (receipts, password resets, order confirmations) bypass standard unsubscribe rules. If the customer sends transactional email through Mailchimp, they need the Mandrill add-on (starting at $20/month). We export transactional message templates and note which ones are API-triggered versus scheduled. Delivery logs for transactional messages migrate as a compliance audit file. Note that Mailchimp Mandrill does not support SMS transactional messages; the customer needs a separate SMS transactional provider if SMS is required.

Customer.io email engagement logs (sent, delivered, bounced, opened, clicked) have no native Mailchimp activity history attached to subscriber records beyond standard open/click tracking. We export the engagement timeline as a compliance and audit CSV. If the customer wants to preserve engagement context in Mailchimp, we tag subscribers based on their engagement history (e.g., Power User, Inactive, Bounced) as part of the migration to maintain segment continuity.

Customer.io's topic-level subscription preferences (per-channel opt-in for email, SMS, push, in-app) map to Mailchimp's marketing permission flags. We map email_opt_out to the Email Marketing Permission, SMS consent to the SMS Marketing Permission, and flag push and in-app channels as unsupported (Mailchimp does not handle push or in-app). If the customer uses Customer.io's subscription_center preferences, we export the preference center configuration as a reference for rebuilding in Mailchimp's preference center.