Migrate from Core Practice to Mailchimp

Core Practice patient records map 1:1 to Mailchimp contacts. The primary email address becomes the Mailchimp subscriber identifier. First name, last name, and phone map to standard merge fields. Archived or inactive patient status maps to Mailchimp's Archived status rather than unsubscribed.

The patient email field in Core Practice becomes the Mailchimp subscriber email. This is the unique key for deduplication — if a patient record has no email, FlitStack flags it for manual review before migration since Mailchimp requires an email address for subscribers.

Core Practice custom fields on patient records — such as referring dentist, preferred appointment time, insurance provider, or treatment interest — migrate to Mailchimp custom merge fields. Mailchimp requires merge field names to start with an asterisk and caps text at 255 characters; long-text fields require splitting or truncation.

Treatment categories from Core Practice (General Checkup, Orthodontics, Cosmetic, Emergency, etc.) become Mailchimp tags applied to each patient contact. Tags enable campaign segmentation — a牙齿美白 campaign can target only contacts with the Cosmetic tag. Multiple treatment types per patient become multiple tags.

Core Practice patient status values (Active, Inactive, Archived) map to Mailchimp subscriber statuses. Active maps to Subscribed, Inactive maps to Archived, and Archived maps to Archived. Unsubscribed patients in Core Practice are handled as unsubscribed in Mailchimp to preserve suppression lists.

The assigned dentist or hygienist on a Core Practice patient record has no direct Mailchimp equivalent. FlitStack creates a PRACTITIONER merge field on each Mailchimp contact and populates it with the practitioner name or ID from Core Practice. This enables segmenting campaigns by assigned provider if needed.

Core Practice stores the last completed appointment date per patient. Mailchimp has no native date field — this migrates as a text-formatted merge field (LAST_VISIT_DATE) in YYYY-MM-DD format. The value enables recall and reactivation segment logic in Mailchimp but requires manual segment-building since Mailchimp treats it as text.

Core Practice appointment records — including date, time, provider, procedure codes, and treatment notes — have no equivalent in Mailchimp's audience model. These are operational data that Mailchimp cannot represent. FlitStack preserves appointment context via treatment-category tags and last-visit date but does not migrate individual appointment records.

Clinical treatment plans, clinical notes, medical history, and radiograph references stored in Core Practice cannot migrate to Mailchimp. Mailchimp is an email marketing platform, not a clinical record system. These must remain in Core Practice or a dedicated clinical records system. FlitStack discloses this as a data boundary upfront.

Core Practice invoice records, payment history, and outstanding balance data have no Mailchimp equivalent. Mailchimp's data model does not support financial records. This data remains in Core Practice for billing purposes and is referenced separately from the email marketing audience.

Patient recall reminders, appointment confirmation automations, and treatment-follow-up workflows built in Core Practice do not transfer to Mailchimp. FlitStack exports a list of Core Practice automation triggers (such as recall intervals per treatment type) as a reference document for rebuilding in Mailchimp's automation builder.

Multi-location dental practices using separate Core Practice accounts per location can create separate Mailchimp audiences per location (preferred for isolated patient lists) or use a LOCATION tag within a single audience (preferred for centralized reporting). FlitStack surfaces this decision before migration and applies the chosen structure consistently.