Migrate from Case.one to Mailchimp

Many-to-many contact-company associations collapse to a single firm field

Case.one allows a single contact to link to multiple law firms or client companies simultaneously via its junction model. Mailchimp's audience structure is a flat subscriber list — there is no junction table, no equivalent of a contact-company many-to-many relationship. We resolve this by setting the most recently modified company as the primary CONTACTFIRM merge field and adding each additional firm as a tag (AdditionalFirm:{name}). Your Mailchimp segmentation will see only one firm per contact unless you filter by tags, so matter-specific firm assignments may require a custom segment builder that includes the AdditionalFirm tags. This is a structural difference between platforms that cannot be eliminated — it must be accounted for in your segmentation strategy.

Custom fields without a merge field equivalent become tags, limiting segmentation depth

Mailchimp supports a fixed set of merge field types: text, number, date, phone, address, birthday, website, and image. Case.one custom contact fields that use structured types — multi-select pick-lists, boolean checkboxes, long text, or JSON-typed fields — cannot map to a Mailchimp merge field and must become tags. Tags in Mailchimp enable basic segmentation (subscriber has tag X) but do not support value-based filtering the way merge fields do (e.g., filter by amount > $5,000). If your Case.one custom fields include financial thresholds, complex status codes, or multi-value arrays, those will land as tags and you will need to rebuild that segmentation logic in Mailchimp using tag-based conditions or re-import the underlying data as merge fields manually post-migration.

Matter-relationship context is stored as reference tags, not linked records

Case.one's contact-matters junction table is central to its data model — a contact can be associated with dozens of open and closed matters. Mailchimp has no concept of a many-to-many junction between subscribers and external entities. We store each matter relationship as a CaseMatterID:{id} tag on the subscriber. This preserves the relationship as a reference ID, but it does not enable Mailchimp to filter subscribers by matter name, matter stage, or responsible attorney in the way Case.one does natively. You can build a Mailchimp segment that filters on CaseMatter:{name} tags, but the segmentation builder will show tags rather than a structured relationship picker — your team will need to construct segment conditions manually for each matter-based group you want to target.

API rate limits on Case.one require batch extraction spread over multiple hours

Case.one's API enforces rate limits on contact export endpoints. For audiences over 10,000 contacts, we must paginate extraction across multiple API sessions, which extends the data pull from minutes to hours. The delta-pickup window is calculated after the initial bulk extraction completes — any records modified in Case.one during the extraction window are pulled in the final delta run. If your firm has a high volume of active contacts being modified during business hours, the delta window may need to be extended to capture those changes. We coordinate the extraction window with your team to minimize the gap between initial pull and final delta.

Duplicate contact handling requires a pre-migration dedup decision

Case.one does not enforce email uniqueness at the contact level — the same email address can appear on multiple contact records (e.g., a paralegal who is also listed as a billing contact, or a shared firm inbox used across multiple matters). Mailchimp requires a unique email per subscriber. Before migration, your team must decide how to handle duplicates: merge them into a single subscriber with tags from all associated matters, or keep them as separate subscribers with different subscriber IDs. We surface all duplicate email pairs in a pre-migration report and apply your chosen rule before the full load runs. This decision affects downstream segmentation and email deliverability, so it should be made before the migration date.