Migrate from Field Force Tracker to Odoo CRM

Odoo lead-to-opportunity conversion drops custom fields unless patched

Odoo's built-in Convert to Opportunity action on a crm.lead does not automatically carry custom fields from the lead to the resulting opportunity record. Fields like x_fft_job_type and x_fft_dispatch_notes that you create on crm.lead stay on the lead when it converts — the new opportunity record will be blank in those fields unless you either install the Odoo Community Association's custom-field-mapping module (cytechmobile/odoo-custom-field-mapping-free) or rebuild the conversion via a server action that explicitly copies field values. We surface this as a pre-migration checklist item so your Odoo admin can decide on the approach before go-live.

Odoo external API rate limits throttle bulk imports

Odoo's XML-RPC external API is free on all plans but enforces request concurrency and per-hour throughput limits that vary by Odoo hosting method (Odoo.sh vs. self-hosted Community). Bulk imports that exceed those limits receive 403 or 504 responses mid-load, potentially leaving the database in a partially migrated state. We batch FFT API reads and Odoo API writes into chunks of 200–500 records with exponential back-off on rate-limit responses, and we re-verify record counts after each batch. If your Odoo instance is self-hosted Community, the API limit is typically governed by your own server's worker configuration.

FFT work-order statuses require per-pipeline value mapping

Field Force Tracker uses a single work-order status pick-list across the entire account. Odoo CRM's stage_id field is scoped per pipeline and per crm.team, meaning each Odoo pipeline has its own independent set of stage values stored as crm.stage records in the database. If your FFT account has multiple service teams with different status naming conventions, you need to decide whether to collapse those into one Odoo pipeline with a unified stage set or create separate Odoo pipelines (and thus separate CRM teams) to preserve the distinction. We deliver a stage-mapping plan before the migration runs so this decision is made before data lands.

GPS coordinates, dispatch data, and route-planning info have no Odoo CRM equivalent

Field Force Tracker captures technician GPS coordinates at dispatch and job completion, route-planning data, and real-time mobile status updates that form the backbone of field-service operations. Odoo CRM's data model has no native fields for geo-coordinates, route segments, or real-time mobile status. We preserve this data as custom Latitude__c, Longitude__c, and Last_Known_Location__c text fields on res.partner, but these fields are static references — they do not drive Odoo's Kanban views, reporting, or any native functionality. If you need field-service scheduling and dispatch in Odoo, that requires the separate Odoo Field Service module, which is a distinct installation and configuration project beyond CRM migration scope.

Foreign-key sequencing: leads must exist before opportunities load

Odoo enforces referential integrity at the ORM level. crm.lead records require a valid partner_id (res.partner) before they can be created. If you batch-load leads and partners simultaneously, leads referencing partner IDs that have not yet been committed will fail with a foreign-key violation error. We sequence the migration in three passes: first partners (customers and employees), then leads with the partner_id lookup resolved, then sale.orders referencing those leads. We flag any FFT work orders whose linked customer has no email match in FFT's customer table before migration starts, so orphan records are handled explicitly rather than failing silently.