Migrate from FieldEdge to Odoo CRM

FieldEdge customers map 1:1 to Odoo res.partner records. The is_company flag is set based on FieldEdge's customer type — businesses with multiple contacts use parent_id on the child partner records to establish the company hierarchy. Primary service address maps to partner address fields; billing address maps separately or as the same record depending on configuration.

FieldEdge work orders are the core operational record with no direct Odoo CRM equivalent. We map job number, status, scheduled date, assigned technician, service address, labor hours, parts used, and job total to custom fields on crm.lead. If Odoo Project is deployed (Enterprise), work orders map to project.task linked to the partner record. This choice is validated during the sample migration phase.

FieldEdge invoices map to Odoo account.move records with move_type='out_invoice'. Invoice line items map to account.move.line with product_id linked to the migrated product catalog. Payment_state in Odoo reflects the FieldEdge payment status — paid, outstanding, or overdue. Invoice date and due date are preserved from FieldEdge's create_date and due_date fields.

FieldEdge service agreements track plan name, coverage type, contract value, start date, renewal date, and coverage details. Since Odoo CRM has no native service-agreement object, we create custom fields on crm.lead: x_service_plan, x_coverage_type, x_contract_value, x_agreement_start, x_renewal_date, and x_coverage_notes. If sale.subscription is active, we map agreements there instead with a link to the partner record.

FieldEdge users and technicians map to Odoo res.users by email address match. Active status is preserved. FieldEdge role distinctions (office staff vs. field technician) are translated to Odoo access groups — the dispatcher and admin roles get full CRM access; technician roles get mobile and field-service access. Unmatched FieldEdge users are flagged before migration so Odoo accounts can be pre-created.

FieldEdge parts and materials catalog maps to product.template with type='product'. List_price and standard_price are populated from FieldEdge's unit price and cost fields. The product's description maps to product.template's description field. If FieldEdge tracks inventory quantities, these map to product.qty_on_hand via Odoo's stock quant model.

FieldEdge work order status values (e.g., Scheduled, In Progress, On Hold, Completed, Invoiced) map to Odoo crm.stage names specific to the sales team. We create a dedicated pipeline stage set for the migrated work order data. Probability values are assigned per stage to support Odoo's revenue forecasting model. Stage timestamps are preserved as custom datetime fields on the opportunity.

FieldEdge payment status values (Paid, Outstanding, Overdue, Void) map to Odoo account.move payment_state values (paid, in_payment, outstanding, overdue, void). The mapping is direct value-by-value. Any partial payments recorded in FieldEdge are reflected as payment registers linked to the account.move in Odoo.

FieldEdge custom properties on customers that have no Odoo standard field equivalent become ir.model.field records on res.partner. We create custom fields before migration and map source values during data load. Field type in Odoo is chosen based on the source data type — char, text, selection, or float. Custom field names in Odoo use the x_ prefix convention.

FieldEdge work-order-level custom properties map to custom fields on whichever Odoo object holds the work order data. If work orders map to crm.lead custom fields, those fields are added there. If project.task is used, custom fields are added to project.task. Type-aware mapping applies — date fields become date fields, numeric fields become float or integer, etc.

FieldEdge estimates and proposals that are not yet converted to work orders map to Odoo sale.order in draft state. Line items map with product_id, product_uom_qty, and price_unit from the FieldEdge estimate. If the estimate has an accepted status in FieldEdge, we create the sale.order as confirmed. Rejected estimates are preserved as lost opportunities with a custom lost_reason field.

FieldEdge's internal record IDs are stored on every migrated object as a custom Char field (e.g., x_fieldedge_id) for traceability and delta-run deduplication. This field is indexed in Odoo and used in the WHERE clause during subsequent delta-pickup queries to avoid creating duplicate records on re-runs.