Migrate from The Customer Factor to Odoo CRM

Customer Factor flat contacts vs Odoo res.partner / crm.lead split

The Customer Factor does not distinguish between raw leads and active customers — every record is a flat customer or prospect with no separate contact-company relationship model. Odoo uses res.partner for companies and individual contacts and crm.lead for pipeline opportunities. We split Customer Factor records by looking at whether a record has an active estimate, job, or invoice: records with billing activity land as res.partner commercial contacts; records with no sale history and an open prospect status land as crm.lead. The is_company flag on res.partner is inferred from whether the record has child contact records or a company name field populated. This mapping is the most consequential decision in the migration because it determines which records appear in Odoo's CRM pipeline versus the Contacts app.

Estimate to sale.order transformation requires line-item relinking

The Customer Factor stores estimate line items within the estimate record as an embedded list. Odoo sale.order stores order lines in a separate sale.order.line table with a many2one link to sale.order and a many2one link to product.product. When The Customer Factor estimate has no product ID (just a description and price), we create an Odoo product.product record for it or store the line as a description-only sale.order.line with no product_id. Either way, the line-item relationship must be re-established during migration because Odoo relies on product_id for stock reservation and COGS reporting. Estimates without line items are migrated as sale.order records with zero lines for reference.

Custom fields in The Customer Factor have no schema declaration — Odoo requires field definition first

The Customer Factor stores custom field values as key-value properties on each record with no central field registry — two customers can have the same custom property with different casing or spelling. Odoo custom fields must be defined as Python field declarations on the model before any data can be written to them. Before migration, FlitStack enumerates all unique custom field keys across the Customer Factor dataset, deduplicates them, assigns Odoo field types based on value inspection (text vs. number vs. date), and creates the custom field definitions on the crm.lead or res.partner model via Odoo's ir.model.fields. If The Customer Factor has 15+ custom fields, this pre-mapping step adds planning time.

Odoo does not have a native CRM workflow engine — automation must be rebuilt

The Customer Factor allows follow-up automation rules (e.g., send reminder when job status changes, auto-assign based on zip code). Odoo does not have a direct equivalent for CRM-specific automation in its base module — automation logic lives in Odoo Studio's Business Rules (available in Odoo Studio or Enterprise) or in Python code within a custom module. FlitStack exports the Customer Factor automation rule definitions as a JSON document for your Odoo admin to reference when rebuilding in Odoo Studio. The automation rules themselves do not migrate.

Odoo attachment storage requires ir_attachment records with correct res_model / res_id

The Customer Factor attaches files to customer or job records with no formal content-type enforcement. Odoo stores every file as an ir_attachment record with res_model (the Odoo model name, e.g., crm.lead or res.partner) and res_id (the database ID of the linked record). Files migrated without the correct res_model/res_id combination will be uploaded but orphaned from the record view. Because Odoo IDs are assigned at insert time and are not known until after migration, attachment migration must run as a second pass after all crm.lead and res.partner records have been created and their Odoo IDs are known.