Migrate from Bright to Mailchimp

Bright contacts map to Mailchimp audience members via email as the primary key. All standard contact fields (name, email, phone, job title, address) map to Mailchimp merge fields directly. Unsubscribed and bounced contacts route to the Mailchimp Suppression List and cannot be re-imported as new members.

Bright company records map to a COMPANY merge field on the contact record in Mailchimp. Bright supports N-to-N contact-to-company relationships; Mailchimp supports one primary company per contact. We use the most-recently-associated company as the primary value and surface remaining companies in a custom NOTES field or as tags for reference.

Bright deal records have no native Mailchimp equivalent — Mailchimp has no deal or opportunity object. We translate deal name, amount, stage, and close date into Mailchimp tags (e.g., deal-stage:Proposal Sent) and store numeric values in custom merge fields (e.g., DEAL_AMOUNT, DEAL_CLOSE_DATE). Rebuild deal pipeline tracking as Mailchimp segments post-migration.

Bright pipeline names and stage values map to a tag prefix scheme in Mailchimp (e.g., pipeline:Sales/stage:Negotiation). Mailchimp segments can filter by these tags and tag combinations to approximate a deal pipeline view, but this requires manual segment definition post-migration. We provide a tag-to-segment mapping plan as part of the delivery.

Bright engagement logs (calls, emails, meetings, notes) have no native Mailchimp equivalent for historical activity tracking. We preserve the most recent activity type, summary, and timestamp in a custom ACTIVITY_LOG merge field on the contact. Individual activity records aggregate into a plain-text history string. Ongoing activity tracking requires Mailchimp's built-in campaign engagement metrics post-migration.

Bright custom contact properties migrate to Mailchimp custom merge fields. Mailchimp supports text, number, date, phone, address, and URL merge field types. We create merge fields before migration based on Bright's property inventory. Merge fields exceeding Mailchimp's 30-field audience limit require tag-based fallback for overflow properties.

Bright contact tags transfer directly to Mailchimp tags. Tags preserve segmentation context across both platforms. Mailchimp supports unlimited tags per contact. Note that Mailchimp tag logic differs from Bright's label model — tag-based filtering in Mailchimp is case-sensitive and exact-match, which may require normalization during import.

Bright owner and user records do not map to Mailchimp users — Mailchimp is a single-tenant audience platform without multi-user CRM ownership. We store Bright owner name and email as a MAILCHIMP_OWNER merge field on each contact for reference. Ownership reassignment is not applicable in Mailchimp's model.

Bright file attachments on contact or deal records do not migrate. Mailchimp does not store file attachments on audience members. We create a FILE_REFS merge field listing original attachment names and storage locations so the files can be manually re-uploaded to Mailchimp's Content Studio or a linked storage system post-migration.

Bright subscription status maps directly to Mailchimp member status. Subscribed contacts import as 'Subscribed', unsubscribed contacts add to the Suppression List, and bounced contacts add to the Bounces suppression list. Suppressed contacts cannot be re-imported as new members — any re-subscription requires the contact to re-sign up through a Mailchimp signup form.

Bright lead scores and engagement scores have no native Mailchimp equivalent. We preserve the last-known score value in a numeric ENGAGEMENT_SCORE merge field. Mailchimp calculates its own engagement metrics (open rate, click rate) per campaign — the Bright score will not update automatically post-migration unless a sync integration is built.

Bright contact lists and groups map to Mailchimp Audiences. Each Bright list becomes one Mailchimp audience. If Bright uses multiple lists with overlapping contacts, we consolidate to a single Mailchimp audience using tags to distinguish list membership. Multiple overlapping audiences require tag-based segmentation to avoid contact deduplication conflicts.