Migrate from Pega Platform to Twenty CRM

Pega Party records are individual entities associated with a case, typically representing customers, contacts, or guarantors. FlitStack AI maps each Party to a Twenty People record, extracting pyFirstName, pyLastName, pyEmail, and contact properties and resolving the Party's role label as a custom field on the People record for audit continuity.

Pega stores some Party records with a single pyFullName string rather than split name components. FlitStack AI splits the full name on the last space to populate Twenty's firstName and lastName fields. Where pyFirstName and pyLastName exist as separate properties, those are mapped directly and the full-name split is skipped.

Pega's pyEmailURI property (mailto: URI format) is parsed to extract the raw email address before writing to Twenty's email field. pyPhone is mapped to Twenty's phoneNumber. Mobile phone and secondary contact fields are mapped to their Twenty equivalents when present on the Party record.

Pega stores organization data in Data-Org- class instances, with properties like Name, Domain, Industry, and numberOfEmployees. FlitStack AI extracts each organization record and creates a corresponding Twenty Company record, mapping standard properties to their Twenty equivalents and flagging any organization that has no Pega-assigned name for manual review.

Pega's structured pyAddress page is decomposed into Twenty's address street fields and country pick-list. City, state/province, and postal code are mapped individually. Where Pega stores only a partial address (city only, for example), the remaining address components are left blank and the Company record is flagged for enrichment.

Pega Work items (cases) are process-driven work objects, not sales deals. FlitStack AI migrates them as Twenty Opportunities with a custom text field PegaCaseID__c storing the original Pega case handle so the audit trail is preserved. Case subject maps to Opportunity name; status, priority, and description are mapped to custom fields since Twenty does not have a native case structure.

Pega assignments are workbasket or operator-level routing records. FlitStack AI resolves the assigned operator's email from the assignment and maps it to the Opportunity's assignee field in Twenty. If a workbasket (multiple operators) is assigned, a linked Task is created per operator in Twenty to preserve the routing record.

Pega's case audit history is a structured log of status changes, assignments, and SLA events. FlitStack AI converts each audit entry into a Twenty Note attached to the migrated Opportunity, recording the timestamp, operator, and action. This preserves the case's full history in a readable format in Twenty without requiring a custom audit object.

Pega SLA goal and deadline timestamps are extracted and stored as custom datetime fields (SLA_Goal__c and SLA_Deadline__c) on the migrated Opportunity. Twenty's native Task dueDate field is used for immediate action items. SLA rules themselves cannot be migrated — they must be rebuilt in Twenty's workflow builder if continued SLA tracking is required.

Any Pega custom data class (Data- prefixed classes beyond the standard org/work structures) is migrated as a Twenty custom object. The custom object is created in Settings → Data Model before migration begins. Relationships that exist as embedded pages in Pega are mapped as relation fields in Twenty; many-to-many relationships may require junction objects which are surfaced in the migration plan.

Pega Operator records (staff members) are resolved by email against Twenty Workspace Members. The Twenty workspace must be set up and members invited before migration runs, otherwise owner fields are flagged as unmatched and assigned to a fallback user. Unmatched operators are listed in the pre-migration audit report.

Pega stores file attachments as Data-Content-* records linked to cases. FlitStack AI preserves the attachment name, content type, and the Pega record handle as a custom text field on a Note attached to the related Opportunity. Actual file re-upload requires your team to download from Pega and re-attach in Twenty, as Pega's blob storage is not directly accessible via API.

Pega Decision Rules include Decision Trees, Decision Tables, and Scorecard rules — Pega-engine constructs that power next-best-action logic and conditional routing. These rule artifacts are deeply embedded in Pega's rule stack and cannot be extracted in a format Twenty can interpret. They are disclosed as not migratable and surfaced in the pre-migration audit as candidates requiring manual reconstruction in Twenty's workflow builder.

Pega Case Types define the stages, transitions, and SLA configurations of a work process. Twenty does not have a case-type equivalent — processes are modeled as Opportunities with stage pick-lists and workflow automations. Each Pega Case Type must be analyzed and rebuilt in Twenty's workflow builder as a set of stage definitions and automation triggers.