Migrate from Jiva to Mailchimp

Jiva Contact maps directly to a Mailchimp contact profile within an Audience. Email address is the Mailchimp subscriber hash key — each Jiva contact's email field must be non-null and valid RFC 5322 format. Duplicate email addresses in Jiva collapse to a single Mailchimp subscriber; the most-recently-modified Jiva record by updated_at timestamp wins.

Jiva firstname maps to Mailchimp's built-in FNAME merge tag. If Jiva stores full name in a single 'name' field without a separate firstname, split on the first whitespace and map remaining characters to LNAME or a custom FULLNAME merge field.

Jiva lastname maps to Mailchimp's built-in LNAME merge tag. When Jiva has no separate lastname field, the substring after the first space in the full name populates LNAME; if no space exists, LNAME remains blank. This behavior ensures that names like 'Doe Jr.' or hyphenated surnames are preserved accurately when the space delimiter is present in the source data.

Jiva email address maps directly to Mailchimp's subscriber email address, which is hashed (MD5) to form the subscriber ID used for API operations. Mailchimp requires valid, RFC-compliant email addresses; role-based addresses (info@, support@) are allowed but flagged for suppression review to prevent bounces from generic inboxes.

Mailchimp has no built-in PHONE merge field by default. A custom PHONE merge field of type PHONE must be created in the Mailchimp audience before migration begins; E.164 formatting (+1XXXXXXXXXX) is preserved exactly as entered in Jiva without any reformatting or validation that could alter the original value.

Jiva Company (or Account) has no direct Mailchimp equivalent — Mailchimp has no account or organization object. We store the company name in a custom COMPANY merge field. If the Jiva account has multiple locations or sub-entities, each subsidiary name can become a Mailchimp Tag for segmentation rather than a separate merge field value.

Jiva contact's job title migrates to a custom TEXT merge field named JOBTITLE. Mailchimp does not have a native job title field, so this requires a pre-created custom merge field in the destination audience before data load. The TEXT type preserves all characters including commas, slashes, and parentheses commonly found in job titles.

Jiva's internal record ID is preserved as a custom TEXT merge field (SOURCE_JIVA_ID) on each Mailchimp contact. This enables traceability back to the source system and supports delta-run deduplication — if the same email appears in a subsequent Jiva export, the existing Mailchimp subscriber is updated rather than duplicated.

Jiva lifecycle or contact status pick-list values (e.g., Lead, Customer, Churned) map to both a custom TEXT merge field (LIFECYCLE_STAGE) and Mailchimp Tags per value. Tags enable segment-based campaigns in Mailchimp without requiring multiple audiences. Each unique Jiva status value generates a corresponding Tag name; the merge field preserves the raw value.

Jiva unsubscribe flags must route to Mailchimp's account-level suppression list, not as a per-contact field value. Contacts with unsubscribed=true in Jiva are excluded from the active migration batch and instead exported as a suppression-only import file (status=unsubscribed). Re-importing suppressed contacts as active subscribers requires Mailchimp support or a list re-upload after suppression removal.

Jiva deal and pipeline records have no Mailchimp equivalent. Mailchimp does not store deal amounts, stage names, or close dates. We export deal records as a separate CSV for your records; the data should be loaded into a dedicated CRM or analytics tool if needed post-migration.

Jiva's call logs, email threads, meeting records, and note history do not map to Mailchimp. Mailchimp tracks only aggregate open/click counts per subscriber going forward. Historical engagement data from Jiva should be exported separately and stored in your documentation archive.

Each Jiva contact custom field maps to a Mailchimp merge field. If Jiva has more than 40 custom fields on Contact, the excess must be prioritized by business value — low-importance fields can be collapsed into a JSON-encoded NOTES merge field or omitted from migration and documented for manual entry.

Mailchimp's native CreatedDate is the migration timestamp, not the original Jiva creation date. We preserve the original Jiva created_date as a custom DATE merge field (JIVA_CREATED_DATE) for reporting continuity — this requires a pre-created DATE-type merge field in the Mailchimp audience.

Jiva's owner or assigned-user field maps to a custom TEXT merge field (JIVA_OWNER) storing the owner's name or email. Mailchimp has no native concept of record-level ownership; this field is for reference only and does not affect Mailchimp permissions or send capabilities.