Migrate from Hellotracks to Odoo CRM

Hellotracks extra_number and extra_text field naming requires pre-creation of Odoo custom fields

Hellotracks Jobs use a numbered suffix convention for custom fields — extra_number_1 through extra_number_10 and extra_text_1 through extra_text_20 — with labels stored in separate fields. This is not a standard key-value model; the numbered index is the stable identifier and the label is metadata. When migrating to Odoo CRM, these become static custom fields on crm.lead, not dynamic. We create a mapping table from each numbered suffix to an Odoo field name (x_extra_number_1, x_extra_text_1, etc.), using the Hellotracks label as the field description. All destination fields must be created in Odoo before migration data is loaded — we deliver the exact field definition (name, type, label, help text) in the pre-migration schema plan so your Odoo admin can create them before the migration run.

GPS waypoints and trip history have no native Odoo CRM equivalent — we preserve as JSON custom fields

Hellotracks records GPS waypoints as an array of objects containing latitude, longitude, speed, and timestamp per point. Trip summaries store origin, destination, total distance, and duration. Stop records capture arrival/departure times at places or jobs. Odoo CRM's crm.lead model has no field type for GPS coordinates or route data. We store waypoints, trip summaries, and stops as custom text fields on crm.lead, serialized as JSON so the raw data is preserved and queryable. This is the correct approach — it keeps the data linked to the opportunity record — but it requires post-migration reporting to be built as Odoo custom reports rather than native views. We include a sample Odoo QWeb report template for GPS data review as part of the migration deliverables.

Hellotracks places support multiple geofence radii per location — Odoo has no geofence concept

Hellotracks Places store a geofence as a named location with a radius. A single Place record can have one active radius at a time, but Hellotracks allows multiple places to be associated with a single address. Odoo res.partner addresses are single-value: one street, city, zip per address record. We map each Hellotracks Place to a separate res.partner record with the geofence radius stored as a custom float field (x_geofence_radius). If you rely on Hellotracks' multi-radius geofence behavior — where one physical address triggers alerts at different radii — you will need to reconfigure geofence logic in Odoo using a third-party geofencing app from the Odoo Apps Store or a custom module. We flag this in the pre-migration review and recommend specific Odoo Apps Store geofencing modules if applicable.

Job-to-opportunity foreign key sequencing requires Workers to migrate before Jobs

Hellotracks Jobs reference a worker_id, and Odoo crm.lead records reference partner_id. If we attempt to load Jobs before Workers resolve to res.partner records, the partner_id foreign key fails — Odoo requires a valid partner_id on crm.lead. We sequence the migration as: (1) Workers → res.partner, (2) Places → res.partner address records, (3) Jobs → crm.lead with partner_id resolved by email match. Alerts and Form submissions reference Jobs and are loaded last. This sequencing is handled automatically by FlitStack, but it means the migration plan must include a review of worker email completeness — records with no email cannot be auto-matched and require a fallback resolution strategy (assign to a default partner or create a placeholder contact) agreed upon before migration runs.

Hellotracks progressSuccess boolean requires post-state stage override logic

Hellotracks Job records have both a state field (pending, accepted, in_progress, completed, cancelled) and a separate progressSuccess boolean. A job with state=in_progress but progressSuccess=1 indicates a completed job whose state was not updated. Odoo CRM stage_id is a single field — there is no separate completion flag. We apply a two-pass mapping: first, state maps to stage_id via the value mapping table; second, if progressSuccess=1 is found on any record, we override the stage to the terminal Won stage regardless of the state value. This logic must be validated in the sample migration run. We document the override rule in the migration plan and include it in the field-level diff report so you can confirm it before the full migration commits.