Migrate from Fireberry to Odoo CRM

Fireberry Contact records map to Odoo res.partner with partner_type = 'contact'. Name, email, phone, address, and owner assignment migrate directly. Fireberry's lifecycle stage maps to a custom Char field fb_lifecycle_stage__c on res.partner for audit continuity. We import res.partner before any Deals to satisfy the Many2One partner_id foreign key on crm.lead (Odoo's opportunity model).

Fireberry Company records map to Odoo res.partner with partner_type = 'company'. Industry, company size, and address fields migrate to the corresponding Odoo res.partner fields. The Company-to-Contact parent relationship maps to res.partner's child_ids (child partners). Company domain becomes the Website field for deduplication during import.

Fireberry Deals map to Odoo crm.lead in opportunity mode. Deal amount maps to Odoo's Planned Revenue field. Fireberry's pipeline assignment maps to a crm.team scoped stage within Odoo, and dealstage maps to crm.lead stage_id with stage probability migrated from Fireberry. The Contact and Company links on the Deal become crm.lead partner_id and partner_id.company_held references respectively.

Fireberry pipelines become Odoo crm.team records with their own stage sequences. Each Fireberry pipeline stage maps to an Odoo crm.stage entry with Is Won and Stage Type flags configured. We reconstruct stage ordering and probability percentages per Odoo's stage model. Stages with zero records in Fireberry are flagged for the customer to decide whether to create them in Odoo or drop them.

Fireberry Activities map to Odoo mail.activity for planned actions (calls, meetings, tasks) and mail.message for historical records (logged calls, completed meetings). Activity type from Fireberry determines Odoo activity_type_id. Owner assignment resolves to Odoo res.users by email match. Timestamps and duration fields migrate to mail.activity date_deadline and Odoo's activity type duration fields.

Fireberry Custom Objects (user-defined Components that function as standalone record types) map to Odoo IrModel custom models. We pre-create the Odoo custom model schema — including all custom field definitions (IrModelField with ttype, relation, and required flags — before any data import. Fireberry Component names become Odoo model names with a custom_ prefix, and field names are mapped to Odoo's snake_case naming convention.

Fireberry custom fields on standard objects (Contact, Company, Deal) map to Odoo custom fields on the equivalent model. Text fields map to Odoo char or text; numeric fields map to float or integer; date fields map to date or datetime; picklist fields map to Odoo selection fields. We create the Odoo field definitions in the target environment before importing data. Any formula or computed fields from Fireberry are noted as requiring Odoo computed field replacement.

Fireberry tags on Contacts and Companies migrate to Odoo crm.tag records for Deals and res.partner.category for Contacts and Companies. Tags are exported as flat lists per record and imported as tag_ids many2many relationships in Odoo. The customer chooses at scoping whether tags should be unified across object types or kept separate per Odoo's native tag scoping.

Fireberry file attachments are included as download references in the export. We preserve attachment filenames, MIME types, and linked record references. Attachments hosted internally by Fireberry require re-upload; we document every attachment reference and flag any that are Fireberry-internal-hosted so the customer can re-upload them post-migration. Odoo ir.attachment records are created with the correct res_model and res_id references to the parent migrated record.

Fireberry Owner records (name, email, role, team) map to Odoo res.users. We resolve Fireberry owners by email match against the destination Odoo instance. Any Fireberry Owner without a matching Odoo User goes to a reconciliation queue for the customer's admin to provision the User before record import proceeds, because OwnerId references are required on crm.lead and res.partner.

If Fireberry contains product records, they map to Odoo product.template (and product.product variants). Product name, SKU, unit of measure, and list price migrate directly. Odoo's product variant model is created only if Fireberry products have variant attributes; otherwise product.template alone suffices.

Fireberry workflow rules (trigger-action pairs stored as configuration) are captured as structured text records during scoping but cannot be exported as reusable definitions. We deliver a written inventory of every active Fireberry workflow with its trigger, conditions, actions, and recommended Odoo Server Action or Automated Action equivalent for the customer's admin to rebuild in Odoo Studio post-migration. This is not a code migration; it is a documented handoff.

Fireberry reporting views are configuration-dependent and not exportable as reusable report definitions. Underlying data — Deals, Activities, Contacts — migrates so Odoo pivot, graph, and spreadsheet views can be rebuilt. We provide a written report inventory listing each Fireberry report's metrics, filters, and chart type for the customer to recreate in Odoo Reporting or via Odoo Spreadsheet.

If Fireberry contains historical invoice or subscription records, these map to Odoo account.move entries. Fireberry invoice data (line items, amounts, dates, partner references) merges into Odoo accounting records, but only if the Odoo Accounting app is active in the destination instance. If the customer is using only the CRM module without Accounting, we flag invoice data as requiring a separate accounting migration scope.