Migrate from Dr.DENTES to Mailchimp

Dr.DENTES patient records map to Mailchimp contacts. The patient's email address is the primary key — contacts without a valid email are excluded from the Mailchimp audience since Mailchimp requires an email for each subscriber. We also verify email format and flag duplicates during the import process to maintain list hygiene.

Standard first name merge field. Mailchimp uses FNAME by default; we map Dr.DENTES firstname directly. If Dr.DENTES stores full_name in one field, we split on the first space. The split logic also handles common suffixes like Jr. or III, ensuring accurate first name extraction.

Standard last name merge field. Mapped directly when present as a separate field in Dr.DENTES. If full_name only, we extract the portion after the first space delimiter. We also trim trailing punctuation and handle hyphenated surnames for consistency across the audience.

Email is the sole join key between systems. We validate email format before import, flag malformed addresses, and route them to a separate correction file for your team to review. The validation includes checks for domain MX records, ensuring that imported addresses are likely to receive campaign emails.

Phone number maps to Mailchimp's PHONE merge field. If Dr.DENTES stores phone in multiple formats (with/without country code), we normalize to E.164 format before import. Normalization removes extraneous characters, adds the leading plus sign when missing, and pads country codes for consistent display across devices.

Dr.DENTES address components (street, city, state, zip) map to Mailchimp's compound ADDRESS field. All four sub-fields are required for Mailchimp to render address personalization blocks. If any sub-field is missing in Dr.DENTES, we flag the contact in the pre‑migration data‑quality report and leave the corresponding Mailchimp sub‑field blank.

Patient status in Dr.DENTES (active, inactive, archived) maps to Mailchimp tags: 'active_patient', 'inactive_patient', 'archived_patient'. Tags drive segmentation for recall campaigns and re‑engagement sequences. These tags are applied during import and can be updated automatically as patient status changes in Dr.DENTES via scheduled delta syncs.

Treatment history from Dr.DENTES is serialized as text in a custom Mailchimp merge field (TREATMENT_HISTORY__c). Mailchimp cannot store clinical procedure objects natively — the field preserves reference data for staff reviewing the contact in Mailchimp. The serialized format includes procedure codes, dates, and outcomes, providing a quick clinical snapshot without exposing sensitive details in campaigns.

Recall dates in Dr.DENTES map to a custom Mailchimp date field (RECALL_DATE__c). This field can be used to trigger Mailchimp Automation Flows for recall campaigns based on the patient's next scheduled visit window. Automation triggers evaluate the RECALL_DATE against current date to fire timely reminders, and can include follow‑up actions if the date passes without a recorded visit.

Dr.DENTES email_opt_in flag determines whether the contact lands as 'subscribed' or 'non-subscribed' in Mailchimp. True maps to subscribed; false maps to a non‑marketing contact status pending explicit re‑permission. We also record the original opt‑in timestamp from Dr.DENTES as a custom field to preserve consent history for compliance audits.

SMS consent from Dr.DENTES maps to a custom Mailchimp field (SMS_PERMISSION). Mailchimp SMS requires separate setup through its integration with Mailchimp SMS; this flag is informational until the SMS product is activated. When the SMS product is enabled, the SMS_PERMISSION field can be used to respect patient preferences within Mailchimp's SMS campaigns and compliance checks.

Insurance carrier name from Dr.DENTES maps to a custom text field (INS_PROVIDER__c). Stored for reference only — Mailchimp campaigns do not use insurance data, but having it in the contact record avoids re‑querying Dr.DENTES for administrative communications. The field can be displayed in internal staff reports and used to segment patients by insurance plan for targeted billing outreach.

Patients marked as do_not_contact in Dr.DENTES are imported into Mailchimp's suppression list rather than the active audience. Suppressed contacts cannot be re‑added to campaigns, protecting your sender reputation from accidental re‑engagement. Mailchimp's suppression list persists across imports, so future uploads automatically skip these addresses, and you receive alerts for any bounce events that require manual cleanup.

Dr.DENTES appointment reminders, recall sequences, and follow‑up task triggers have no Mailchimp equivalent. These must be rebuilt as Mailchimp Automation Flows. FlitStack exports your Dr.DENTES workflow definitions as a rebuild reference document for your team or a Mailchimp specialist. The reference includes trigger conditions, timing intervals, and associated contact tags, giving your specialist a clear blueprint for recreating patient communication sequences in Mailchimp.