Migrate from Hellotracks to Mailchimp

Hellotracks member records map directly to Mailchimp contacts. The email address acts as the primary key, ensuring de-duplication and reliable contact matching during the import. Members that lack an email address are flagged in the audit report, queued for manual enrichment, or omitted from the Mailchimp audience to maintain data integrity.

Standard name fields migrate directly from Hellotracks to Mailchimp. Hellotracks records firstname and lastname as distinct properties, while Mailchimp expects FNAME and LNAME merge fields for each contact. When a name is missing or null, the corresponding merge field receives a blank value, preserving the schema alignment without altering contact eligibility.

Email serves as the primary identifier and contact key throughout the migration. Mailchimp mandates a valid email format for inclusion in an audience, rejecting any record that does not meet the standard. Hellotracks members lacking an email are flagged for review, while contacts with malformed addresses are excluded and recorded in the migration audit log for corrective action.

Phone numbers are transferred into the PHONE merge field of each Mailchimp contact. The original international formatting is retained without conversion to E.164, ensuring that local display remains consistent. If the SMS add-on is active on the Mailchimp account, the stored phone value can be used for SMS marketing campaigns.

Hellotracks records the jobtitle attribute for each member, such as 'Field Technician' or 'Dispatcher'. Since Mailchimp does not provide a native jobtitle property, the value is stored in a custom TEXT merge field named JOBTITLE on the contact record. This custom field enables segmentation based on role and supports personalized email content using the stored title.

Hellotracks API exposes up to 20 extra_text fields per member (extra_text_1_key through extra_text_20_key as labels, extra_text_1_val through extra_text_20_val as values). Each non-empty field is created as a Mailchimp merge field. The 30-field standard plan limit may require prioritization; Premium supports 80.

Hellotracks extra_number fields (extra_number_1 through extra_number_10) are mapped to Mailchimp merge fields defined as Number type. The original type metadata (bool, decimal, number) is consulted to apply the appropriate formatting in Mailchimp, ensuring numeric precision and display consistency. Because Mailchimp requires merge fields to exist prior to import, each numbered field is pre-created in the Mailchimp audience before the migration run begins.

Hellotracks customFields is a key-value array (e.g., {key: 'Department', val: 'Repair'}). Each unique key is created as a Mailchimp merge field. Field type defaults to TEXT unless type metadata indicates otherwise. Duplicate key names across records are consolidated into a single merge field definition.

Hellotracks Places are geofenced locations (client sites, warehouses, offices) with names, addresses, and custom fields. Mailchimp has no location object — place names and addresses are added as merge fields, and place membership is expressed as Mailchimp tags (e.g., TAG: ClientSite-A, TAG: Warehouse-North).

Place address components—street, city, state, postal code, and country—are parsed and loaded into Mailchimp's standard address merge fields (ADDR, CITY, STATE, ZIP, COUNTRY). The associated geofence radius measured in meters is preserved as a custom merge field named PLACE_RADIUS_M, providing a reference point for any location‑related analysis, despite Mailchimp lacking native geofencing functionality.

Hellotracks Jobs, representing service tasks, lack a direct counterpart in Mailchimp's data model. To retain service history, the latest job status, the linked worker reference, and the job completion timestamp are extracted and written as custom merge fields on each related Contact record. These fields supply context for audience segmentation and targeted campaigns without replicating the full job hierarchy.

Hellotracks job status values are translated into both a custom merge field named JOB_STATUS and a set of Mailchimp tags that reflect the current state. The mapping assigns TAG: Job-Complete for 'success', TAG: Job-NeedsFollowUp for 'issue', and TAG: Job-InProgress for 'active' status. Because Mailchimp contacts represent a flat model, the chronological sequence of status changes is not retained; only the latest state appears in the contact record.

Check‑in and check‑out timestamps from completed Hellotracks jobs are imported as custom datetime merge fields, CHECKIN_DT and CHECKOUT_DT, attached to the relevant Contact record. These fields document the precise moments a worker arrived at and left a job site, providing useful timing context for segmentation and reporting. However, they do not serve as triggers within Mailchimp automation workflows, as Mailchimp lacks event‑driven job‑site notifications.

Job-specific extra fields (up to 20 text and 10 number per Hellotracks Job API object) migrate as merge fields on the linked Contact record. The Hellotracks Job API object also exposes inputFormConfig-defined fields — these are preserved with their labels as merge field names, truncated to Mailchimp's 30-character limit.

Hellotracks Trip records include waypoints, route distance, speed, duration, and stop events. Mailchimp has no geospatial, routing, or trip-logging capability. Trip summaries (total distance, total active time) for the most recent completed trip are added as merge fields; full route history is not transferable.

Hellotracks Alert records capture geofence violations, speed breaches, idling, and other triggered events. Mailchimp contacts have no alert or notification log. Alert records are exported as a separate CSV for reference; they do not become contact records or activity history in Mailchimp.

The internal member identifier from Hellotracks is saved as a custom TEXT merge field called SOURCE_HT_ID on each Mailchimp contact. This field supports delta‑run de‑duplication by matching new imports against existing contacts, provides full traceability to the original Hellotracks record, and allows reconciliation with Hellotracks reports to verify data completeness after migration.

Hellotracks does not provide a native first‑registered timestamp through its standard member API. However, the creation timestamps of jobs and trips linked to each member are accessible. FlitStack AI extracts the earliest of these timestamps—typically the date of the first job assignment or the first recorded trip—and stores it as a custom datetime merge field named HT_CREATED_DT on the Mailchimp contact, ensuring continuity for historical reporting.