Migrate from MetroLeads to Mailchimp

MetroLeads Leads map to Mailchimp Contacts in the destination Audience. The Lead email address becomes the Contact email (required for Mailchimp). The Lead name field splits into Mailchimp FNAME and LNAME merge fields. We resolve lead_fields by fetching MetroLeads property IDs, mapping them to named Mailchimp merge field variables, and loading the values during contact import. Any MetroLeads Lead without an email address is held in a quarantine list for the customer to enrich before re-import because Mailchimp requires an email address on every Contact.

MetroLeads Companies have no direct Mailchimp equivalent. Mailchimp Audiences are flat contact lists without a native Companies or Accounts concept. We offer two strategies during scoping: (1) create one Mailchimp Segment per MetroLeads Company and assign Leads to the segment by Company lookup; (2) store Company name as a custom merge field on each Contact and use Mailchimp's segmentation builder to filter by company. Strategy 1 preserves grouping; Strategy 2 preserves the Company name as queryable data without a separate object. The customer chooses during scoping.

MetroLeads embedded phone arrays (with type metadata: Work, Mobile, Fax) on Lead records flatten into Mailchimp's PHONE merge field. MetroLeads supports multiple phone numbers per Lead; Mailchimp supports one phone merge field per Contact. We load the primary phone (type = Mobile preferred, then Work) into the PHONE merge field and append any secondary numbers as a text note in the Contact record or as a separate merge field if the plan allows.

MetroLeads embedded email arrays (with type metadata: Work, Personal) on Lead records: the Work email becomes the primary Contact email address in Mailchimp. If a Lead has multiple emails and the primary is Work, we load Work as the main address. Personal email is stored as a merge field if needed for segmentation. Mailchimp requires one email per Contact; Leads with no email are excluded from migration and flagged for enrichment.

MetroLeads Lead state is a tenant-configured string field (e.g. new, contacted, qualified, lost) that varies per MetroLeads instance. We extract all unique state values during the export scan and present them to the customer for mapping to Mailchimp's lifecycle stages (subscriber, customer, churned, or a custom tag-based stage system). Unmapped state values are flagged so no Lead is orphaned with a null lifecycle mapping during import. This design step prevents Leads from landing in Mailchimp without a disposition category.

MetroLeads source_tags (string arrays indicating disposition: e.g. disposition_answered, disposition_no_answer) map directly to Mailchimp Tags. Tags are flat string labels in Mailchimp; we preserve the raw tag string from MetroLeads without renaming so that existing segmentation logic based on tags translates directly. Tags load as part of the contact import batch via Mailchimp's Tags parameter on the Contact API or the tags column in CSV import.

MetroLeads lead_fields store custom property values keyed by internal property IDs (e.g. customer_id_070). We fetch the MetroLeads property schema first, build an ID-to-name mapping, and create Mailchimp merge fields with the corresponding human-readable names before import. MetroLeads custom properties that exceed Mailchimp's merge field limit (30 on Essentials/Standard, 80 on Premium) are prioritized by the customer during scoping; lower-priority fields are stored as a JSON blob in a NOTES merge field for manual extraction post-migration.

MetroLeads Events (calls, emails, meetings, tasks tied to Leads) have no direct Mailchimp equivalent because Mailchimp tracks engagement per campaign (opens, clicks, unsubscribes) rather than as a universal activity timeline. We extract event_type and event timestamp during export. Call and meeting events with notable disposition data (e.g. call_outcome, meeting_result) are stored as Tags on the Contact record for post-migration visibility. Email events migrate as Mailchimp tracks opens and clicks natively once the contact list is active in Mailchimp campaigns.

MetroLeads assigned_to user references on Lead records map to a Mailchimp merge field (e.g. SALES_OWNER) that carries the owner's name or email. Mailchimp does not have a native Owner concept equivalent to CRM user assignments. We store the owner name as a read-only merge field so that the customer's sales operations team can filter contacts by owner in Mailchimp segmentation without rebuilding a separate assignment system.

MetroLeads lead_group is a UUID-based grouping concept that clusters related Leads. Mailchimp Segments serve a similar grouping function for contact segmentation. We export the lead_group UUID as a custom merge field (LEAD_GROUP_ID) and create a corresponding Mailchimp Segment per unique group UUID so that related Leads stay associated post-migration. The customer can rename Segments to meaningful names after migration.