Migrate from Forms On Fire to Mailchimp

Forms On Fire form definitions, workflow routing, and conditional logic have no Mailchimp equivalent

Forms On Fire stores each form's field schema, conditional show/hide rules, workflow routing assignments, and automated alert chains inside its own platform database. Mailchimp has no form-definition store — signup forms are created independently using Mailchimp's form builder, and automation triggers are defined in Mailchimp's Customer Journeys or Classic Automations. FlitStack migrates submission data and custom field schemas, but every Forms On Fire form must be manually recreated as a Mailchimp signup form, and every workflow route must be rebuilt as a Mailchimp automation. This is not a gap in FlitStack's capability — it is a genuine platform architectural difference. Budget time and a Forms On Fire workflow export (which FlitStack can provide as a rebuild reference document) for this manual reconstruction phase.

Entries without an email address cannot be imported into Mailchimp

Mailchimp contacts are keyed by email address — every contact record requires a valid, unique email. Forms On Fire form submissions frequently capture field data from respondents who did not provide an email (e.g., customer intake forms, safety inspection logs, or field checklists where the respondent is a technician rather than a customer). These entries appear in the Forms On Fire export but cannot create Mailchimp contacts without an email. FlitStack surfaces these records in the pre-migration audit as 'non-importable contacts.' Your team must decide whether to exclude them entirely, capture emails through a separate outreach step, or maintain them in an alternative system. Entries without emails are not silently dropped — they are flagged and reported.

GPS coordinates, photos, and signatures require transformation and re-upload — original files do not migrate inline

Forms On Fire's location fields capture structured GPS objects (latitude, longitude, accuracy, timestamp, and optionally an address string). Photo, signature, and file upload fields store binary blobs in Forms On Fire's document management layer. Mailchimp contacts store only flat field values — there is no binary attachment model. FlitStack parses GPS objects into address or text fields, downloads and re-uploads photos and signatures to Mailchimp's file manager, and stores the resulting URLs in text merge fields on the contact record. The original Forms On Fire file link is broken; the file now lives in Mailchimp's file manager. If strict chain-of-custody or document-retention requirements apply to these files, consult FlitStack support before migration to discuss document-archiving alternatives.

Multiple Forms On Fire forms with overlapping contacts collapse into one Mailchimp contact per email address

Mailchimp enforces one contact record per email address within a single audience. If the same email address appears in submissions across multiple Forms On Fire forms (e.g., a customer fills out both an intake form and a follow-up inspection form), FlitStack merges those into a single Mailchimp contact. Merge fields from the most recently submitted entry overwrite prior values by default unless you specify a 'preserve earliest' or 'concatenate all values' strategy. Form-of-origin is preserved as a tag and merge field, so you can segment by which form each submission came from. This is by design in Mailchimp's data model — it is not a FlitStack limitation — but it changes how multi-form submission history is represented compared to Forms On Fire's per-entry model.

Mailchimp merge field type constraints limit how some Forms On Fire field types map

Mailchimp supports a fixed set of merge field types: text, number, date, phone, address, website, image, and Birthday. Forms On Fire field types like calculation results, barcode scan values, and boolean flags do not have native Mailchimp equivalents and must map as text. Location fields with raw GPS coordinates (no address string) cannot populate Mailchimp's structured address field and instead become text. If your Forms On Fire forms use advanced field types extensively, the migration plan will include a schema-design step where FlitStack's team confirms which merge field type best represents each source field — this is a manual design decision, not an automatic one.