Migrate from Results to Mailchimp

Results Contacts map to Mailchimp Members within a designated Audience. We use email address as the primary dedupe key. The Results contact's name, phone, address, and custom field data map to Mailchimp merge fields (FNAME, LNAME, PHONE, ADDRESS fields). Subscription status in Results (subscribed, unsubscribed, bounced) maps to Mailchimp Member Status directly. Any contact in Results without an email address is flagged in the reconciliation report and excluded from import because Mailchimp requires a valid email for Member records.

Results Companies have no direct Mailchimp equivalent. We offer two strategies: store the company name as a Mailchimp Tag (one tag per Company, applied to all Members with that Company value) for segmentation, or map Company fields to custom merge fields on each Member record. The customer's choice during scoping determines whether Company name, domain, industry, and employee count become tags or merge fields. Tags are recommended for companies that recur across multiple Contacts; merge fields are recommended for one-contact-per-company accounts.

Results Deals have no Mailchimp equivalent because Mailchimp does not have a deal or opportunity object. Deal fields (deal name, amount, stage, close date) that the customer wants to preserve are mapped to custom merge fields on the associated Contact's Member record, or to Tags prefixed with DEAL:. Deal pipeline and stage assignments become Tags for segmentation in Mailchimp. The customer specifies which Deal fields matter for ongoing marketing segmentation during scoping.

Results Pipelines do not map to Mailchimp. Pipeline names become a tag group (PIPELINE:) in Mailchimp, and each pipeline assignment is a tag on the Member record. This allows the customer's admin to create Mailchimp segments filtering by pipeline in the Audience view. Stage names within each pipeline similarly become tags (STAGE:). The tag taxonomy is documented in the migration handoff.

Results engagement history (calls, emails, meetings, tasks) has no direct Mailchimp equivalent in the Member record. We extract the past 90 days of email engagement data from Results (send timestamp, open timestamp, click timestamp) and import these as Mailchimp activity records against the matching Member. Historical data older than 90 days cannot be imported into Mailchimp per platform constraints; we export this as a CSV reference file for the customer's records. Call, meeting, and task engagement is documented as a gap in the handoff report.

Results custom fields map to Mailchimp custom merge fields. Text-based custom fields are created as TEXT merge fields in Mailchimp with a 255-character limit. Fields exceeding this limit are split across two merge fields (FIELD_NAME and FIELD_NAME_LONG) or truncated with a note in the migration report. Date fields are converted to Mailchimp DATE merge fields. Number fields map to NUMBER merge fields. Picklist fields map to RADIO or dropdown merge fields. All merge field mappings are defined in the scoping document before migration begins.

Results tags on Contacts map directly to Mailchimp Tags on the corresponding Member. Tag names are preserved as-is. Mailchimp Tags can be applied across all Audiences if the customer's Mailchimp setup uses a single shared Audience, or scoped per Audience if multiple Audiences exist. We resolve this during scoping by checking whether the customer's Mailchimp account uses one or multiple Audiences.

Results Attachments linked to Contacts have no direct Mailchimp import path. We export attachment metadata (filename, linked contact, upload date) as a CSV and note the gap in the handoff report. The customer's admin recreates or links attachments manually in their chosen storage system post-migration. Attachments are not a standard part of the Mailchimp Member data model.

Results Tickets do not have a Mailchimp equivalent. If the customer uses Tickets to track customer service history relevant to marketing (for example, identifying at-risk customers), we map Ticket status and subject as Tags on the Member record. Open tickets become a CUSTOMER_SERVICE:OPEN tag; resolved tickets become CUSTOMER_SERVICE:RESOLVED with the resolution date as a custom merge field. This is a best-effort mapping documented in scoping.