Migrate from Practice by Numbers to Mailchimp

Mailchimp merge-field type mismatch breaks date-based segmentation

Mailchimp requires merge fields to have a declared type at creation — text, date, number, or address. Once a field is created as a text field, it cannot be changed to a date type without deleting all values and recreating the field, which causes data loss. FlitStack inspects every PbN custom field during the planning phase and creates Mailchimp fields with the correct type before migration data is loaded. Specifically, next_appointment_date and last_appointment_date are created as DATE-type merge fields so Mailchimp's relative date segment filters (e.g., 'NEXT_APPT is in the next 30 days') work correctly. If your PbN export mixes date and text values in the same column, we flag that column for cleansing before import.

Mailchimp's audience-level contact deduplication may merge household contacts unexpectedly

Mailchimp deduplicates contacts by email address within each audience — if two PbN patient records share the same email (e.g., a parent and child registered under one family email account), Mailchimp merges them into a single contact at import. The merged contact retains the first record's values and loses the second. FlitStack detects duplicate email addresses during the PbN export review and presents your team with three options before migration: append a unique suffix to the second email address, tag both contacts with a 'household' label and keep one record, or suppress the duplicate entirely. This decision must be made before the bulk import because Mailchimp's merge happens at import time and cannot be undone without deleting the contact.

Mailchimp's 30-custom-field limit constrains dental-specific data preservation

Mailchimp's Standard plan caps custom merge fields at 30 per audience. A dental practice with treatment history, multiple recall dates, insurance details, referral sources, and clinical flags can exceed 30 custom fields quickly. FlitStack maps the highest-value fields for marketing segmentation first and stores overflow data in a single JSON-formatted custom text field (Extra_Data__c) that can be parsed by your team or used in Mailchimp's personalization tokens. We flag any field that would push the audience over the 30-field limit before migration runs and present a prioritization ranking so your team can decide which fields appear as queryable merge tags versus stored-only data.

Mailchimp does not send automated appointment reminders — recall campaigns require manual setup

PbN's core value for patients is automated appointment reminders via SMS and email tied to specific appointment timestamps. Mailchimp has no native appointment object and cannot trigger reminders based on a date stored in a custom merge field — there is no built-in mechanism equivalent to PbN's recall engine. After migration, your team must build Mailchimp automation journeys that use the NEXT_APPT__c custom date field as a segment trigger, which requires Mailchimp Standard or Premium plan access to multi-step automations. FlitStack exports the PbN appointment schedule as a planning document for rebuilding these automations in Mailchimp, but the automation logic itself must be configured within Mailchimp post-migration.

PbN's per-provider subscription means contact counts may differ after migration

PbN counts patients per provider within a practice, and the same patient seen by multiple providers may appear multiple times in a PbN export depending on how the practice configured records. Mailchimp counts contacts uniquely by email address. A single patient with one email address who appears under two providers in PbN becomes one contact in Mailchimp. This is typically desirable (a patient should receive one recall email, not two), but it means the Mailchimp contact count will be lower than the PbN patient record count. FlitStack surfaces this discrepancy during the pre-migration data audit and resolves duplicates by keeping the record with the most recent appointment date.