Migrate from My Dental Clinic to Mailchimp

Patient contact records in My Dental Clinic map directly to Mailchimp subscribers. Email address is the unique identifier on both sides. Each patient contact becomes one Mailchimp audience member. Patients without a valid email address are excluded from migration and flagged in the pre-migration report.

First name and last name migrate as native Mailchimp merge fields. These populate *|FNAME|* and *|LNAME|* personalization tags in email templates. Proper capitalization is preserved. Salutation fields (e.g., 'Dr. Smith') are stored as-is in the First Name field if no separate honorific field exists.

Email address is the primary key on both systems. Duplicate email addresses within the same Mailchimp audience are handled via the upsert logic: existing subscribers are updated, new ones are created. Mailchimp requires email addresses to be valid format — invalid addresses are excluded and logged.

Phone numbers migrate to the built-in Mailchimp PHONE merge field. SMS marketing consent must be managed separately in Mailchimp's compliance settings after migration — phone numbers are imported as non-SMS-consented by default unless your My Dental Clinic has a documented SMS opt-in.

Street address, city, state, ZIP code, and country migrate to Mailchimp's structured ADDRESS merge field. Mailchimp stores address as a compound field — we split My Dental Clinic address components into the correct sub-fields (addr1, city, state, zip, country) so geolocation segmentation and physical-mail automation triggers work correctly.

Date of birth migrates as a DATE-type merge field in Mailchimp. This enables birthday automation triggers in Mailchimp's Customer Journey builder — a common recall and re-engagement use case for dental practices. If My Dental Clinic stores DOB as a text field, we parse it to a valid date format before import.

Mailchimp does not have a native patient identifier field. We create a custom PATIENTID text merge field and populate it with My Dental Clinic's internal patient ID or chart number. This field enables reconciliation: if a patient updates their email in Mailchimp, you can still match them back to their original patient record using the ID.

Last visit date migrates as a custom LASTVISIT date merge field. This enables segmentation for recall automations — e.g., enroll all patients with LASTVISIT older than 6 months into a re-engagement campaign. We also derive a RECENCY_TAG (e.g., 'Active_30Day', 'Lapsed_6Month') and apply it as a Mailchimp tag during migration.

Upcoming appointment date from My Dental Clinic maps to a custom NEXTAPT date merge field. This supports pre-appointment confirmation automations in Mailchimp — your team can trigger a confirmation email X days before the scheduled date using Mailchimp's time-delay Customer Journey logic keyed on NEXTAPT.

Treatment history from My Dental Clinic does not map to a single Mailchimp field. We transform appointment records into Mailchimp tags: one tag per treatment event (e.g., 'Treatment_Cleaning', 'Treatment_Perio', 'Treatment_Whitening', 'Treatment_Implants'). The most recent treatment type also populates a TREATCAT merge field for profile-level segmentation. Tags enable behavioral cohort campaigns — separate email sequences for cleaning patients versus perio patients.

Insurance type or carrier name from My Dental Clinic maps to a custom INSURANCE text merge field. This supports segmentation for insurance-related campaigns (e.g., 'Your insurance covers preventive care' emails). Insurance claim history does not migrate — that is a billing record with no Mailchimp equivalent.

Active patients from My Dental Clinic map to Mailchimp subscriber status 'subscribed'. Inactive patients require a business decision: map to 'unsubscribed' (patient requested no contact) or keep as 'subscribed' with a PATIENTSTATUS custom field set to 'Inactive' for recall campaigns. We surface this mapping decision before the migration runs and apply your chosen rule consistently.

Clinical notes, periodontal charting, X-ray file references, and treatment plan details stored in My Dental Clinic have no equivalent in Mailchimp's data model. PHI and clinical notes must remain in My Dental Clinic for HIPAA compliance. We recommend exporting these as a separate PDF archive for record-keeping — they are outside the scope of a Mailchimp audience migration.

Billing ledgers, outstanding balances, payment history, and insurance claim records in My Dental Clinic do not map to Mailchimp. Mailchimp is a marketing platform, not a billing system. These records stay in My Dental Clinic or your dental-specific billing software. We can export billing contact fields (e.g., guarantor information) as standard contact fields — the financial records themselves are not touched.

Recall sequences and automated appointment reminders built in My Dental Clinic do not migrate. They must be rebuilt in Mailchimp's Customer Journey builder. The migrated RECENCY_TAG and LASTVISIT merge field serve as enrollment triggers: patients lapsed past a defined date automatically enroll in a re-engagement journey. We provide a rebuild reference document outlining your existing recall logic for your team to reconstruct.