Migrate from Enrich-CRM to Mailchimp

HubSpot Contacts enriched by Enrich-CRM export to Mailchimp as audience members. The HubSpot contact email becomes the Mailchimp subscriber identifier for deduplication. Enrichment data (title, seniority, LinkedIn URL, location, company name) maps to Mailchimp merge fields (FNAME, LNAME, PHONE, COMPANY, JOBTITLE, LINKEDIN) created during audience setup. We create custom merge fields for any enrichment-specific fields (seniority tier, enrichment_date, data_confidence_score) that have no standard Mailchimp equivalent. The mapping skips HubSpot contacts that bounced or unsubscribed — those records export to Mailchimp as suppressed addresses only.

HubSpot Company records enriched by Enrich-CRM do not map to a native Mailchimp object because Mailchimp has no Companies or Accounts. We denormalize company firmographics (industry, employee count, revenue tier, tech stack) onto the linked Contact record as custom merge fields or as a JSON-encoded custom field if the enrichment schema is complex. The HubSpot company domain becomes a COMPANY merge field on the Contact for segmentation and personalization. This denormalization is acknowledged during scoping — if the customer needs a true company object, Mailchimp is not the right destination.

Enrich-CRM job-change alerts are event records, not traditional CRM objects. We capture the most recent alert per contact as a Mailchimp note on the audience member (up to 500 characters per note). Historical alert timestamps are preserved as a custom merge field job_change_last__c. Ongoing job-change detection is not native to Mailchimp — we recommend either a re-enrichment tool post-migration or a Zapier path that tags contacts when a new enrichment provider detects a job change.

Custom lead scoring models and contact segments built inside Enrich-CRM are not accessible via API and cannot be exported. We document the scoring criteria during scoping through screen captures and customer interviews, then define equivalent Mailchimp segments using merge field values, engagement activity (opens, clicks, last campaign date), and tag combinations. The rebuild is a configuration task the customer's admin executes post-migration using our segmentation specification document. Segmentation rebuild is scoped separately from the data migration.

The HubSpot Company-to-Contact lookup relationship collapses during denormalization to Mailchimp. We preserve the company name as a merge field on the audience member and use it as a segment dimension (e.g., 'segment by company name' or 'segment by industry from enrichment'). This allows teams to still target by account in Mailchimp using tags or merge field filters without a native relationship model.

HubSpot Owners (sales reps) do not have a native Mailchimp equivalent. We map the HubSpot owner name to a Mailchimp tag (e.g., tag 'Owner: Jane Smith') on each audience member so sales teams can filter their audience by assigned rep. If the customer uses Mailchimp's customer journey automations for rep-specific nurture tracks, tags serve as the routing dimension. This mapping is optional and confirmed during scoping.

HubSpot contacts with a subscribed=false status or a bounce/failure engagement record export to Mailchimp as a suppression list. We format the suppression list as a CSV with email address and suppression reason (bounce, unsubscribe, manual suppress) and import it to Mailchimp before the main audience migration. This prevents bounced or opted-out contacts from receiving campaigns on day one and protects deliverability metrics.

If the customer used Enrich-CRM's API to attach custom metadata to enrichment results (e.g., enrichment_source_provider, enrichment_batch_id, data_freshness_score), we create equivalent custom merge fields in Mailchimp and populate them during import. Complex nested JSON metadata is stored as a single TEXT merge field. The merge field schema is defined during scoping and created in Mailchimp before migration begins.