Migrate from Marketing 360 to Mailchimp

Marketing 360 Contacts map directly to Mailchimp Audience members via email address as the primary key. We extract firstName, lastName, email, phone, and contactName from the CRM API and create or update the corresponding Mailchimp member record. Contacts without a valid email address are held in a reconciliation queue for the customer's admin to enrich or suppress before final import.

Marketing 360 custom fields from the Custom Fields API map to Mailchimp merge fields by field name. Mailchimp merge fields have a hard 255-character limit; we truncate values exceeding this threshold and flag the truncation in the migration report so the customer can decide whether to split long-form data across multiple merge fields or store it externally. Field type mapping: text fields map to text merge fields, date fields map to date merge fields, and picklist-type custom fields map to radio or dropdown merge fields based on single-select vs multi-select behavior in Marketing 360.

Marketing 360 contact tags migrate to Mailchimp Tags preserved with their full taxonomy and membership associations. We extract every distinct tag name and id from the CRM API, create the corresponding Tags in each Mailchimp Audience, and apply tag memberships to each contact during member import. Tags used for contact classification in Marketing 360 serve as the primary segmentation signal in Mailchimp and can be used to recreate Marketing 360 audience segments as Mailchimp tagged-audience segments.

Marketing 360 Status and Type fields use arbitrary name/id pairs to classify contacts (for example, Status: Active/Inactive/Prospect and Type: Residential/Commercial). We extract the full taxonomy and map these values to Mailchimp Tags with a prefix convention (for example, Status_Active, Type_Commercial) to preserve the classification context without creating custom merge fields. The customer chooses at scoping whether to apply Status and Type as Tags or to create dedicated Tags in a separate namespace.

Marketing 360 email subscriber data and segment membership derive from the CRM contact export. We identify contacts with valid email addresses and extract any list or segment membership flags. These migrate to a primary Mailchimp Audience. If the customer used multiple Marketing 360 email lists, we create corresponding Mailchimp Audiences and map contact-segment memberships to audience-group relationships during import.

Marketing 360 Assignees (username, fullName, email nested under contacts) represent sales rep ownership. Mailchimp does not have an assignee or owner field on Audience members. We extract assignee data during scoping and store it in a migration artifact. The customer can use this to configure Mailchimp's team features (multiple user access) post-migration or cross-reference against a separate CRM if they adopt a standalone CRM alongside Mailchimp.

Marketing 360 UXi Posts, Pages, and Testimonials export as XML content without layout files or theme assets. We extract text content, categories, tags, and media references from the export. These migrate as Mailchimp Landing Page content or as a structured content inventory the customer's team can manually recreate in Mailchimp's landing page builder. Layout files, root-domain media assets, and theme configuration require rebuild and are scoped separately as a content workstream.

Marketing 360 Automation Journeys are stored in the application layer and not accessible via the public API. We cannot migrate them as code. During scoping we document every active journey: trigger conditions, time delays, branch rules, subscriber entry points, and CRM actions. This inventory is delivered as a written rebuild checklist mapped to equivalent Mailchimp Customer Journey Builder triggers (such as 'joins audience' for list-entry triggers or 'contact added to segment' for segmentation-based entry). The customer's admin rebuilds automations post-migration.