Migrate from Field Force Tracker to Mailchimp

Field Force Tracker client records map to Mailchimp contacts. The client's primary company name maps to the built‑in COMPANY merge field. Clients missing an email address are flagged before import because Mailchimp requires a valid email for each subscriber; those records are held for manual review and excluded from the initial load.

The client email address maps directly to Mailchimp's EMAIL field, which serves as the unique identifier for each subscriber. Mailchimp treats duplicate email addresses within the same audience according to your audience settings: either merging the records or rejecting the new entry. Prior to migration, email values are normalized (trimmed, lower‑cased) to prevent mismatches caused by extra spaces or capitalization differences.

Field Force Tracker stores the first and last name as separate client properties. Both fields map directly to Mailchimp's built‑in FNAME and LNAME merge fields, present in every Mailchimp audience. If either name component is missing in Field Force Tracker, the corresponding merge field stays blank; a full‑name merge field can be added later for display. The migration preserves original capitalization and handles Unicode characters without transformation.

Client phone numbers map to a PHONE merge field that must be created in Mailchimp before import. Mailchimp stores phone numbers as free‑text merge fields; the migration normalizes values to E.164 format when possible, preserving any non‑numeric characters as entered. If a client record has no phone, the PHONE field stays empty. SMS marketing later requires separate compliance configuration in Mailchimp, including consent collection and list cleaning.

Field Force Tracker client address data — street, city, state, zip, and country — maps to Mailchimp's ADDRESS merge field group. Mailchimp structures address information across six sub‑fields: ADDR1, ADDR2, CITY, STATE, ZIP, and COUNTRY. If a client record lacks certain components, those sub‑fields are left blank while the remaining fields are populated. The migration preserves original formatting and attempts to normalize state abbreviations and country codes to Mailchimp's expected format.

Field Force Tracker records a service type or job category for each client. During migration, each unique service‑category value becomes a Mailchimp tag applied to the contact. This enables segment‑based campaigns (e.g., 'HVAC Service', 'Plumbing', 'Elevator Maintenance') without using merge‑field capacity. If a client has multiple categories, each value creates a separate tag. Tags are normalized to title case to prevent duplicates from capitalization differences.

Field Force Tracker custom client properties (e.g., 'customer_tier', 'contract_status', 'preferred_technician') migrate as Mailchimp merge fields. You must pre-create merge fields in Mailchimp with matching types — text fields for freeform values, dropdowns for pick-list values. We deliver a merge field creation guide as part of the migration plan.

Field Force Tracker work orders and job tickets have no counterpart in Mailchimp because Mailchimp is built around subscriber contacts, not operational job records. These objects cannot be imported directly. However, any service‑type or job‑status information that already exists on the client record can be transferred as Mailchimp tags, providing indirect historical context for the contact. Work order IDs, technician assignments, and job details remain excluded from the migration.

Field Force Tracker can associate each client with a company record. The company name maps to Mailchimp's built‑in COMPANY merge field. If a client lacks a company entry, the merge field stays empty and the record is flagged for review. Multiple clients sharing the same company retain the same COMPANY value, allowing segmentation by organization; the migration does not create separate company objects in Mailchimp.

Field Force Tracker technician and employee records have no Mailchimp counterpart because Mailchimp focuses on subscriber contacts rather than internal staff. Consequently, technician assignments, employee roles, and staff identifiers do not migrate. If you wish to associate a contact with a technician, that relationship can be captured as a custom merge field or tag, but it must be added manually after import, as Mailchimp does not store employee objects.

Service contracts and agreements stored in Field Force Tracker have no Mailchimp counterpart. Contract status may be represented as a tag on the client contact (e.g., 'Contract Active', 'Month-to-Month') if that data exists as a custom field on the client record.

Field Force Tracker GPS check‑in data and location‑tracking records are operational details specific to field‑service activities. Mailchimp’s platform is designed for subscriber contacts and email campaigns, and it does not store geographic or tracking information. Consequently, GPS coordinates, route logs, and check‑in timestamps are excluded from the migration. If location‑based segmentation is required, you would need to derive it from address data already present in Mailchimp’s address merge fields.