Migrate from Pega Customer Engagement Suite to Mailchimp

Pega Customer Profiles map directly to Mailchimp Contacts. Standard contact fields (First Name, Last Name, Email, Phone, Address) migrate to their Mailchimp merge field equivalents (FNAME, LNAME, EMAIL, PHONE, ADDRESS). We use the email address as the deduplication key and reject records with duplicate or malformed email addresses during the validation pass. Any custom profile properties extend as Mailchimp custom merge fields (max 40 characters per field name, mapped to MC's naming convention).

Pega's custom Entity records (organization-specific data tables beyond standard Customer Profile fields) require flattening before migration because Mailchimp has no relational object model. Each Entity maps to either a Mailchimp custom merge field (for single-value properties) or a Tag (for multi-value or categorical data). Lookup relationships between entities are documented as a relationship map and cannot be preserved as foreign-key references in Mailchimp; they are communicated to the customer's admin as an impact note for segmentation redesign.

Pega Cases do not have a direct Mailchimp equivalent. Case metadata (case ID, status, priority, assigned operator, creation date, last modification date) is not meaningful within Mailchimp's contact-centric model. We extract the most operationally relevant case attributes (current status, priority tier, case type label) and encode them as Tags on the Contact record. Full case history is documented as a separate CSV export for the customer's operations team to retain independently.

Work Objects are case instances with stage, assignment, and SLA metadata. The pyStatusWork and pyAssignment fields from Pega map to a combination of Mailchimp Tags (for status and stage) and a custom merge field (for SLA tier). We cannot preserve the routing or assignment hierarchy; these become informational tags that the marketing team uses for segment filtering in Mailchimp rather than case management flags.

Pega email engagements (email body, timestamp, direction, sender/recipient) do not map to a native Mailchimp object because Mailchimp tracks campaign email activity (opens, clicks, unsubscribes) rather than inbound/outbound CRM emails. We extract email engagement records and append them as a formatted Note on the Contact record in Mailchimp (using the Notes feature via API). This preserves the historical communication context without forcing it into Mailchimp's campaign tracking model.

Pega call engagements (call disposition, duration, recording URL) cannot be represented in Mailchimp's contact model. We extract call records and append them as Notes on the Contact using Mailchimp's member notes endpoint, preserving call timestamp, duration, and disposition in a structured text format. Call recordings (URLs) are documented in the handoff CSV for the customer's admin to store in an external system.

Pega meeting engagements (meeting title, start/end time, attendees, location) migrate as Notes on the relevant Contact records via Mailchimp's API notes endpoint. Meeting attendees beyond the primary contact are documented as a separate attendee list CSV for the customer's records. Calendar-based meeting tools (Google Calendar, Outlook) are recommended as the ongoing meeting capture mechanism post-migration.

Pega Notes attached to Customer Profiles map directly to Mailchimp Contact Notes via the Mailchimp Members Notes API endpoint. Note body, author, and timestamp migrate as structured note entries on each Contact. We preserve the note creation order by appending notes chronologically so that the most recent note appears at the top of the contact's note history.

Pega Data Pages are cached data structures used by applications to retrieve customer-related information. We extract the cached values and map them to Mailchimp Tags (for categorical values) or Merge Fields (for scalar values). Data Pages that represent lookup tables or reference data are documented in the schema inventory rather than migrated, as Mailchimp has no reference data or lookup table concept.

Pega Case Types define templates for cases, including stages, steps, assignments, and routing rules. Mailchimp has no case management capability, so Case Types cannot be migrated as a functional object. We document each Case Type in a configuration inventory that the customer's operations team uses to assess which Mailchimp Automation triggers and tags might replicate the marketing-relevant portions of the case flow logic.

Pega Next-Best-Action decision rules and Decision Manager configurations are AI-driven logic trees specific to Pega's decisioning engine and cannot be extracted and translated to any other platform. We document the decision strategy structure and the business outcomes it was designed to produce as a specification brief. Mailchimp's own audience-based automation triggers (welcome, birthday, tag-added, purchase) can replicate the marketing-side intent of simple decision rules, but complex multi-armed bandit or predictive models cannot be reproduced without a dedicated decisioning platform.

Pega low-code workflows, case flows, and service level rules use Pega's BPMN-adjacent authoring syntax that has no equivalent in Mailchimp. We do not migrate workflows as code. We deliver a written inventory of every Pega workflow with its trigger conditions, case routing logic, SLA definitions, and automated actions, along with a recommendation for which Mailchimp Automation triggers (tag-based, date-based, or event-based) could approximate the marketing-relevant automation logic. The customer's marketing team rebuilds these in Mailchimp's Automation builder post-migration.