Migrate from Odoo Field Service to Odoo CRM

Field Service tasks do not auto-link to CRM opportunities without a sale.order bridge

Odoo Field Service tasks and CRM leads occupy the same database but belong to separate model families — fieldservice.task and crm.lead are not the same object and do not share a foreign-key relationship. Tasks created from a sales order in Field Service carry a sale_line_id link back to sale.order, but the task itself has no crm.lead foreign key. FlitStack AI resolves this by tracing the sale.order → sale_order_line → crm.lead link where it exists, then attaching the migrated task as a project.task activity on the found opportunity. Tasks without a sales order bridge become standalone project.task records under a CRM-linked project. This mapping decision must be confirmed during the planning phase because it affects how service history appears in the CRM pipeline view.

Field Service state values require explicit value-by-value mapping to CRM stage names

fieldservice.task uses Odoo workflow states — New, Confirmed, In Progress, Done, Cancelled — which are stored as XML state transitions in the FSM module. Odoo CRM uses crm.stage with pick-list stage names that are completely independent. There is no automatic translation between a field service state and a CRM stage. Teams that have built business logic around field service states (e.g., routing rules, notifications, or SLA timers tied to 'Confirmed') need to have those translated into CRM stage-based automations post-migration. FlitStack AI creates a value-mapping table for each state-to-stage translation and preserves the original state as a custom field on the migrated task so no information is lost during the transition.

Equipment records have no native equivalent in Odoo CRM and must be reclassified as products

fieldservice.equipment is its own model with fields for serial number, brand, model, maintenance contract, child equipment hierarchy, and customer link. Odoo CRM has no equipment object — it uses product.product for anything that can be sold, invoiced, or tracked as inventory. Migrating equipment therefore requires reclassifying each record as a product with variant tracking enabled for serialized items. If the equipment has a bill of materials or sub-components, those need to be converted to a product.bom structure. The reclassification is irreversible in Odoo since the equipment model is not available in CRM-only deployments. FlitStack AI creates the product records first, then updates the task-equipment links to point to the new product IDs before committing the migration.

Time-tracking entries in Field Service require a project.project to exist in CRM before migration

Field Service stores timesheet entries in project.timesheet linked to a fieldservice.task. If the task's project_id is set, the timesheet entries exist in project.timesheet with a task_id link. In Odoo CRM, timesheets live in account.analytic.line (the analytic accounting model). CRM does not create a project.project automatically when an opportunity is created — it must be explicitly enabled via the CRM settings or linked to a project manually. FlitStack AI creates a project.project for each CRM opportunity that received migrated field service tasks before moving timesheet data, so the analytic lines have a valid project_id to link against. Without this step, timesheet migration fails on foreign-key validation.

Mobile app data, map routes, and GPS logs do not migrate — those are runtime state

Odoo Field Service's mobile app stores GPS location pings, route traces, and mobile form submissions that are written to the database as task state updates and message logs. The route geometry (polyline data) and real-time GPS logs are not stored as discrete database records with field-level persistence — they exist as in-memory state on the mobile device and are not fully captured in the PostgreSQL schema. FlitStack AI migrates the task record state and chatter history, but the mobile app's dispatch map view, route replay, and geofence alert data cannot be reconstructed in Odoo CRM because CRM does not have a route geometry storage model. This is disclosed during planning so the team does not expect historical dispatch maps to appear in the CRM.