Migrate from Pega Customer Engagement Suite to Salesforce Sales Cloud

Pega Customer Profiles store contact information, interaction history, and preferences. They map to Salesforce Contact (with standard fields: FirstName, LastName, Email, Phone, MailingAddress) and the related Account (CompanyName becomes Account Name; industry, annual revenue, and website map to Account fields). Relationships to organization-level entities in Pega become Account-Contact hierarchy lookups in Salesforce. We resolve the Account before inserting Contacts so the AccountId foreign key is satisfied at insert time.

Pega Cases represent service requests, complaints, and inquiries. Each case instance carries pyStatusWork, pyAssignment, and SLA metadata. We map Case ID to Salesforce Case Number, Case priority to Priority, the Pega assigned user to Salesforce OwnerId via User email lookup, and the customer reference to ContactId or AccountId on the Case. Closed and open case statuses map to Salesforce Case Status picklist values that we configure in the destination org before migration.

Work Objects are case instances created from Case Type templates with pyStatusWork and pyAssignment fields. We extract all work object records including current assignment, stage, and audit history. If the Work Object represents a service interaction, it maps to Salesforce Case; if it represents a sales or operational process, it maps to Task or Event with a WhatId pointing to the related Account or Opportunity. The mapping decision is made during scoping based on the Case Type category in Pega.

Pega Entities are core data model objects that map to database tables. Organizations often add custom entities beyond Pega's standard ones. We audit every Entity in the source system during discovery, map standard entities to Salesforce standard objects (Account, Contact, Product2), and map custom entities to Salesforce custom objects with __c API names. We pre-create the destination schema including all custom fields, lookup relationships, and validation rules before any data import.

Data Pages are cached data structures used by Pega applications to retrieve and display information. We extract the cached data values and map them to equivalent custom objects or custom fields in Salesforce. If the Data Page represents a reference dataset (country codes, product lists, pricing tiers), it becomes a Salesforce Custom Object; if it represents a single attribute on a Contact or Account, it becomes a custom field on that object. The dependency on the parent Entity is resolved before insert.

Case Types define the template for cases including stages, steps, assignments, and routing rules. We document Case Type configurations as specifications for manual rebuild in Salesforce as Case Record Types and Case Status values. The Case Type name becomes the Record Type label; stage transitions become Case Status picklist entries. This is not an automated migration because Pega's routing logic and SLA enforcement have no direct Salesforce equivalent.

Custom fields extend standard Pega objects and are associated with Rules. We extract field names, data types, and all populated values. Each custom field maps to a Salesforce custom field of the equivalent type (text to Text, numeric to Number, date to Date, picklist to Picklist). Multi-value fields map to Salesforce multi-select picklists. Field-level mapping is required due to differences in Pega's property model and Salesforce's field type constraints.

Pega assignment records track who is responsible for a Work Object at each stage. We extract assignment history (assignee, timestamp, status) and map it to Salesforce Task records with TaskSubtype=Call or Task (depending on assignment type) linked to the parent Case or Work Object. The Pega assignee email resolves to Salesforce User OwnerId via the User mapping table.

Pega stores a complete audit trail for each case including status changes, user actions, and system events. We extract the case history and map it to Salesforce CaseComment records for human-authored notes and to EmailMessage or Task records for automated system events. Timestamps preserve the original Pega creation and modification dates via Salesforce CreatedDate and LastModifiedDate fields.

Pega SLA rules define entitlement time targets per case type and priority. We document SLA configurations as a written specification for Salesforce Case Milestones (Service Cloud) or as custom fields (FirstResponseDate, ResolutionDate) on the Case object. SLA breaches map to a custom text field recording the Pega SLA status at migration time. This is configuration rather than data because Salesforce milestones are calculated at runtime, not stored historically.

Pega's Decision Manager and Next-Best-Action rules are AI-driven logic trees specific to Pega's decisioning engine. These cannot be extracted and translated to other platforms. We deliver a written specification for each Decision rule documenting its trigger conditions, business logic branches, and recommended Salesforce Einstein Next Best Action or Salesforce Flow equivalent. Rebuild is scoped separately.

Pega workflows (cases, processes, and service levels) are authored in Pega's low-code BPMN-adjacent syntax. The platform does not export workflows in a standard format compatible with Salesforce. We document every active workflow including its trigger, conditions, actions, and SLA configuration as a written specification for manual rebuild in Salesforce Flow. This is the highest-scope documentation deliverable for Pega-to-Salesforce migrations and typically requires a separate implementation engagement.