Migrate from Pega Platform to Odoo CRM

Each Pega case maps to one Odoo lead. The Pega case pxInsCachedKey is stored in a custom field (Source_Case_ID__c) for traceability. pyID (human case number) maps to a reference custom field. Case creation timestamp becomes lead create_date. If the Pega case type corresponds to a sales opportunity, the Odoo lead can be converted to a crm.lead opportunity via Odoo's lead-conversion action.

Cases where pyStatusWork indicates a won or active deal split to an Odoo opportunity (crm.lead with type='opportunity'). Cases where pyStatusWork indicates a prospect, new, or pending status map to an Odoo lead with type='lead'. The split rule is configurable per case type — your migration plan defines the threshold rule for when a Pega case becomes an Odoo opportunity versus a lead.

Pega Data Pages with scalar properties (string, integer, boolean) become Odoo Char, Integer, or Boolean custom fields on the crm.lead model. The field name in Odoo is derived from the Data Page name (lowercased, underscores replacing spaces). For pick-list type Data Pages, an Odoo Selection field is created and value-by-value mapping is applied. Each custom field is created before migration runs so the ETL can write values on first pass.

Pega Data Pages that contain embedded sub-pages (page group mode) require flattening: each scalar sub-property maps to a separate Odoo custom field on the lead. Where a sub-page represents a related entity (e.g., a contact embedded in the case), the embedded data is normalized into a separate res.partner record and linked via a many2one custom field on the lead. This prevents data duplication and preserves the relationship in Odoo's relational model.

Each Pega assignment maps to an Odoo mail.activity record attached to the corresponding lead. The activity type (call, meeting, email, upload) is inferred from the Pega assignment action label (e.g., 'Review' → note; 'Phone Call' → phone call). The Pega operator assigned to the assignment is resolved by email match to an Odoo res.users record. If no match is found, the activity is assigned to a fallback Odoo user and flagged in the migration report.

Pega workbaskets (Data-Admin-Work-Basket) map to Odoo crm.team records. The Pega workbasket name becomes the team name; operators assigned to the workbasket map to crm.team.member records linked to the corresponding Odoo sales rep. Note that Pega's workbasket is a shared queue — Odoo's team model assigns a lead to one sales rep at a time. If the Pega case was in a shared basket (not individually assigned), the Odoo lead is assigned to the team with a null user_id, and Odoo's lead assignment rules handle routing.

Pega file attachments (pyAttachments) are downloaded from Pega's document storage and re-uploaded to Odoo's ir.attachment table linked to the corresponding crm.lead record. The original filename, MIME type, and create date are preserved. Large file handling follows Odoo's attachment storage configuration (file system or external storage). Inline images embedded in Pega case notes are extracted, saved as files, and the HTML note in Odoo is updated to reference the re-hosted image URL.

Pega case notes (pyNote, case-wide notes, assignment notes) map to Odoo mail.message records with note subtype. The message body carries the original note text; author is resolved by operator email to Odoo res.users. Timestamps are preserved. HTML-formatted Pega notes are stripped to plain text unless the target Odoo instance has the mail extension installed, in which case basic HTML is preserved.

Pega operators (Data-Admin-Operator-ID) are matched to Odoo res.users by email address. Unmatched operators are flagged and can be invited to Odoo before migration or assigned to a placeholder user. Pega Work Groups map to crm.team: the group name becomes the team name, and group members (operators) are added as team members linked to their Odoo user accounts.

Pega SLA metadata stored on assignments (pySLAName, pySLADeadline, pySLARemaining) has no Odoo native equivalent. These values are migrated as custom Char and Datetime fields on crm.lead. Odoo's native SLA tracking requires the Discuss SLA module (Enterprise) or a third-party app from the Odoo Apps store — we document the recommended app and configuration for post-migration SLA setup.

Pega pyStatusWork values (e.g., New, Open, Pending-Approval, Resolved-Completed, Resolved-Cancelled) are mapped to Odoo CRM stage_id values by a value-mapping table. The mapping is defined in the migration plan: Odoo stages are pre-created to correspond to Pega status values. If a Pega status has no equivalent Odoo stage, it maps to the nearest stage and the original Pega status value is preserved in a custom Char field (Source_Status__c).

Pega custom Data Objects created in App Studio (not standard case types) map to either Odoo custom fields on the lead (if the object is a property bag attached to the case) or a separate Odoo model (ir.model) if the object is a first-class entity with its own lifecycle. The mapping decision is made during the migration planning phase based on whether the Pega Data Object has independent records or only exists as case-embedded data.

Where a Pega case references a customer identifier (pyCustomerID) that corresponds to an external party record, we look up the Pega Data Page for that customer and map the record to an Odoo res.partner. If the Pega case embeds contact details (name, email, phone) directly in the case, those fields are extracted and used to create or match an Odoo partner record. The res.partner.id is then linked to the crm.lead via the partner_id field.

Pega pyPriority values (integer 1–5 scale or label-based priority) map to Odoo's priority field (stars: 1–5 on crm.lead) using a value-mapping table. If Pega uses a named priority (Critical, High, Medium, Low), we create a custom selection field on crm.lead with the same labels. The mapping preserves the relative ordering so that high-priority Pega cases land as high-priority Odoo leads.