Migrate from OPEX 365 CRM to Odoo CRM

OPEX 365 CRM Contact records map to Odoo res.partner with partner_type set to contact. We map fullname, email, phone, mobile, street, city, state, country, and birthday fields directly. Owner assignments from Dataverse (owninguserid) map to Odoo user_id on the partner if the partner record has a CRM salesperson assignment; otherwise the record lands without an owner and the customer's admin assigns it post-migration. Lifecycle stage or contact status from OPEX 365 CRM custom fields migrates to a custom partner field for segmentation.

OPEX 365 CRM Account records map to Odoo res.partner with is_company=True. Industry classification, annual revenue, number of employees, and address fields migrate to their equivalent Odoo partner fields. The Account-Contact parent-child hierarchy is preserved by linking Contact partner records to their parent Company partner record via parent_id. Odoo enforces that is_company=True partners have no parent_id.

OPEX 365 CRM Opportunities map to Odoo crm.lead records with type=opportunity. Pipeline stage names from OPEX 365 CRM migrate as stage_name strings that the customer maps to Odoo stage IDs during configuration. Estimated close date maps to date_deadline. Estimated revenue and probability map to planned_revenue and probability. Opportunity type (new business vs. existing business) maps to Odoo's type field. Lost reasons from OPEX 365 CRM custom fields become Odoo crm.lead lost_reason field.

OPEX 365 CRM Lead records (if present as a separate entity from Opportunity in the source deployment) map to Odoo crm.lead with type=lead. Lead status from OPEX 365 CRM becomes stage_name in Odoo's lead pipeline. Lead score or grade from OPEX 365 CRM custom fields migrates to a custom float field on the Odoo lead. If the source deployment uses Opportunities to represent all prospect records, those records land in Odoo as type=opportunity without a separate lead record.

OPEX 365 CRM pipeline and stage metadata are organizational configuration that do not export through the Dataverse API as data records. We document the source pipeline names, stage labels, stage order, and probability percentages during discovery. The customer recreates the pipeline structure in Odoo via CRM > Configuration > Stages before migration, and we provide a stage mapping table that connects each source stage label to the destination stage_id. Closed-Lost and Closed-Won states must be explicitly mapped because Odoo uses stage names rather than a separate status field.

OPEX 365 CRM Cases (incident entities) map to Odoo helpdesk.ticket if the customer licenses the Odoo Helpdesk module, or to project.task if they manage cases as project work. Case status (Active, Resolved, Cancelled) maps to Odoo stage_id. Priority, subject, and entitlement associations migrate to ticket priority, name, and project_id. We recommend the Helpdesk module path because it provides a dedicated ticket interface; if the customer does not license Helpdesk, project.task is the fallback.

OPEX 365 CRM email activitypointer records with direction=outbound map to Odoo mail.message records with message_type=email on the corresponding crm.lead or res.partner. We resolve the activityparty.pollingPartyId to the target Odoo partner or lead at migration time. Email body (activitypointer.bodymarkdown) migrates as mail.message.body in HTML format. Inbound emails map to incoming mail.message records if the customer uses Odoo's incoming mail gateway.

OPEX 365 CRM phone call activitypointer records map to Odoo crm.phonecall (an addon object if the customer installs the CRM phonecalls module). Call duration from durationinminutes maps to duration. Direction, result, and disposition from OPEX 365 CRM map to crm.phonecall state and partner_id. If the customer does not install the phonecalls module, calls fall back to project.task with a custom call_type field.

OPEX 365 CRM standalone task activitypointer records map to Odoo project.task linked to the crm.lead or res.partner via project_id (a default CRM project is created if no project assignment exists). Task subject maps to name, scheduled start maps to date_begin, due date maps to date_deadline, and priority maps directly. Owner assignment from OPEX 365 CRM activitypointer.owninguserid maps to project.task.user_id.

OPEX 365 CRM appointment activitypointer records map to Odoo calendar.event with start_datetime and stop_datetime preserved from the original timestamps. Location maps to location. Attendee records from OPEX 365 CRM activityparty references map to calendar.attendee records with partner_id resolved to Odoo res.partner. Odoo calendar.event is linked to a crm.lead or res.partner via the calendar.event.res_id.

ActivityParty is the highest-risk polymorphic join in this migration. Each activityparty record references a single pollingPartyId that may point to a Contact, Account, Lead, or User entity. Odoo CRM does not have a polymorphic party model; every activity record must have a typed partner_id or lead_id. We run a pre-import referential integrity pass that queries all pollingPartyId values across activity records, checks whether a corresponding Odoo partner or lead exists, creates placeholder res.partner records for any missing targets, and flags any activityparty records that reference inactive or deleted source entities for the customer to review.

OPEX 365 CRM Notes are stored as annotation entities with notetext and filebody (base64-encoded content). Notes without attachments migrate as mail.message records on the target res.partner or crm.lead. Notes with attachments require separate extraction using the Dataverse RetrieveContent放电 API. We store the binary content in staging blob storage, then upload it to Odoo ir.attachment and link it to the parent record via res_model and res_id. The annotation.filename field preserves the original filename.

OPEX 365 CRM Product records map to Odoo product.product. Product name, default unit of measure, list_price, and standard_cost migrate directly. The OPEX 365 CRM productpricelevel pricing tiers migrate to Odoo product.pricelist item records under the default pricelist. Bundle or kit structures from OPEX 365 CRM do not have a direct Odoo equivalent; we document bundle compositions as a product kit note and the customer recreates the kit structure manually in Odoo if needed.

Custom entities discovered via the Dataverse EntityDefinitions endpoint are not automatically translatable to Odoo. We enumerate each custom entity, its attributes, data types, and lookup relationships during discovery. For each custom entity, we produce a written schema specification with the recommended Odoo implementation approach: a custom Python model (res.partner subclass or standalone model) with fields added via Odoo Studio or custom module development. Custom entity records migrate as rows in the newly created Odoo model, with lookup fields resolved via parent-record lookup passes before import.

OPEX 365 CRM Dataverse users map to Odoo res.users by email address. Security roles and business unit assignments from Dataverse have no Odoo equivalent and are noted for the customer's admin to configure in Odoo Access Rights. Any activityparty or activitypointer record with an owninguserid that does not resolve to an Odoo res.users record is flagged in the owner reconciliation report for manual provisioning before record import begins.