Migrate from tab32 to Mailchimp

Mailchimp contacts map directly from tab32 patient records. Email address is the unique key in Mailchimp — we match by patient email to resolve duplicates. Patients without email addresses are flagged for manual review or excluded per your preference, since Mailchimp requires an email for audience membership.

tab32 first-name and last-name fields map to Mailchimp's standard FNAME and LNAME merge fields. Mailchimp uses these in email personalization tokens (e.g., *|FNAME|*). If tab32 stores names in a single field, we split by common delimiters before loading. Name parsing handles standard dental office conventions including suffixes like DDS or DMD when stored with patient names.

Patient email in tab32 becomes the Mailchimp contact email — the primary identifier for all Mailchimp sends. We deduplicate by email during import; if the same email appears multiple times in tab32, we keep the most recent record's demographics and flag for review.

Phone numbers migrate to Mailchimp's PHONE merge field type. Mailchimp stores phone as free-text; we validate format (E.164 recommended) but do not enforce SMS opt-in — that consent flag must be set separately in Mailchimp's compliance settings. Number formatting normalization is applied to remove extraneous characters before import.

tab32 address components (street, city, state, ZIP, country) map to Mailchimp's structured ADDRESS merge field. This enables geographic segmentation in Mailchimp (e.g., filter by state for regional recall campaigns). We parse tab32's address string into components before loading. Incomplete address records are flagged for manual cleanup or excluded from geographic segmentation logic.

tab32 tracks last-appointment dates per patient. Mailchimp has no native clinical-field equivalent. We create a DATE-type custom merge field (LAST_VISIT_DATE__c) for recare segmentation — for example, targeting patients with last-visit > 6 months ago for recall campaigns. Original timestamp preserved.

If tab32 tracks patient interest in specific services (e.g., cosmetic dentistry, implants, orthodontics), we migrate these as both Mailchimp tags (for journey segmentation) and a multi-select custom field. Tags are additive; Mailchimp allows unlimited tags per contact. We recommend establishing a standardized tag taxonomy during pre-migration planning to ensure consistent naming across all imported records.

tab32's multi-location DSO structure uses location IDs per patient. We create a TEXT-type merge field (PRIMARY_LOCATION__c) so Mailchimp campaigns can segment by which practice a patient belongs to. For large DSOs, we recommend splitting by location into separate Mailchimp audiences instead.

tab32's SMS/email consent flags map to Mailchimp's EUGDPR_* merge fields and consent status. If tab32 tracks marketing email consent separately from appointment reminders, we map the marketing-specific consent flag. Mailchimp's consent model is all-or-nothing per contact — multiple consent types require custom fields.

Insurance data has no Mailchimp equivalent and is generally not needed for email marketing. We preserve it as a TEXT custom field (INSURANCE_PLAN__c) for reference if your team wants to segment recall campaigns by insurance type. Flag: do not include in marketing sends without patient consent.

tab32's clinical data (treatment plans, x-rays, periodontal charting, clinical notes) has zero Mailchimp equivalent — Mailchimp is an email marketing platform, not a health record. These records must remain in tab32 or a HIPAA-compliant alternative. We document them as out-of-scope and do not export them to Mailchimp.

Appointment slot data in tab32 does not map to Mailchimp. Future appointment information can trigger Mailchimp automations via API integration, but the appointment records themselves (date, time, provider, procedure code) stay in tab32. We create a custom field (NEXT_APPOINTMENT_DATE) if tab32 exposes this for marketing-trigger use.

tab32 billing ledgers, outstanding balances, and payment histories have no Mailchimp equivalent and should not be exported to an email marketing platform. Mailchimp Business tier's BAA does not cover financial records — billing data remains in tab32 for HIPAA and PCI compliance. We flag all billing fields as excluded.