Migrate from Unim to Mailchimp

Unim Contacts map to Mailchimp Members within a single target Audience. Email address serves as the primary dedupe key. First name and last name map to FNAME and LNAME merge fields. We resolve any null email addresses and flag them for the customer's admin before import to prevent silently skipped records. Opt-in status migrates from Unim's subscription property or lifecycle stage to Mailchimp's Subscribed status; unsubscribed contacts from Unim are exported as a suppression list and imported separately to protect deliverability.

Unim Companies do not have a direct equivalent in Mailchimp's flat audience model. Company name maps to a text merge field (COMPANY) on the Member record. If the migration scope includes company-level data that needs to remain queryable, we discuss splitting into multiple Audiences (one per company) or using Tags (tagged by company name) for segmentation. The customer's admin chooses the strategy during scoping.

Each Unim custom field discovered during schema introspection is classified by datatype: text fields under 255 characters map directly to Mailchimp text merge fields; text fields over 255 characters are truncated with a note to the admin or migrated as Tags; date fields map to Mailchimp date merge fields; numeric fields map to number merge fields; phone fields map to the PHONE merge field. Fields with complex datatypes (dropdowns, multi-selects) map to Mailchimp Tags with the value as the tag name.

Unim Owner IDs are instance-scoped and not portable. Mailchimp does not have a record-owner model comparable to CRM platforms. We extract owner names as a text merge field (OWNER) for reference, but no user mapping occurs. Owner records requiring preservation are documented for the customer's admin to cross-reference manually in Mailchimp.

Unim activity records (calls, emails, meetings, tasks, notes) are CRM-native engagement objects with no equivalent in Mailchimp's audience model. Mailchimp tracks opens, clicks, and campaign sends but not a contact-level activity timeline. We do not migrate activity history. We deliver a written export of the engagement volume per Contact for the customer's awareness and for potential re-entry in a supplemental CRM if needed.

Unim attachments are served via the Files dimension with separate binary extraction calls. Mailchimp does not store file attachments on Member records. We extract attachment metadata (filename, URL, linked Contact) and deliver it as a CSV inventory. The customer's admin decides whether to re-upload assets to a CMS or cloud storage and link them manually.

Unim bespoke object types discovered during schema introspection that have no direct Mailchimp equivalent are classified: if the object has a 1:1 relationship with Contact (e.g., Subscription, Membership), the fields migrate as merge fields on the Member; if the object has a 1:N relationship (e.g., multiple Policy records per Contact), we migrate the primary record as merge fields and the related records as a JSON payload in a custom field or a separate CSV inventory. Complex relational schemas are documented for rebuild in a supplemental CRM.

Unim tag associations stored as linked records or array fields migrate to Mailchimp Tags on the corresponding Member. Tags serve as the primary segmentation mechanism in Mailchimp and support multi-value assignment per Member. We preserve the full tag-to-record linkage as a tag assignment payload during import.