Migrate from Bloomr to Odoo CRM

Bloomr Contacts map to Odoo res.partner records. The mapping uses name, email, phone, and any custom fields discovered during profiling as direct field-to-field transfers. In Odoo, res.partner serves as both individual contact and organization depending on the is_company flag; we set this to False for person-type records and resolve any company affiliation through Bloomr's Company association. Address fields (street, city, state, zip, country) map to partner fields directly if present in Bloomr's schema. The Bloomr contact ID is preserved in a custom Char field x_bloomr_id for dedupe and audit purposes.

Bloomr Companies map to Odoo res.partner records with is_company set to True. Fields including company name, domain, industry, size, and address map to their Odoo equivalents (name, website, industry_id, employee_size, street, city, state_id, country_id). Custom company properties discovered during Bloomr profiling become custom fields on the res.partner model using Odoo's Studio or direct ir.model.fields creation. Parent-company hierarchy in Bloomr maps to Odoo's parent_id field on res.partner for subsidiary relationships.

Bloomr Deals map to Odoo crm.lead records with type set to opportunity. The deal name becomes crm.lead.name, deal value maps to planned_revenue, and stage maps to stage_id with Odoo stage probability applied from Bloomr's stage configuration. Owner assignment maps from Bloomr owner ID to Odoo user_id on crm.lead. Expected close date maps to date_deadline. Bloomr's deal-to-contact association maps to Odoo's partner_id on crm.lead (the primary contact) and partner_mobile/phone for contact details. We preserve the original Bloomr deal ID in x_bloomr_deal_id.

Each Bloomr deal stage maps to an Odoo crm.lead.stage record created in the destination database before migration. Stage name and sequence order migrate directly. Probability percentage per stage migrates to Odoo's stage probability field, rounded to the nearest integer per Odoo's field type. If Bloomr stages include custom fields (closed-won reason, closed-lost reason), we create corresponding custom fields on crm.lead and migrate values during the Deal phase.

Bloomr Users map to Odoo res.users records. We resolve Bloomr owner assignments on Deals, Contacts, and Activities by matching the Bloomr user email to the Odoo res.users login. Any Bloomr user without a matching Odoo user is held in a reconciliation queue; the customer's Odoo admin provisions missing users before the migration proceeds. Role and permission data from Bloomr maps to Odoo access groups and record rules if the customer has Odoo Access Controls enabled beyond the default.

Bloomr activity records of type call map to Odoo crm.phonecall. We use Odoo's crm_phone module (part of the CRM app) or the base phone module if installed. Call duration, disposition, and timestamp map to duration, state, and date_created on crm.phonecall. The phonecall is linked to the resolved res.partner (contact) via the partner_id field. If the crm.phonecall model is not available in the customer's Odoo version, call records migrate to crm.lead activity history as a note with custom fields capturing duration and disposition.

Bloomr meeting activities map to Odoo calendar.event records. Subject maps to name, start and end time map to start_datetime and stop_datetime, and location maps to location. Attendees (Bloomr contacts associated with the meeting) map to calendar.attendee records linked to the event. We preserve the Bloomr meeting description as the event description. If the customer does not have Odoo's calendar module activated, meetings migrate as notes attached to the related crm.lead or res.partner.

Bloomr email engagement records map to Odoo mail.message records linked to the resolved crm.lead or res.partner via model and res_id. Email subject maps to subject, body to body (HTML preserved), and timestamp to date. The author is resolved to a res.partner record; if the sender email has no matching partner, we create a one-off partner record for the author. Odoo's mail.thread mechanism threads messages by parent_id if a reply-to message_id is present in Bloomr's data.

Bloomr task activities map to project.task if the customer has Odoo Project installed, or to crm.lead activity history if only CRM is active. Task subject maps to name, due date maps to date_deadline, status maps to stage_id or state, and assignment maps to user_id. Description migrates as body text. If the task has a Bloomr deal association, we link the Odoo task to the corresponding crm.lead record via the project_id and task_id relationship or a direct many2one field if Project is not installed.

Bloomr custom fields on Contacts map to Odoo custom fields on res.partner created before migration via ir.model.fields or Odoo Studio. Field type mapping follows Odoo's field types: text fields become char or text, numeric fields become float or integer, date fields become date, checkbox fields become boolean. Selection fields from Bloomr map to Odoo selection fields with the same option values. We preserve the Bloomr custom field name as the Odoo field label with x_bloomr_cf_ prefix on the technical field name.

Bloomr custom fields on Companies map to Odoo custom fields on res.partner (is_company=True) using the same type-mapping logic as Contact custom fields. We scope custom field creation to the res.partner model and set the applies_to context to company-type records during field definition to avoid confusion with individual contact records. Any company-specific taxonomy (industry classification, employee range, annual revenue) that has no Odoo equivalent is created as a custom field.

Bloomr custom fields on Deals map to Odoo custom fields on crm.lead. We create the fields before the Deal migration phase begins, using Odoo's field type system (selection, char, text, float, integer, date, boolean) to match Bloomr's field types discovered during profiling. Lookup relationships from Bloomr custom fields (e.g., a custom field referencing a Contact or Company) map to Odoo many2one fields if the related model exists in the destination database.

Attachment handling in Bloomr is not confirmed through any documented API or export mechanism. We do not include attachment migration in the standard scope. If live API exploration during data profiling confirms attachment endpoint availability, pagination behavior, and file access, we revise scope to include ir.attachment migration linked to the parent res.partner, crm.lead, or related record via res_model and res_id. Until confirmed, we flag this as out-of-scope and recommend manual UI export from Bloomr for any critical attachments.

Bloomr workflow rules, automation triggers, and sequence configurations are not accessible via any documented export endpoint. We cannot migrate automated workflows as structured data. We deliver a workflow audit template during scoping that captures Bloomr workflow name, trigger conditions, actions, and sequence order for the customer's Odoo admin to rebuild in Odoo's Automations module (available from the base CRM app) or via Studio-based server actions and automated actions. This is an out-of-scope item disclosed in the migration agreement before engagement.

Bloomr tags on Contacts and Companies map to Odoo crm.tag records for deal tagging and res.partner.category for contact/company categorization. Tags are stored as many2many relationships; we create the tag records in Odoo before migration and link them via the appropriate many2many field (tag_ids on crm.lead, category_id on res.partner). The customer chooses during scoping whether to use crm.tag, partner category, or a custom multi-select field for their tagging strategy.