Migrate from SwiftCRM to Mailchimp

SwiftCRM Contacts with name, email, phone, and relationship type map directly to Mailchimp Members by email address as the dedupe key. The SwiftCRM Face ID protection flag is not carried to Mailchimp as there is no corresponding field; we note it as an informational property for the customer's records. Any Contact without a valid email address is held in a reconciliation queue for manual resolution before import because Mailchimp requires an email address for Member creation.

SwiftCRM Appointments with scheduled dates, times, and client links cannot map to any native Mailchimp object because Mailchimp is not a scheduling or CRM platform. We carry appointment date and time as mm_appointment_date and mm_appointment_time merge fields on the Member record, and add a mm_has_appointment tag for audience segmentation. The customer rebuilds any appointment reminder workflow as a Mailchimp automation post-migration.

SwiftCRM Reminders tied to clients or appointments cannot import into Mailchimp's activity model. We map reminder dates to mm_reminder_date merge fields and flag mm_reminder_set tags on Member records. Notification history is mapped to mm_notification_history tags. The customer configures their own reminder cadence in Mailchimp automations post-migration.

SwiftCRM E-Docs are not importable into Mailchimp, which has no native file attachment model for Member records. We export all attached files and produce a CSV inventory listing each file name, the linked Contact email address, and a location reference. The customer redistributes files manually, links them via a cloud storage URL in a custom merge field, or uses an alternative document management tool post-migration.

SwiftCRM custom fields vary by account tier during beta. We audit all available custom fields during scoping and map them to Mailchimp merge fields, subject to the 30-field limit on free and Essentials plans and the 80-field limit on Mailchimp Premium. Fields exceeding the limit are stored as mm_custom_tag tags or flagged for manual post-migration entry on the Member record.

SwiftCRM family and business relationship structures between Contacts do not have a native Mailchimp equivalent. We map relationship type to mm_relationship_type tags on the Member record (e.g., family_member, business_client, referral_partner). When both related Contacts are present in the Mailchimp audience, we store the related Contact email as mm_related_contact_email for reference. The customer rebuilds any relationship-dependent segmentation as Mailchimp segments post-migration.

SwiftCRM User accounts and permissions cannot map to Mailchimp seat access because the two platforms manage user roles differently and Mailchimp seats do not correspond to CRM ownership hierarchies. We produce a User inventory document mapping SwiftCRM users to the Mailchimp accounts they should access, and the customer provisions Mailchimp seats manually post-migration.

Notification history tied to client interactions in SwiftCRM migrates as mm_notification_history tags on the Member record. The notification content (message text, timestamp, delivery status) is not transferable to Mailchimp's engagement model. We note the notification count as mm_notification_count for the customer's reference in segmentation.