Migrate from Pega Sales Automation to Mailchimp

Pega Contacts map directly to Mailchimp Audience Members. The parent Account reference is stored as a custom merge field (ACCOUNTNAME) to preserve the company association that Mailchimp's flat contact model does not natively track. Email address is the dedupe key. We run email-validation checks against Mailchimp's format rules before insert to prevent rejections from invalid addresses in the source data.

Pega Accounts do not have a direct Mailchimp equivalent because Mailchimp has no native company or organization object. We treat the Account name as a merge field on each Contact (ACCOUNTNAME) and the Account industry classification as a second merge field (ACCOUNTINDUSTRY). If the customer uses Pega's Financial Services, Insurance, or Healthcare vertical variant, we map the vertical-specific account extension fields to additional merge fields.

Pega Leads map to Mailchimp Audience Members with a tag applied (LEAD_SOURCE: PEGA) to preserve the origin distinction. Any Pega disposition codes on the Lead become a merge field (LEAD_DISPOSITION). Pega Leads with a disposition of Converted are treated as Contacts and imported without the LEAD_SOURCE tag. Unconverted Leads that cannot be emailed due to consent gaps are flagged in the reconciliation report.

Pega territories define access control and geographic or business-unit segmentation. Mailchimp has no territory model. We map each Pega territory assignment on a Contact to a corresponding Mailchimp Tag (format: TERRITORY_<name>) applied to the Audience Member. Territory hierarchy (parent-child) is flattened into a single tag value. If the customer has more than 50 distinct territory values, we recommend consolidating into 10-15 segmentable tags to stay within Mailchimp's tag management limits.

Pega custom fields on Contact (properties added via App Studio or Rule configuration) require individual mapping to Mailchimp merge fields. Mailchimp supports TEXT, NUMBER, DATE, ADDRESS, PHONE, and WEBSITE merge field types. Each Pega property must be typed, and its value must fit Mailchimp's character and format constraints. Merge field names are limited to 10 uppercase characters; longer Pega property names are truncated per Mailchimp naming rules. Custom fields are enumerated entity-by-entity via the Pega API as there is no single-schema discovery endpoint.

Pega Campaigns group Leads and Activities for coordinated outreach. Mailchimp Campaigns are email sends with audience targeting. We map Pega campaign membership (which Contacts were targeted by which Campaign) to Mailchimp Tags on each Audience Member using the campaign name as the tag value (CAMPAIGN_<name>). Campaign status (active, completed, draft) is not migratable as Mailchimp campaign state is not a contact-level attribute.

Pega Activities (calls, emails, meetings, tasks) tied to Contacts carry historical engagement data. Mailchimp has no activity history object for individual contacts beyond open and click tracking on Mailchimp-sent emails. We do not migrate the full activity timeline as Mailchimp cannot store it. We flag the most recent Activity date as a merge field (LASTACTIVITY) on the Audience Member so sales reps retain at least one timestamp reference. Any Pega call disposition codes are stored as a merge field (CALL_DISPOSITION).

Pega Products linked to Opportunities via the junction object do not have a Mailchimp equivalent. Product interest signals are preserved by tagging each related Contact in Mailchimp with the product name (PRODUCT_<name>). This is a best-effort proxy for opportunity-level product attachment data, which does not migrate structurally.