Migrate from Curve Dental to Mailchimp

The core mapping. Each Curve Dental patient record maps to one Mailchimp contact. The patient's email address becomes the Mailchimp EMAIL field — this field is mandatory for a Mailchimp subscriber. Patients without email addresses in Curve are flagged and excluded from the migration, as Mailchimp cannot create a subscriber record without an email.

Direct map to Mailchimp's built-in FNAME merge field. Mailchimp automatically creates FNAME on every audience. We populate it from Curve's patient first name field. No custom merge field creation required. This field serves as the primary identifier for each subscriber and is used in email greeting personalization. Because FNAME is native, no manual setup in Mailchimp is needed before migration. The exact first name string is transferred, preserving original capitalization.

Direct map to Mailchimp's built-in LNAME merge field. Same treatment as FNAME — Mailchimp provides this field natively, so no schema setup is required on the Mailchimp side before migration. This field holds the patient's last name and appears in email greeting personalization alongside FNAME. Because LNAME is a standard Mailchimp merge tag, we copy the last name string from the Curve patient record, preserving capitalization and hyphens if present.

The email address from Curve Dental maps to Mailchimp's EMAIL field — the primary identifier for every Mailchimp subscriber. This field is required. If Curve stores multiple email types (home, work) we map the primary email and surface secondary emails as a custom merge field.

Mailchimp's PHONE merge field is not created by default on new audiences — we create it as a custom merge field during migration setup and populate it from Curve's patient phone number field. This enables SMS follow-up and phone-based segmentation in Mailchimp.

Mailchimp provides a native structured ADDRESS merge field that includes addr1, addr2, city, state, zip, and country subfields. Curve Dental stores each address component in separate fields. We combine Curve's street address lines, city, state, and postal code into Mailchimp's ADDRESS format, mapping each element to the correct subfield. This conversion enables geo‑based segmentation, location‑aware campaigns, and Mailchimp's direct‑mail integration.

Curve Dental custom fields on patient records (e.g., preferred contact method, referral source, insurance carrier, last visit date) become Mailchimp custom merge fields. We create each custom field in Mailchimp before migration, matching the data type — text fields stay text, date fields become date-type merge fields. This is the primary driver of migration complexity for practices with many custom fields.

Curve Dental practices with multiple locations have separate patient rosters per location. Mailchimp has no native 'practice' object — we map each location's patient list to a separate Mailchimp audience named by location. The audience name serves as the practice identifier in Mailchimp. Multi-location practices get one audience per location.

Upcoming appointment dates and recall intervals from Curve do not map to any native Mailchimp object. We can optionally tag patients in Mailchimp with recall categories (e.g., 'hygiene-6month', 'perio-3month') as informational tags, but Mailchimp automation triggers for recalls require manual rebuild in Mailchimp's automation builder.

Insurance information such as carrier name and plan type is stored in Curve Dental but has no corresponding native field in Mailchimp. We create a custom text merge field—named INSURANCE__c—and populate it with the carrier and plan details from each patient record. This field lets the practice segment its Mailchimp audience by insurance carrier, run targeted campaigns that reference benefits, and tailor messaging based on the patient's plan.

Charting data, periodontal measurements, treatment plans, x-rays, and clinical notes are dental-specific clinical records. Mailchimp has no schema to receive this data — these records are excluded from the migration. The practice should retain access to Curve or an alternative clinical system for clinical records.

Billing ledgers, payment history, and accounts receivable balances stored in Curve Dental have no matching object in Mailchimp's contact schema, which only supports subscriber profile fields and tags. Consequently, this financial information stays in Curve and is not transferred during migration. Practices needing billing data for reporting or collections should keep their Curve Dental account or export the records separately. The migration scope focuses on patient contact information.

Mailchimp's subscriber metadata does not expose original create date. We store Curve's patient creation timestamp as a custom datetime merge field (ORIG_DATE__c) so the practice can report on list vintage and sort contacts by when they first entered the system.