Migrate from Leaf360 to Mailchimp

Leaf360 Contacts map 1:1 to Mailchimp Subscribers. The subscriber's email address is the unique key for de-duplication — if the same email appears in multiple Leaf360 records, FlitStack retains the most recently modified version and discards older duplicates. Subscribers receive a Member Status (subscribed, unsubscribed, or pending) that is derived directly from Leaf360's contact opt-in field during the transformation step before data loads into Mailchimp.

Leaf360's first-name property maps directly to Mailchimp's built-in FNAME merge field. If FNAME does not already exist in your target audience, FlitStack creates it via the Mailchimp API before the import run begins. Blank or null source values result in empty merge field values on the Mailchimp Subscriber — no default substitution or placeholder text is applied.

Leaf360's last-name property maps directly to Mailchimp's built-in LNAME merge field, following the same behavior as FNAME for blank or null values. Compound names stored in a single Leaf360 name field are split on the last space character during the transformation pass before data is submitted to Mailchimp.

Leaf360 phone numbers are mapped to Mailchimp's PHONE merge field without formatting changes. Phone number formatting is preserved exactly as stored in Leaf360 — no E.164 normalization is applied unless explicitly requested in your migration plan. Note that Mailchimp's PHONE field is a text-type merge field, not a structured phone type with validation.

The email address serves as the primary key for both Leaf360 Contacts and Mailchimp Subscribers. During migration, FlitStack performs de-duplication on email — if the same email address appears across multiple Leaf360 records, only one Mailchimp Subscriber is created and populated with the most recent contact data available.

Leaf360 address fields (street, city, state, zip, country) are flattened into Mailchimp's structured ADDRESS merge field group. The individual subfields map as follows: street routes to addr1, city to city, state to state, zip to zip, and country to country. If Leaf360 stores address data as a single combined text field rather than discrete components, that value routes to addr1 only.

Leaf360 contact tags carry forward as Mailchimp Tags on each Subscriber. Tag names containing special characters such as commas and quotes are URL-encoded during the import process to prevent parsing errors. Duplicate tag assignments are collapsed during import — a subscriber with the same tag applied multiple times in Leaf360 will appear with that tag only once in Mailchimp.

Leaf360 custom properties of type string, number, date, and picklist map to Mailchimp merge fields of matching type. Picklist values become dropdown merge fields with the same option set presented in Leaf360. All merge fields are pre-created in Mailchimp before the import run executes — your audience must have available merge field slots (Mailchimp allows a maximum of 40 per audience).

Leaf360's original contact create timestamp has no native equivalent in Mailchimp's standard data model. To preserve this historical context for reporting continuity, FlitStack creates a custom datetime merge field (SOURCE_DATE__c) on each Subscriber and populates it with the original Leaf360 createdate value extracted during the export phase.

The Leaf360 internal record ID is stored as a custom text merge field on each Subscriber for traceability across systems. This enables delta-run de-duplication — FlitStack's import logic skips any record whose SOURCE_LEAF_ID already exists in Mailchimp — and supports reconciliation queries between the source and destination platforms.

Mailchimp has no native Company object — all organization data lives on the Contact as merge fields. FlitStack creates a COMPANY text merge field on each Subscriber and populates it from the Leaf360 contact's primary company name association. Multi-company relationships in Leaf360 are collapsed to capture only the primary company on each contact record.

Leaf360 Deals (loan pipeline records with stage, amount, close date) have no Mailchimp equivalent. Loan-stage and deal-amount data does not migrate to Mailchimp — it remains accessible in Leaf360 or must be exported separately for reporting purposes outside Mailchimp. You may optionally store a deal reference ID as a custom merge field if needed for cross-system lookups in downstream tools.

Leaf360's loan-stage follow-up sequences and referral-automation workflows have no Mailchimp equivalent and cannot be imported. Unlike contact data, workflow definitions are proprietary platform objects that do not export to a portable format. FlitStack exports your Leaf360 workflow definitions as a JSON specification document that captures the automation logic, trigger conditions, time delays, and action sequences — your Mailchimp admin can use this as a rebuild reference when constructing Customer Journeys.