Migrate from CASH to Mailchimp

Mailchimp stores all contacts under an Audience. Each source contact maps to a Mailchimp contact record within a target audience. The email address is the unique identifier; duplicate emails are rejected by Mailchimp's import API and surfaced for resolution before the run.

First name from the source contact populates Mailchimp's built-in FNAME merge field. If the source uses a different field name (e.g., given_name), FlitStack AI maps it during validation before the import runs. If a first name is missing, FlitStack leaves FNAME blank, ensuring the contact imports without errors. The validation step also confirms the field type is text and creates the merge field if it does not exist.

Last name from the source populates Mailchimp's LNAME merge field. If the source stores the name in a different field (e.g., surname), FlitStack AI maps it to LNAME during validation. When no last name is present, FlitStack leaves LNAME blank to allow the contact to import without errors, preserving all other data.

Email serves as the primary key in Mailchimp, and each contact must have a unique email address. FlitStack AI deduplicates by email before loading; when the same email appears across multiple source records, the profile with the most recent update timestamp wins and overwrites any earlier version. This ensures the final audience reflects the latest contact data while preserving the original create date for audit continuity.

Phone numbers map to Mailchimp's PHONE merge field if it already exists in the target audience. If the PHONE field has not been created, FlitStack AI provisions it during the setup phase before the migration run, using a text type to accept various phone formats. This ensures all contacts with a phone number on the source side are imported without skipping or erroring due to a missing field definition.

Company name maps to Mailchimp's built-in COMPANY merge field, attached to the contact record. Mailchimp does not have a separate Company object; organization data lives as a field on each contact. If the source stores the company in a differently named field, FlitStack AI maps it to the COMPANY merge field during validation, and creates the field if it does not exist in the target audience before import.

Source tags map one-to-one to Mailchimp tags, preserving every tag assigned to a contact. Tags are imported after all contacts have been loaded, preventing orphaned tag assignments. When tag names contain special characters, FlitStack AI sanitizes them to Mailchimp's allowed character set, replacing or removing unsupported symbols. This ensures consistent tagging and avoids import errors caused by invalid tag names.

Contacts marked as subscribed in the source are imported as subscribed in Mailchimp, maintaining their active status. FlitStack AI identifies contacts with bounced or permanently failed email addresses in the source and excludes them from the import to protect your Mailchimp deliverability scores. This prevents sending to invalid addresses and helps preserve sender reputation from the start of the new audience.

Unsubscribed contacts from the source are loaded into Mailchimp's suppression list instead of the active audience, ensuring they cannot receive any future campaigns. This approach prevents accidental re-sending to opted-out individuals, maintains compliance with email marketing regulations, and protects your sender reputation by keeping suppressed contacts out of the regular audience from the outset.

Hard bounces and soft bounces from the source are imported as suppression entries in Mailchimp, which automatically blocks any sends to those contacts. FlitStack AI flags permanently bounced emails before loading, enabling you to exclude them from the import entirely and protect your sender reputation. This ensures that only valid, deliverable contacts enter the active audience, reducing the risk of future bounce penalties.

Source custom properties are mapped to Mailchimp merge fields, with each data type—text, number, date, or address—requiring a matching merge field in the target audience before migration begins. FlitStack AI analyzes the source schema, creates any missing merge fields during the setup phase, and validates field types to ensure compatibility. This pre‑migration field provisioning prevents import errors and guarantees that all custom data is transferred correctly.

Pick-list values in the source are mapped to Mailchimp merge field options of the matching type, such as radio or dropdown. If the source contains values not yet defined in Mailchimp, FlitStack AI adds those missing options to the merge field during setup. This ensures all pick‑list data transfers without dropping any values, and validation confirms that option labels match before the import runs.

Mailchimp records open and click activity at the campaign level rather than as a per‑contact timeline, so historical engagement data cannot be imported as structured contact fields. FlitStack AI exports the engagement history to a CSV file for manual lookup. This reference preserves the original data for reporting continuity while keeping the Mailchimp contact profile clean.

Campaign send history does not transfer to Mailchimp because Mailchimp stores campaign records independently of contacts. FlitStack AI exports the source campaign names, send dates, and IDs to a CSV file that can be used as a reference when rebuilding campaign records in Mailchimp. Your team can use this reference to recreate campaign structures, schedules, and audience targets manually, ensuring reporting continuity where needed.