Migrate from Odoo Field Service to HubSpot

Odoo's single-partner model splits into HubSpot Contact + Company, requiring a pre-migration entity classification step

Odoo res.partner is a unified model where a single record can represent an individual, an organization, or a field-service site location. HubSpot requires splitting these into Contact (individuals) and Company (organizations) objects before any record can be created. We run a pre-migration entity classification pass that inspects each Odoo partner record — checking partner_type, whether it has child contacts, whether it has location_ids — to determine whether it should land as a HubSpot Company or a HubSpot Contact with an associated Company. This step is non-trivial for Odoo databases where users have blurred the contact/company distinction using categories and custom fields. We surface every ambiguous record before migration so your team can decide the correct split.

HubSpot Tickets lack field-service scheduling — task timelines and Gantt dependencies do not translate

Odoo Field Service task records store scheduled_date_start, scheduled_date_end, complete_duration, and Gantt dependency links (parent_id, dependency_field). HubSpot Tickets have a createdate, a modifieddate, and a closedate, but no native scheduling timeline or Gantt view. There is no HubSpot-native way to represent a field technician's route plan, a task's dependency on another task completing first, or the drag-drop rescheduling that Odoo's Gantt view provides. We preserve the Odoo scheduling dates as custom Ticket properties (odoo_scheduled_start, odoo_scheduled_end) and note that the scheduling workflow itself must be rebuilt using HubSpot's Workflows or a third-party scheduling integration.

field.service.task state values require explicit value-mapping to HubSpot Ticket pipeline stages

Odoo field.service.task stages are user-defined in Odoo Studio and stored as stage_id records with arbitrary names across Odoo databases. HubSpot Ticket pipeline stages are also user-defined but have a fixed set of stage names per pipeline. There is no automatic one-to-one mapping between 'New / In Progress / Pending / Done / Cancelled' in Odoo and any particular HubSpot Ticket stage set. We extract the actual Odoo stage names from the source database via the field.service.task.stage model, enumerate your HubSpot pipeline stages, and produce a value-mapping table that maps each Odoo stage to a specific HubSpot Ticket stage. You approve the mapping before the migration writes a single record.

Odoo timesheet entries link to field.service.task via project_id, not a direct foreign key on the task itself

In Odoo's timesheet model (account.analytic.line), field-service timesheets are identified by linking to the Odoo project record that represents the Field Service project (project_id on the timesheet row). Odoo does not store a direct link from account.analytic.line to field.service.task — the relationship is inferred through the project. This means a naive migration that maps timesheets by looking for a task_id field will find no matches and drop all timesheet data. We query the field-service project ID first, then pull all account.analytic.line rows linked to that project, extract the employee_id and unit_amount, and create HubSpot Tasks linked to the corresponding migrated Tickets.

Odoo worksheets and signature images are binary ir.attachment records with no structured content to index in HubSpot

Odoo field.service.task worksheets are PDF or image files stored as ir.attachment records with res_model = 'field.service.task' and res_id = the task ID. The file itself downloads from Odoo's binary field (datas) and must be re-uploaded to HubSpot. HubSpot's Files API accepts binary uploads and associates files with CRM records, but there is no mechanism to extract structured content (form fields, checklist results) from the worksheet PDF into HubSpot's native properties. We re-upload the raw file attachment and link it to the migrated Ticket. The structured worksheet data, if it must be visible in HubSpot, requires a separate extraction step using the Odoo worksheet module's model data.