Migrate from LEAP to Mailchimp

LEAP Client records map 1:1 to Mailchimp Subscribers. The subscriber hash is computed from the lowercase email address. The hash (MD5 of the lowercased email) is stored for later deduplication and can be referenced during reconciliation. Clients with no email address are flagged for manual review before migration—Mailchimp requires a valid email for every subscriber record.

Each LEAP custom field on a Client record becomes a Mailchimp Merge Field scoped to the target Audience. Text fields map directly; pick-list fields require per-value mapping rules. Date fields become Mailchimp date-type merge fields. Boolean fields become text merge fields with Yes/No values.

LEAP client status values (Active, Inactive, Archived) map to Mailchimp subscriber statuses (subscribed, unsubscribed, cleaned). Active clients become subscribed; archived clients become unsubscribed with a tag indicating archived origin. This prevents mailing to inactive clients while preserving the original status for reference.

LEAP Matters have no direct Mailchimp equivalent—Mailchimp Subscribers do not support matter associations natively. We create Mailchimp Tags from Matter names or numbers so users can segment by case type. For example, matter 'Family Law-Divorce-2024' becomes tag 'FamilyLaw'. Matter IDs are stored in a read-only merge field for traceability.

LEAP's responsible attorney field maps to a custom Mailchimp merge field (ATTORNEY) that stores the attorney's name. If attorney-to-subscriber assignment is needed for routing, tags can be applied per attorney. No Mailchimp native equivalent for user ownership exists—tags handle the association.

LEAP client email maps directly to Mailchimp's required EMAIL field. Email addresses are normalized (lowercased, trimmed) before computing the subscriber hash. Duplicate email addresses across LEAP clients are flagged—Mailchimp does not allow two subscribers with the same email address. When duplicates are detected, the most recently modified LEAP record is kept as the active subscriber, and the others are listed in a deduplication report for manual review.

LEAP client phone numbers map to Mailchimp's PHONE merge field. International phone formats are preserved as entered in LEAP. If LEAP stores separate mobile and work phone fields, both map to PHONE with a custom separator or as separate merge fields.

LEAP address components map to Mailchimp's structured ADDRESS merge field group. Street address splits into ADDR1 and ADDR2; city, state, postal code, and country map individually. If LEAP stores a single address string, it is parsed and split by common delimiters before loading.

LEAP trust account transactions have no Mailchimp equivalent—Mailchimp is not a financial record system. Trust balances and transaction history are exported as a separate CSV report for the firm's records. They are not loaded into Mailchimp as subscriber data. Optionally, the current trust balance can be saved as a read‑only merge field on the subscriber record for internal reference, but it is not used in Mailchimp campaigns.

LEAP documents attached to Client records cannot be migrated to Mailchimp's file hosting (30MB per file limit). We extract document metadata (filename, type, matter reference) and store it in a custom merge field (Client_Docs__c) as a reference list. Actual documents remain in LEAP or an alternative document storage system.

LEAP billing records, invoices, and payment history do not map to Mailchimp. Mailchimp is not a legal billing platform. Outstanding balance or last invoice date can be stored as a read-only custom merge field if needed for client communication segmentation, but financial records remain in LEAP or the firm's billing system.

LEAP staff users who will receive Mailchimp login credentials can be optionally migrated as Tags indicating internal staff status. This is only relevant if the firm wants to segment Mailchimp audiences between client subscribers and internal staff contacts. Most migrations omit this mapping.