Migrate from Oracle EBS CRM to Odoo CRM

Oracle EBS Accounts stored in ARHZTA and exposed through APPS schema map directly to Odoo res.partner records with partner_type set to customer. The Oracle ACCOUNT_NUMBER becomes partner reference, site_address fields map to street/city/country on res.partner, and tax_id maps to vat. Account is extracted first as it is the parent of every Contact and Opportunity in the EBS CRM data model. We scope extraction to ARHZTA base tables and do not touch financial AR tables unless the customer explicitly requires financial migration scope.

Oracle EBS Contacts stored in HR or AR schemas (depending on whether they are employees or external parties) map to Odoo res.partner with parent_id pointing to the Account partner record. First name, last name, email, phone, and title migrate directly. The Oracle CONTACT_POINT table holds multiple contact methods (email, phone, fax) and we map these to res.partner phone and email fields, with additional contact points stored in the Odoo partner_multi_relation module or as custom fields. Relationship links between Contact and Account are preserved via parent_id.

Oracle EBS Opportunities stored in the CZ (Collaborative Selling) or deprecated ASF schema map to Odoo crm.lead. We identify the correct schema at discovery time and extract stage name, probability, expected close date, and revenue amounts. The crm_lead CREATE via XML-RPC is performed after Account and Contact partners are created so that partner_id and contact_id lookups are satisfied. Oracle CLOSED_LOST and CLOSED_WON status maps to Odoo stage_id values that we configure as a pre-migration step.

Oracle EBS Activities and tasks are stored across multiple EBS CRM schemas depending on which CRM module is installed — either the deprecated Teleservice tables or the modern Interaction Center tables. We identify the correct schema at discovery, extract the activity type, timestamp, owner, and related Account/Contact references, and map call-type activities to crm.phonecall in Odoo. Generic task-type activities map to project.task if the Odoo project app is installed; otherwise they map to crm.lead internal notes.

Oracle EBS CRM custom objects reside in user-defined tables within base product schemas and often reference FK columns pointing to core tables like RA_CUSTOMERS or OE_HEADERS. We extract the DDL for every custom table during discovery, identify the referencing FK relationships, and create equivalent Odoo model definitions via a custom Odoo module before importing data. The XML-RPC import targets the newly created Odoo model by its external ID. Custom field types (LOBs, dates, numbers) map to Odoo corresponding field types in the custom module.

Attachments in Oracle EBS CRM are stored as LOB data (BFILE or CLOB columns) in the database or on the file system depending on the attachment configuration. We extract them as BASE64-encoded binary blobs, then upload to Odoo as ir.attachment records via XML-RPC with the res_model and res_id pointing to the related parent record (Account partner, Contact partner, or Opportunity crm.lead). File name and MIME type are preserved in ir_attachment name and mimetype fields.

Notes and audit history in Oracle EBS CRM are stored in generic note tables (FZ_NOTES or equivalent) or in the application-level audit trail. We extract them as text blobs with timestamps and owner references and write them to Odoo mail_message records linked to the parent crm.lead or res.partner. The mail.message model is native to Odoo's messaging architecture and renders in the Chatter thread on the relevant record. Author is resolved via the Odoo res_users mapping.

Oracle EBS Territory definitions stored in AS_TERRITORIES base tables with hierarchical org structure map to Odoo crm_team records. We extract the territory hierarchy and assignment rules during discovery and create corresponding crm.team records with member assignments. Odoo crm_team does not support the full hierarchical territory model that Oracle provides, so we flatten the hierarchy to a single crm.team per territory and note the parent-child relationship in the handoff documentation for the customer's Odoo admin to implement via custom code if needed.

Oracle EBS Forecasting is implemented through the Collaborative Selling module and stores forecast data in versioned CZ tables with tight coupling to Opportunity and Territory objects. There is no standard migration path for Oracle EBS Forecast records to any cloud CRM including Odoo. We extract forecast snapshots as a structured CSV report with opportunity references, forecast amounts, and version timestamps, and deliver this as a reference document for the customer to manually enter into Odoo's crm.lead expected_revenue field or to use as a baseline for rebuilding a forecast model in Odoo.

Oracle EBS CRM Users are employees sourced from HR schema (PER_ALL_ASSIGNMENTS_F) with CRM-specific responsibilities assigned via FND_RESPONSIBILITY. We extract the FND_USER and FND_RESPONSIBILITY tables during discovery to build an accurate user count and responsibility matrix. Users are mapped to Odoo res_users by matching email addresses. Any EBS user without a corresponding Odoo user is held in a reconciliation queue for the customer's admin to provision before record import begins. The responsibility matrix informs Odoo access rights group assignments.

Oracle Workflows (stored in WF_ tables and implemented via PL/SQL packages) encode the routing, approval, and notification logic specific to EBS. These definitions cannot be exported as structured data and have no equivalent construct in Odoo's automation model. We document every active Workflow at discovery, capturing the triggering event, routing conditions, and approver assignments in a structured report. This report is handed off to the customer's Odoo implementation team to rebuild the automation logic using Odoo Studio or a custom module.

If the Oracle EBS CRM deployment includes the Teleservice or Interaction Center Lead module, Leads are stored in module-specific tables. We identify the correct table at discovery, extract lead name, status, source, and owner, and map to Odoo crm.lead with type = lead. The crm.lead record retains type = lead until the customer runs the Odoo lead_to_opportunity wizard, which converts it to type = opportunity and creates the associated partner record.

If Oracle EBS Order Management or Pricing modules are in scope, Oracle product and price book data stored in the Oracle Pricing tables (QPN tables) maps to Odoo product_product records. Product name, description, list price, and cost map directly. If only CRM data is in scope (no Order Management migration), we extract product references as external ID strings on crm.lead rather than full product records, to avoid migrating financial data outside the agreed CRM scope.