Migrate from Civicrm to Odoo CRM

CiviCRM Individual contacts map to Odoo res.partner with is_company=False and individual_type set to 'natural_person'. Standard name fields (first_name, last_name), addresses (with location_type: work, home, other), emails (with location_type), phones (with phone_type), and the contact's preferred_language migrate directly. We resolve the CiviCRM preferred_language field to res.partner lang field at import time.

CiviCRM Organization contacts map to Odoo res.partner with is_company=True. Organization name maps to name (not legal_name separately), and the legal_name field from CiviCRM maps to Odoo's company_registry if a registry number is present. Organization subtypes (Employer, Government, Non-profit) map to Odoo customer_rank and supplier_rank flags based on the organization's contribution history.

CiviCRM Household contacts have no native Odoo equivalent because Odoo's res.partner model treats households as Organizations with individual members. We create a parent Partner record for the household and attach individual members as child contacts with partner_share=True. The household address migrates to the parent partner; member relationship types (e.g., 'head of household') map to Odoo res.partner relation types that we pre-create during schema setup.

CiviCRM Activities (calls, emails, meetings, tasks) map to Odoo Project tasks in a dedicated 'CiviCRM Activity History' project. Each activity type (Meeting, Phone Call, Email, Task) becomes a task with the original activity subject, details body, date, and assignee preserved. We use the Odoo Project API to create tasks in batch, with the project_id resolved before task import begins.

CiviCRM Groups with static membership (GroupContact records) map to Odoo Tags on the Partner record. For groups larger than 500 members where tag proliferation becomes unwieldy, we create a dedicated Odoo Project team or partner category hierarchy and add members to that team. Dynamic (smart) groups cannot be reproduced without re-running the filter logic; we document the filter criteria for the customer's admin to implement in Odoo.

Odoo has no native donation or contribution module in the base CRM. We create a custom crm.donation model with fields mapping to financial_type, total_amount, currency, receive_date, payment_instrument, and contribution_status. For organizations already using Odoo Accounting, we alternatively map Contributions to Account Move lines (invoices/payments) linked to the partner, which provides native financial reporting. The customer chooses the model during scoping, and we pre-create the custom model via Odoo data migration before any records load.

CiviMember records (type, status, start_date, end_date, source, membership_price_set tier) map to custom fields on the Odoo res.partner: membership_type__c, membership_status__c, membership_start_date__c, membership_end_date__c. For organizations with complex membership tier structures, we create Odoo Product.product variants representing each tier and link them to the partner via sale order lines for historical tracking. We preserve the membership status timeline (new, current, grace, expired) as a status history JSON blob in a long-text field.

CiviCRM Events map to Odoo Calendar events with event_type, start_date, end_date, and location preserved. CiviCRM participant roles (Attendee, Speaker, Volunteer, Host) map to custom event.registration fields or tags. If the Odoo Events app is not installed in the destination database, we fall back to Project tasks with a dedicated 'Events' project to preserve event records. Price sets for paid events require Odoo Product and Sale Order line mapping before event registrations migrate.

CiviCase records map to Odoo Project with a dedicated project per case_type. Each case's activity chain (the set of CiviCRM Activities linked to the case) migrates as sequential tasks within the Odoo project. We enumerate every active case_type during scoping, extract its status option values, and create corresponding Odoo stage records in the project. The Odoo project name carries the original CiviCRM case_id for audit traceability. Case statuses are type-scoped in CiviCRM and must be extracted per case_type XML before mapping.

CiviCRM relationship types (employee-employer, spousal, household member, etc.) map to Odoo res.partner relation types that we pre-create during schema setup. Both the source and target contact must exist in Odoo before the relationship can be established, so we load contact records before relationship records. The bidirectional flag on CiviCRM relationship types translates to a symmetric Odoo relation type where applicable.

CiviCRM Tags are flat entity-level labels that attach to Contacts, Activities, or other records. We map them to Odoo res.partner.category entries for Contact tags, and to Project task tags for Activity tags. Multi-entity tagging is split into separate tag migrations per entity type since Odoo tags are model-scoped.

Grants is an optional CiviCRM extension present in some nonprofit instances. We create a custom crm.grant model in Odoo with grant_type, amount_requested, amount_granted, status, and deadline fields, linked to the applying Organization partner. For organizations that use Odoo Project for grant-funded work, we alternatively map grants to project milestones with the grant amount as the milestone value.

ECK allows arbitrary custom entity types in CiviCRM with user-defined schemas. These have no standard mapping to Odoo. We pre-create a corresponding custom model in Odoo (via ir.model and ir.model.fields) for each ECK entity type, preserving all custom property fields and any contact lookups. ECK entity data migrates as records in the new custom model after the standard contact migration completes. The customer identifies ECK usage during scoping.

CiviCRM stores file attachments in the database (civicrm_file / civicrm_entity_file) or on the filesystem. We extract the file content and re-associate with the destination record using the original CiviCRM entity table name and entity_id as an external reference stored in the ir_attachment description field. Files linked to Contacts attach to the migrated Odoo partner; files linked to Cases attach to the migrated Odoo project task.

CiviCRM single-record custom fields on contacts (custom groups with is_multiple=False) map to custom fields on res.partner in Odoo. Multi-record custom groups (Custom_* prefixed tables) map to Odoo one2many lines on a custom model that we create per custom group. We query the total custom group count during scoping; sites with more than 20 custom groups exceed MySQL's 61-join limit in CiviCRM APIv4 and require entity-by-entity export rather than bulk wildcard queries.