Migrate from Pega Customer Engagement Suite to Twenty CRM

Pega Cases are the central work object representing service requests, complaints, and inquiries. Each Case instance carries status, priority, assignment, and SLA metadata. Twenty CRM has no native Case object, so we map Case records to a combination of Company (for organizational cases) and Person records (for individual cases), with the original Pega case status, priority, and assignment data preserved in custom fields on the destination records. If the Pega deployment uses Cases primarily at the account level, they map directly to Company.

Work Objects are case instances created from Case Type templates with current assignment, stage, and audit history. The pyStatusWork and pyAssignment fields carry routing and SLA data that we translate to Twenty Task status and assignee fields. Activity timestamp ordering is preserved by setting the Twenty Task's due date and completion date to the original Pega work object timestamps. Parent-case linkage is maintained via a custom field linking the Task to the migrated Company or Person record.

Pega Entities are the core data model objects that map to database tables; organizations often add custom Entities beyond Pega's standard ones. We map each Entity to a Twenty Custom Object created via the /metadata API before data migration begins. The Twenty metadata schema (DataSource, Object, Field tables) is pre-configured with matching field names and data types so that the GraphQL schema generation produces the correct structure. Any Entity relationships (parent-child, many-to-many) are resolved as Twenty custom object lookups.

Pega Customer Profiles store contact information, interaction history, and preferences. When a Customer Profile includes organizational affiliation, we split it into a Person record (name, email, phone, address) and a Company record (organization name, domain), with the Person linked to the Company via a standard relationship field. Custom properties on the Pega Customer Profile migrate as custom fields on the Person object. Interaction history migrates as Tasks and Notes attached to the Person record.

Pega Data Pages are cached data structures used by applications to retrieve and display information. We extract the cached data values and map them to a Twenty Custom Object with field names derived from the Data Page's property definitions. Since Data Pages represent derived query results rather than source records, we create a separate Custom Object for each Data Page and populate it with the extracted values, noting that the query logic that originally hydrated the Data Page will need to be rebuilt as a Twenty view or filter.

Pega Case Types define the template for cases including stages, steps, assignments, and routing rules. Twenty CRM has no equivalent case-type concept; its workflow model uses standard CRM objects (Tasks, Notes, Opportunities) with no native BPMN-style stage/step builder. We document each Case Type configuration as a written specification covering stages, step sequence, assignment rules, and SLA definitions, which the customer's admin uses to design equivalent Twenty CRM workflows manually after migration.

Custom fields extend standard Pega objects and are associated with Rules. We extract field names, data types, and all populated values from every custom field definition. Mapping to Twenty custom fields requires a destination object (standard or custom) and field creation via the /metadata API before import. Text fields map to text, numeric fields to number, picklist values to select, and date fields to date. Custom field validation rules do not migrate and must be defined manually in Twenty's field settings.

Pega Decision Manager and Next-Best-Action rules are AI-driven logic trees specific to Pega's decisioning engine. Twenty CRM has no native decisioning or AI-driven next-best-action capability. Decisions cannot be extracted and translated to Twenty's platform. We deliver a written inventory of every active Pega Decision rule with its conditions, actions, and business context so that the customer's team can evaluate whether equivalent logic needs to be rebuilt manually or via an external decision engine.

Pega workflows authored in Pega's low-code BPMN-adjacent syntax do not export in a standard format compatible with Twenty CRM. We do not migrate workflow logic as code. We export business logic as documentation covering each workflow's trigger, conditions, actions, assignments, and SLA configurations, which the customer's admin uses to design equivalent processes using Twenty's standard CRM objects (Tasks, Notes, Opportunities with stage automation) after migration.

Pega report definitions, dashboard configurations, and analytics views are platform-specific and do not transfer across systems. We deliver a written catalog of every Pega report with its filters, groupings, metrics, and chart configuration. The customer's admin rebuilds these as Twenty CRM views, filters, and Opportunity reports, or connects to an external BI tool (Metabase, Grafana, or similar) that reads from Twenty's database directly.