Migrate from Pawa to Mailchimp

Pawa Contact records map to Mailchimp Members within a designated Audience. We use email address as the dedupe key during import. First name, last name, phone, and any standard Pawa fields map to their Mailchimp equivalents (FNAME, LNAME, PHONE). Custom Pawa fields translate to Mailchimp merge fields, subject to the 255-character text limit and the per-Audience field count ceiling (30 on Essentials and Standard, 80 on Premium). We flag any Pawa custom field exceeding 255 characters at scoping time so it can be truncated or split into multiple merge fields before import.

Mailchimp has no Company or Account object. We map Pawa Company name, address, and any company-level custom fields to custom merge fields on the Mailchimp Member record using a configurable naming convention (e.g., COMPANY_NAME, COMPANY_CITY, COMPANY_INDUSTRY). We apply company data to each Member by cross-referencing the Contact-to-Company relationship from the Pawa export before writing to Mailchimp.

Pawa tags stored as flat string arrays on Contact and Company records migrate as Mailchimp Tags on each Member. We preserve the original tag names so segmentation logic that relied on Pawa tags can be replicated in Mailchimp using Tags as a filter condition. Note that Mailchimp Tags are audience-scoped and do not inherit across multiple Audiences if the customer chooses to create separate Audiences.

Pawa custom fields on Contacts and Companies require explicit field-by-field mapping to Mailchimp merge field types. We create merge fields in Mailchimp during the pre-migration phase (text, number, date, address, phone, birthday) matching the Pawa field type. We validate field names and types against a live Mailchimp API read of the Audience schema before the import phase begins. Any Pawa field using an unsupported type (e.g., multi-select or file attachments) is flagged for customer review and excluded from the standard import path.

Pawa Users (sales reps, admins) with email addresses that correspond to Mailchimp account users are mapped as Owners or can be stored as a merge field (e.g., ASSIGNED_REP) on each Member. Mailchimp does not have a record-level Owner field equivalent to CRM systems; we recommend storing the original Pawa owner as a text merge field for reference rather than as a system-level assignment. Inactive Pawa users are flagged and excluded unless the customer requests otherwise.

Pawa Deals, including deal value, stage, and linked contacts, have no Mailchimp equivalent. Mailchimp does not track pipeline stages, deal values, or sales probability. We exclude Deals from the migration scope and document the existence of deal records in the pre-migration inventory so the customer can decide whether to export them to a separate spreadsheet or CRM for future reference.

Pawa pipeline stages used on Deals do not map to Mailchimp. Mailchimp organizes contacts by engagement status and tag-based segments, not by sales pipeline stages. We note any pipeline stage values in the migration scope document and confirm with the customer that these are excluded from the data transfer.

Pawa's API does not expose file attachments in any documented endpoint. We do not migrate attachments and flag their existence in the source account so the customer can manually download and re-upload them to the destination if needed. We exclude attachment-bearing records from the record count used to scope migration timelines and pricing.