Migrate from Pega Customer Engagement Suite to Odoo CRM

Pega Work Objects are case instances with status, priority, assignment, stage, and audit history. We extract pyStatusWork, pyAssignment, and stage fields and map them to Odoo CRM Opportunity records with custom stage mapping. High-volume organizations with complex case types may opt to map Work Objects to Odoo Project tasks under a Cases project, which we configure during schema design. pyStatusWork (case status) maps to crm_stage; pyAssignment (assignee) resolves via email lookup to Odoo User. Historical case audit entries migrate as Opportunity description text or attached notes for audit trail continuity.

Pega Customer Profiles store contact information, interaction history, and preferences. We map standard fields (name, email, phone, address) to Odoo Contact records, and organization-level data (company name, industry, segment) to the related Odoo Company (res.partner with is_company=True). Customer Profile custom properties map to Odoo Contact custom fields. The Pega customer profile ID is preserved in a custom field for cross-reference.

Pega Entities map to database tables and often represent domain-specific data beyond standard Customer Profiles. We extract each Entity's populated records and map fields to Odoo Contact, Company, or custom fields depending on cardinality and relationship structure. Custom Entities with foreign-key relationships to Customer Profile are resolved by looking up the parent Customer Profile ID and creating the corresponding Odoo Contact or Company first, then populating the custom fields. This requires a dependency-ordered import sequence.

Pega Data Pages are cached data structures used by applications to retrieve and display information. We extract cached data values from Data Page records and map them to Odoo custom fields on the relevant Contact or Company, or to ir.model.data records for reference data (e.g., country lists, product categories) that Odoo already manages natively. Reference data that already exists in Odoo (countries, currencies, states) is not re-imported but verified for completeness.

Pega Case Types define the template for Work Objects, including stages, steps, assignments, and routing rules. We document each Case Type configuration as a written specification for manual rebuild in Odoo Studio, including stage definitions, assignment rules, and SLA thresholds. Odoo does not replicate Pega's SLA enforcement natively, so SLA rules are noted for rebuild using Odoo server actions with date-based deadline tracking.

Pega's Next-Best-Action decision rules and Decision Manager logic trees are AI-driven and Pega-specific. These cannot be extracted and translated to any other platform. We deliver a written inventory of every active decision strategy with its context (which case type, which channel, which customer segment), the current rule weights, and a recommendation for manual rebuild using Odoo Studio conditions and server actions or a third-party decision engine. This documentation is the handoff artifact; we do not migrate decision rules as code.

Pega workflows authored in Pega's low-code BPMN-adjacent syntax do not export in a standard format compatible with Odoo or any other CRM. We export workflow definitions as written documentation (stage list, routing conditions, SLA definitions, escalation triggers) for manual rebuild in Odoo CRM Studio using automated actions, server actions, and Python constraints. The rebuild scope depends on workflow complexity; a simple five-stage case routing takes days to rebuild, while complex multi-channel decisioning may take weeks.

Pega custom fields extend standard objects and are associated with Rules. We extract field names, data types, and all populated values, then map them to Odoo custom fields on the appropriate object (res.partner for Contacts, crm.lead for Opportunities). Field type mapping from Pega to Odoo: text to char or text, integer to integer, decimal to float, date to date, boolean to boolean, picklist to selection field. Multi-value fields map to Odoo char fields with comma-separated values or to tags depending on the customer's preference.

Pega report definitions, dashboard configurations, and analytics views are platform-specific and do not transfer across systems. We deliver a written inventory of every Pega report with its data source objects, filters, groupings, and chart types. Odoo CRM uses its own reporting engine (crm_lead_report, pivot views) and integrates with Odoo's BI tool (Reporting engine, or third-party like Pentaho). The customer's admin or an Odoo reporting specialist rebuilds reports post-migration.

Pega Work Object assignees (pyAssignment) and Customer Profile owners are resolved by email match against Odoo User records. We extract every distinct Pega user referenced on migrated records and attempt email-based matching against the destination Odoo User table. Unmatched users go to a reconciliation queue for the customer's admin to provision before record import resumes. Odoo User records (active=True) are required for OwnerId resolution on Opportunities and Contacts.

Pega engagement records (if stored as separate activity logs alongside Work Objects) migrate to Odoo CRM Activity records (mail.mail, crm.phonecall, calendar.event). We extract activity type, timestamp, subject, body, and assignee, then create the corresponding Odoo activity record linked to the parent Contact or Opportunity. Activity ordering is preserved by setting create_date to the original Pega timestamp. Pega's assignment history (which user handled which case stage) migrates as a Note attachment for audit continuity.

Pega entities representing organizations (as opposed to individual Customer Profiles) map to Odoo Company records (res.partner with is_company=True). Organization name, address, industry classification, and custom properties migrate to the Company record. Individual Customer Profiles linked to that organization map to Odoo Contact records with parent_id set to the Company record, establishing the Contact-Company hierarchy that Odoo CRM uses for reporting and pipeline attribution.