Migrate from The Service Manager to Mailchimp

Every The Service Manager contact maps to a Mailchimp contact. The email address is the unique identifier — it must be present and valid for the record to import. Contacts without an email address are exported to a separate review file for manual handling before the Mailchimp import runs.

Mailchimp has no native company object. The company name, industry, and website from The Service Manager migrate as FNAME/LNAME company merge fields plus a Company_Tag tag on each contact. If your CRM uses parent-child company hierarchies, only the top-level company name is retained; child relationships are noted as tags for segmentation.

Mailchimp has no ticket object. The most recent ticket ID, ticket status, and priority level are encoded as Mailchimp tags (e.g., ticket_status:Resolved, priority:High, last_ticket_id:12345) on each contact record. This preserves the support context without a native equivalent in the destination.

Custom fields from The Service Manager that map to Mailchimp-supported types (text, number, date, phone, address, dropdown) are created as merge fields in the destination audience before migration. Fields with complex data types (arrays, multi-select, or nested JSON) are converted to pipe-delimited tags or custom text fields.

Company-level custom fields in The Service Manager migrate as Mailchimp merge fields on contacts when the field applies to a contact (e.g., Contract_Type on a contact record that originates from the Company object). Fields with no contact-level equivalent are surfaced as one-time tags for reference segmentation.

SLA tier values (Tier 1, Tier 2, Tier 3) from The Service Manager are mapped to Mailchimp tags using a consistent prefix (e.g., sla_tier:Tier1, sla_tier:Tier2). This tag-based encoding allows you to segment contacts by service level without consuming merge field slots. The tag format is searchable in Mailchimp's segment builder using tag membership conditions.

The Service Manager owner or assigned agent name maps to a Mailchimp tag using the assigned_agent prefix (e.g., assigned_agent:John Smith). This preserves the account-owner relationship for segmentation purposes. Since Mailchimp has no native owner field, the tag encoding ensures the relationship remains visible in contact records without requiring a separate merge field.

The Service Manager dynamic filter views (e.g., Open Tickets by Priority, High-Value Accounts) are converted to Mailchimp segments using a combination of tag membership and merge field conditions. Segment logic that relied on CRM-specific operators is translated to Mailchimp's AND/OR segment builder syntax.

The Service Manager workflows, SLA escalation rules, and approval chains have no Mailchimp equivalent. We export workflow definitions as a structured JSON document that your team can use as a reference when rebuilding automations in Mailchimp's Customer Journeys. The JSON captures each rule's trigger conditions, escalation thresholds, and expected outcomes for your Mailchimp admin to reference during the rebuild process.

Email templates and web forms from The Service Manager use an internal format incompatible with Mailchimp. We extract the HTML content from each template as a text file. These files can be imported into Mailchimp's template builder to accelerate rebuild time.

The Service Manager knowledge base articles are not contacts but reference material. During migration, we tag contacts with a knowledge_category tag referencing the most recently viewed article category, preserving a link to the content area without transferring the article body itself.

Ticket attachments stored in The Service Manager are downloaded and re-uploaded to Mailchimp's file hosting service. Large files exceeding Mailchimp's size limits or unsupported formats are preserved as an external URL reference field on the contact record, maintaining a link to the original attachment location in cloud storage for retrieval when needed.