Migrate from Hellotracks to Zoho CRM

Hellotracks job status flags have no native Zoho CRM equivalent and require value mapping per status combination

Hellotracks uses two independent boolean flags — progressActive and progressSuccess — to represent job lifecycle. progressActive=1 means the job is currently being worked. progressSuccess=1 means the job was completed successfully. A job can have both flags set (completed mid-shift), neither (pending), or progressSuccess=0 with an issue flag indicating a problem. Zoho CRM Deals use a single pick-list Stage field. We translate every Hellotracks flag combination into a Zoho Deal Stage value by document with the customer before migration. If your team uses custom Hellotracks flag combinations for internal routing, those rules need to be documented as a value-mapping table before migration runs. A mapping error here causes completed jobs to appear as open deals.

Hellotracks custom job fields (extra_number_$, extra_text_$) require Zoho CRM custom field creation before migration

Hellotracks Jobs support up to 10 numbered extra_number fields and 20 extra_text fields, plus a JSON customFields array with arbitrary key:value pairs. These are configured via Hellotracks inputFormConfig and can vary per workflow. Zoho CRM requires custom fields to be created before data is inserted — the Zoho CRM /settings/fields API endpoint (POST) is called first to create each unique custom field discovered in the Hellotracks export, with data_type inferred from the value content (numeric values create number fields; string values create text fields). If a Hellotracks job has customFields with 30 unique keys across 500 jobs, that means 30 Zoho custom fields are created before the migration batch runs — this step adds planning time and must be approved before execution.

Trip and waypoint GPS data has no standard Zoho CRM home — summarized fields preserve the value but lose granularity

Hellotracks Trip records contain structured arrays of GPS waypoints (each with timestamp, latitude, longitude, and speed), plus trip quality assessments and stops-at-place. Zoho CRM has no GPS field type and no standard object for route history. We create a Field_History__c custom module and store summarized trip data (distance, duration, waypoint count, peak speed) as number fields. The raw waypoint array is preserved as a Base64-encoded JSON attachment on the record. This means Zoho reports can reference trip summaries, but the granular GPS trace is not queryable via Zoho standard reporting — only viewable by opening the attachment. If your team relies on GPS trace inspection for compliance or billing, factor this into your acceptance criteria.

Hellotracks dispatch workflows and alert rules do not migrate and have no Zoho CRM equivalent to export to

Hellotracks dispatch rules (auto-assign jobs to workers based on location, team, or zone) and alert thresholds (speed alerts, geofence breach alerts, inactivity alerts) are operational automations that live in Hellotracks configuration with no documented export endpoint. Zoho CRM does not have a native equivalent to Hellotracks GPS-based auto-dispatch — Zoho's assignment rules cover record ownership, not field-worker location routing. Alert rules would need to be rebuilt as Zoho CRM Workflows or Blueprint processes, but Hellotracks does not provide a machine-readable export of the rule logic. We provide a structured audit workbook for documenting each Hellotracks automation so your Zoho admin can rebuild them from the specification.

Hellotracks API polling constraints require migration in batched waves, extending timeline for large datasets

Hellotracks API documentation explicitly warns: 'Don't poll aggressively. Use Webhooks for real-time updates instead.' Unlike Zoho CRM (which publishes rate-limit credits per tier), Hellotracks publishes no explicit per-minute request ceiling — only the advisory to avoid aggressive polling. For migrations with 50,000+ jobs and 200,000+ trips, we pace API requests at conservative intervals and switch to Hellotracks' CSV export endpoints where available (Timesheet Report, Mileage Report, Form Submissions). This batch-and-pace approach typically adds 1–3 days to the migration timeline for large datasets compared to a fully unthrottled pull. We flag this in the scoping phase and adjust timeline estimates accordingly.