Migrate from Sercom to Mailchimp

Sercom contacts map 1:1 to Mailchimp members. Each contact's email address becomes the member's primary identifier. Firstname, lastname, phone, jobtitle, and address fields map to Mailchimp's standard contact properties. The contact's Sercom ID is stored as a merge field (SRC_SYSTEM_ID) for traceability.

Sercom companies do not have a direct Mailchimp equivalent — Mailchimp has no Company or Account object. Company name maps to the COMPANY merge field on each member. Company domain, industry, employee count, and annual revenue become additional text or number merge fields on the contact record. Contacts linked to multiple Sercom companies retain the primary company name in COMPANY; additional companies are stored as tags.

Sercom service tickets have no meaningful Mailchimp equivalent. Ticket ID, status, priority, and description are exported as tags on the contact record (e.g., TAG: Ticket-OPEN, TAG: Priority-High). The full ticket history is exported as a separate CSV reference file — FlitStack delivers this alongside the Mailchimp import so the data is not lost, even though Mailchimp cannot display it natively.

Mailchimp has no asset management model. Asset records are exported as a separate CSV with the Sercom contact ID as a linking key. Key fields like asset name, serial number, and status are mapped to text merge fields on the member record for quick reference, but the full asset history requires the separate export file.

Scheduled service appointments do not map to Mailchimp automations or campaigns. Appointment date, type, and outcome are stored as tags (e.g., TAG: Appointment-Completed-2024-Q3) and the raw appointment data is included in the reference export alongside tickets and assets. This approach preserves the complete appointment history in a separate reference file, maintaining audit trails even though Mailchimp cannot natively display or trigger automations from appointment data.

Sercom Enterprise custom objects map to Mailchimp merge fields if the data is contact-level key-value pairs. If the custom object uses N:N relationships or contains multi-value data, FlitStack flattens it to one or more tags. Each custom object requires pre-migration planning to determine the best Mailchimp representation.

Any custom fields on Sercom contacts (beyond the standard firstname/lastname/email/phone set) must be pre-created in Mailchimp as merge fields before migration. FlitStack generates a Mailchimp setup checklist as part of the migration plan so the merge fields exist before data is loaded.

Sercom workflow rules, ticket routing automations, and task-assignment sequences do not have Mailchimp equivalents and cannot be migrated. FlitStack exports Sercom workflow definitions as a structured JSON document your team can use as a rebuild reference in Mailchimp's Customer Journey Builder.

Sercom owner assignments (which user is responsible for a contact or ticket) have no Mailchimp equivalent. The owner email or name is mapped to a Owner_Email__c merge field on the member record so team attribution is preserved, but Mailchimp does not have a CRM-owner concept.

Sercom tags or labels applied to contacts map directly to Mailchimp tags. Tags survive the migration intact and can be used immediately in Mailchimp segmentation and Customer Journey triggers after the migration completes. This direct migration preserves all existing categorization and labeling applied to contacts within Sercom, maintaining the full organizational structure and segmentation logic that teams have established over time. You will not need to rebuild tag-based segments or recreate trigger conditions from scratch.