Migrate from Dentally to Mailchimp

Dentally patient records map directly to Mailchimp contacts within an audience. The patient's email address is the primary identifier for Mailchimp — patients without an email address on file in Dentally are flagged and held from the initial import batch until a valid email is supplied or a fallback workflow is established.

Standard first name maps to Mailchimp's built-in FNAME merge field for immediate contact identification. If Dentally stores the full name in a single 'name' field rather than separate first and last name fields, FlitStack AI splits on the first space delimiter to extract the first name component before writing the import file. This ensures consistent naming across the migrated audience.

Standard last name maps to Mailchimp's built-in LNAME merge field for contact records. Compound surnames and multi-part last names such as 'Van der Berg' or 'Macdonald' are preserved exactly as stored in Dentally — no additional parsing is applied unless a recognized prefix is detected that can be cleanly demarked from the surname.

Patient email address maps to Mailchimp's required EMAIL field, which serves as the unique identifier for each contact. Mailchimp enforces a strict one-email-per-contact rule — patients with multiple email addresses recorded in Dentally have their primary email migrated as the main contact identifier, and any additional addresses are stored in a custom merge field for reference.

Patient phone number from Dentally's practice telephone field maps to Mailchimp's PHONE merge field. International format standardization following the E.164 format is applied automatically during the export transform if Dentally stores numbers in local or non-standardized format. This ensures consistent phone formatting across the imported Mailchimp contacts.

Mailchimp has no native MOBILE field — a custom merge field is created in the Mailchimp audience to accept the mobile number from Dentally. SMS marketing consent status should be verified against local regulations before the number is used for SMS campaigns.

Date of birth has no native Mailchimp equivalent and requires a custom DATE-type merge field for each audience. The date format is normalized to YYYY-MM-DD during the export transform process so Mailchimp can use it in date-conditional Customer Journey branches and time-based segmentation rules without format conversion issues.

Appointment frequency patterns, last appointment date, and next scheduled recall date extracted from Dentally are encoded as Mailchimp tags for behavioral segmentation. Examples include tags such as 'Recall-6months', 'Last-Visit-2024-09', or 'ApptFrequency-High'. These tags enable precise segmentation for recall campaigns without creating per-contact custom fields for temporal data that would clutter the contact record.

Each Dentally custom field attached to a patient record is examined during migration — text-based fields under 255 characters become custom Mailchimp merge fields directly. Fields exceeding the 255-character limit are truncated to 254 characters and flagged in the migration report for manual review of the cut-off point to ensure no critical data is lost at the truncation boundary.

Dentally stores patient address components separately (street address, city, county/state, postcode, country) — these map to Mailchimp's structured address merge fields. If Dentally stores address as a single unstructured text block, FlitStack AI parses it into discrete components using known address format patterns before writing the import file for Mailchimp's address standard.

Dentally's preferred-contact pick-list values including Email, Phone, SMS, and Letter are mapped to a custom PREFCONTACT merge field. The original values from Dentally are written verbatim to Mailchimp without transformation — Mailchimp's conditional content blocks then reference these values to route campaign variants based on each contact's stated contact preference.

For multi-site dental groups, Dentally's site or practice identifier is used to create separate Mailchimp audiences per location. Each audience receives only contacts belonging to that specific site. If a single consolidated audience is preferred instead, the site name is written as a merge field on all contacts to enable location-based segmentation within the unified audience.

Dentally treatment plan types and recall intervals such as 'Hygiene-6month', 'Checkup-12month', or 'Restorative' are mapped to a custom RECTYPE merge field in Mailchimp. This enables precise campaign segmentation by recall urgency level, allowing practices to send targeted communications to patients based on their specific treatment category and recall schedule needs.

Dentally clinical notes and medical history fields exceed Mailchimp's 255-character merge field limit and cannot be meaningfully represented in an email marketing contact record. These fields are flagged as PHI-sensitive and excluded from the Mailchimp import — they remain in Dentally's clinical record system and are referenced manually for care-related communications that require clinical context.