Migrate from Bella FSM to Mailchimp

Bella FSM customer records map directly to Mailchimp audience members via email as the unique identifier. Multiple Bella FSM customers sharing the same email address are de-duplicated during migration — the first record wins, subsequent records are merged by email with custom field values concatenated into a note field.

Bella FSM text-type custom fields on the customer page map to Mailchimp merge fields (type: text). Mailchimp allows up to 40 merge fields total; if the source has more than 40 custom fields, the remainder are stored as a single concatenated note on the contact record.

Bella FSM checkbox fields (boolean) are migrated as text merge fields ('Yes'/'No') or as Mailchimp tags (e.g., tag 'Has_Service_Contract' applied when the checkbox was true). Tag-based mapping is preferred for segmentation clarity. If tags are chosen, each true checkbox generates a tag with a descriptive name; false checkboxes are ignored. Tags are applied during the bulk import phase and can be used to build dynamic segments in Mailchimp.

Bella FSM dropdown fields with custom option lists require explicit value mapping to Mailchimp merge field dropdown options. Options are created in Mailchimp first, then mapped 1:1 by label. If a Mailchimp merge field is text-type, values are migrated as text strings.

Bella FSM address fields (street, city, state, zip, country) map to Mailchimp's structured ADDRESS merge field. Mailchimp's address field consolidates all address components into one field — we split Bella FSM address parts into the correct sub-fields (addr1, city, state, zip, country).

Bella FSM job and work order records have no Mailchimp equivalent. These records do not migrate. Service history may be referenced by tagging the associated contact with job-related labels (e.g., 'Job_Completed_2024') for segmentation purposes. You may create custom tags reflecting the latest job state for each contact, but detailed job records stay in Bella FSM and cannot be stored in Mailchimp.

Bella FSM invoice and payment records are operational billing data with no Mailchimp equivalent. Invoice totals, payment status, and balance due cannot be stored in Mailchimp contacts. If customer financial history is needed in Mailchimp, it must be stored as a custom merge field (text) at migration time.

Bella FSM equipment tracking records (serial numbers, make/model, service history) have no Mailchimp equivalent. Equipment data may be stored as text merge fields on the contact record if limited in scope, but the full equipment object does not migrate. If you wish to keep a reference to the primary equipment, you can map the most recent equipment description to a merge field, but historical service logs remain outside Mailchimp.

Bella FSM employee records (staff names, roles, hourly rates) are internal operational data with no Mailchimp equivalent. These records do not migrate. If you need to associate a primary technician with a customer, you can store the technician name as a text merge field on the contact record, but employee schedules and rates remain in Bella FSM.

If Bella FSM stores multiple service locations per customer as separate location records, these can be migrated as Mailchimp contact tags (one tag per location) or as a text merge field listing the locations. Location-based segmentation in Mailchimp is then built using tag-based or field-based segments.

Bella FSM customer notes map to Mailchimp contact notes. Each note in Bella FSM becomes a separate note entry in Mailchimp with the original timestamp if available. Long notes are truncated at Mailchimp's 1,000-character note limit. If a note exceeds the character limit, FlitStack AI splits it into multiple entries, preserving as much content as possible. All note metadata, including creation date, is retained for audit purposes.

Bella FSM's customer record create date does not map to a native Mailchimp field. Mailchimp's built-in 'OPTIN_TIME' reflects when the contact was added to Mailchimp, not when they became a Bella FSM customer. Original create date is stored as a custom date merge field (Original_Customer_Date__c naming convention) for reporting continuity.