Migrate from Field service software to Odoo CRM

Field service customer records map directly to Odoo res.partner entries. Both company-level and individual contact records use the same partner model in Odoo—company contacts use partner type 'company' while individual technicians or client contacts use type 'contact'. Primary address, phone, and email fields translate 1:1. Parent-company hierarchies in the source system map to res.partner.parent_id for multi-location accounts.

Each work order becomes an Odoo crm.lead record representing the service opportunity or job ticket. The source work order name maps to crm.lead.name, job status maps to crm.stage via a value-mapping table, and the linked customer maps to the partner_id foreign key. Original work order number is preserved as a custom reference field for audit continuity. Line items or service tasks attach as sale.order.line records after opportunity conversion.

Technicians and field workers map to Odoo res.users entries so they can be assigned as crm.lead owners or linked to calendar.event records. Owner resolution uses email matching against Odoo user accounts—if no match exists, records are assigned to a fallback owner and flagged for admin review. Active/inactive status translates directly; archived technicians may be preserved as inactive users or contacts depending on reporting needs.

Scheduled appointments and dispatch time slots map to Odoo calendar.event entries. Start and end datetimes, timezone, and technician assignment (user_id) translate directly. Events are linked to the corresponding crm.lead via the res_model and res_id fields, creating a navigable link between the scheduling layer and the opportunity record. Recurring schedule patterns are noted but require manual Odoo calendar recurrence configuration.

Individual line items on a work order—parts used, labor hours, service fees—map to Odoo sale.order.line records attached to a sale.order created from the converted crm.lead. Product records in the source system map to product.product entries in Odoo; if no matching product exists, a placeholder product is created during migration and flagged for product catalog cleanup. Quantities and unit prices translate 1:1; discount fields map to discount percentage where supported.

Invoiced work orders map to Odoo account.move records with move_type 'out_invoice'. Customer name, invoice date, due date, and line amounts translate directly. The source invoice number is preserved in account.move.ref for cross-system reconciliation. If the source platform tracks paid versus outstanding status, payment state maps to Odoo's payment_state field (Paid, Partial, Unpaid, Reversed). Credit notes map to account.move with move_type 'out_refund'.

Equipment records tied to work orders map to Odoo maintenance.equipment only if the maintenance module is active in the target Odoo instance. Without it, equipment data migrates as custom fields on the crm.lead (Equipment_Name__c, Equipment_Model__c, Serial_Number__c) or as notes attached to the partner record. We surface this as a configuration decision before the migration run.

Notes attached to work orders migrate as Odoo ir.attachment records linked to the corresponding crm.lead via res_model='crm.lead' and res_id set to the lead's database ID. File names, MIME types, and file contents are preserved. Odoo's attachment storage limit (default 25MB per file) applies; larger files are flagged and re-hosted post-migration.

Every migrated record receives a custom Char field (Source_ID__c) on the primary Odoo model storing the original platform's internal record ID. This field enables delta-run de-duplication, rollback identification, and cross-system audit trails. The field is created as a Char field with index=True for fast lookups during the delta-pickup phase.

Source-specific custom fields on work orders (e.g., dispatch_priority, site_location, service_category, work_order_type) require Odoo custom field creation via Settings > Technical > Custom Fields. We create Char, Selection, or Integer fields depending on the source field type, then map values row-by-row during migration. Pick-list value sets require value_mapping entries per distinct option.

Work order owners in the source system resolve to Odoo res.users records via email address matching. Unmatched owners trigger a pre-migration flag so your admin can either invite the user to Odoo or reassign records to a designated fallback owner before the run. This prevents null user_id values on migrated leads, which would break Odoo's assignment rules and reporting.

Scheduling dispatch rules, auto-assignment workflows, and notification triggers in field service software have no Odoo CRM equivalent that can be migrated directly. These must be rebuilt using Odoo Studio automations, server actions, or base automation rules post-migration. We export workflow definitions as a JSON reference document to support the Odoo-side rebuild effort.