Migrate from Firmao CRM to Odoo CRM

Firmao Contact records (GET /svc/v1/contact) map to Odoo res.partner with company_type='contact'. We extract name, email, phone, address fields (street, city, postal_code, country) and resolve the parent company via companyName matching against Firmao Company records before inserting into Odoo, populating the parent_id lookup. Custom contact fields (customFields.customN) are mapped after the Odoo custom field definition is created during schema setup. Owner assignment is resolved via email matching against Odoo res.users.

Firmao Company records (GET /svc/v1/company) map to Odoo res.partner with company_type='company'. The company name becomes partner name, and address components (street, city, postal_code, country) are split into Odoo address fields. Company records are imported before Contacts so that parent_id lookups resolve at Contact insert time. Custom company fields follow the same dot-notation extraction and Odoo custom field pre-creation pattern as Contacts.

Firmao Deals (GET /svc/v1/deal, available on Professional and above) map to Odoo crm.lead. We verify the customer's Firmao tier during scoping before attempting Deal extraction; accounts on Standard tier have no Deals to migrate. Deal name maps to crm.lead name, dealstage maps to stage_id (resolved via crm.stage name matching), and dealValue maps to planned_revenue. Owner is resolved by email. The Firmao subClass/subId envelope for deal-to-task associations is handled via a note on the crm.lead record until the Tasks phase inserts project.task records.

Firmao Tasks (GET /svc/v1/task) map to Odoo project.task. The subClass/subId envelope carries the associated dealId or contactId reference. We use dealName matching against the migrated crm.lead to resolve project_id on the task, and contactId to resolve the user_id or partner_id. Status (pending, inProgress, completed) maps to Odoo stage_id within a dedicated project.project created for the migration. Due dates and assignee are preserved directly.

Firmao Products (GET /svc/v1/product) map to Odoo product.product with name, default_code (product code), list_price, and standard_price preserved. The product's base fields migrate as-is. We create a corresponding product.template record alongside product.product per Odoo's internal architecture. Custom product fields (customFields.customN) follow the standard dot-notation extraction pattern.

Firmao warehouse stock is not a standalone object — it returns as subClass=warehouse subId entries within the product GET response, carrying netPriceInStore and currentStoreState per warehouse. We extract each subId variant as a separate Odoo stock.location record with location_type='internal' and a corresponding stock.quant record for each product-location combination, setting the quantity from currentStoreState. This flattens the nested envelope structure into Odoo's flat stock management model.

Firmao Users (GET /svc/v1/user) export as name, email, and role. We map the role string to an Odoo access rights group (for example, 'admin' maps to 'CRM Manager' group, 'user' maps to 'Sales' group). Owner assignments on Deals and Tasks are resolved by email match against the migrated res.users records. Users without a matching Odoo account enter a reconciliation queue for the customer's admin to provision before the record import resumes.

Firmao custom fields are defined in Professional and above under Settings and referenced in the API using dot-notation keys (customFields.custom5, customFields.custom12). There are no human-readable labels in the API response. We retrieve a sample record via GET first to enumerate which custom field keys are populated, then cross-reference against the customer's import documentation. Each active custom field key gets an Odoo ir.model.fields definition created before any data import begins, with the field type set to 'char' for string values. Empty custom fields in the sample export are flagged and excluded.

Tags appear as a comma-separated property on Firmao Contact and Company records with no dedicated /tags endpoint. We extract the tag values as a list during export and create corresponding res.partner.category records in Odoo (or match to existing categories by name). Each Contact or Company receives res.partner.category assignments via res.partner.respartner_rel_m2m during import.

Pipeline stages are not a standalone API object in Firmao — they are a property value on each Deal record. We export the distinct stage names from the Deal dataset and create corresponding crm.stage records in Odoo before Deal import begins. Stage sequence order and probability percentages are set on each stage. If the customer has custom stage names (not the Firmao defaults), we use those verbatim in Odoo.

Firmao Invoices (VAT invoices, bills, receipts, accounting notes) are accessible via the API with line items, tax codes, and payment status. We map invoice headers to Odoo account.move records with move_type='out_invoice' or 'in_invoice' depending on direction, and line items to account.move.line. Note that the full invoice financial workflow (payments, reconciliation, aged receivable reports) requires an Odoo Accounting configuration that is out of scope for the data migration itself.

Firmao Projects (available on Professional and above, with Gantt and Kanban views) migrate as project.project with name, description, and date_start. The project task associations map to the project.task records already migrated. The Gantt bar positions and Kanban column configuration are visual layout data that do not have a structural equivalent in Odoo's project.project model and are not migrated.