Migrate from Fortifi to Mailchimp

Fortifi Customer records map to Mailchimp Audience members. The primary key mapping uses email address as the dedupe identifier. Standard fields (first name, last name, email, phone, company) map directly to Mailchimp merge fields (FNAME, LNAME, EMAIL, PHONE, COMPANY). Any Fortifi custom properties on Customers migrate as Mailchimp merge tags or custom fields. We resolve the audience ID in Mailchimp before import and use the Members API with status (subscribed, unsubscribed, cleaned) set from the source opt-in state.

Fortifi Subscription records define recurring billing models and plan assignments. These do not map to a standard Mailchimp object but map to a segmentation strategy. We map each Fortifi subscription plan to a Mailchimp Group or Tag so that customers in plan A land in group/tag PlanA, customers in plan B in group/tag PlanB. The customer selects the grouping strategy (Groups for mutually exclusive plans, Tags for additive classifications) during scoping. Subscription status (active, canceled, past_due) migrates as a separate Tag value.

Fortifi Email records (sent, delivered, opened, bounced states) migrate to Mailchimp member activity history where the Mailchimp API supports activity retrieval. Open and click data migrates as engagement flags on the Member record. Bounced email addresses are extracted and imported as a Mailchimp suppression list so that no campaigns attempt to resend to invalid addresses. Historical campaign attribution (which campaign sent to which contact) maps to Mailchimp tags with campaign naming conventions.

Fortifi custom field schemas discovered during scoping map to Mailchimp merge tags. We use the Mailchimp Marketing API to pre-create merge tags matching the Fortifi field names and data types (text, number, date, dropdown). Boolean fields become yes/no text or checkbox merge tags. Date fields preserve ISO format. Multi-select or tag-based Fortifi fields may map to Mailchimp tags if the values exceed what a single merge tag can store.

Fortifi Actions track behavioral events against customers (purchases, logins, feature usage). Mailchimp does not have a native behavioral event object outside of automation triggers, but we map significant Fortifi Action types to Mailchimp Tags so that marketing automation triggers can reference them. High-frequency action types (page views, daily logins) are excluded as noise; threshold-based actions (first purchase, plan upgrade) are prioritized for tag migration.

Fortifi Interactions track customer touchpoints across support and engagement channels. We map interaction channel types (support ticket, live chat, phone) to Mailchimp Tags with a prefix (support_, chat_, phone_) so that support history is visible in Mailchimp for segmentation purposes. Interaction timestamps and summaries are not stored as individual Mailchimp records but referenced in tag metadata.

Fortifi User records (name, email, role) map to Mailchimp Account users. We extract user email addresses and role assignments from Fortifi and provide a mapping table to Mailchimp admin account invitations. Actual Mailchimp account provisioning requires the customer to send invitations from the Mailchimp account settings. We do not create Mailchimp accounts programmatically.

Fortifi Invoices carry full financial data including line items, payment status, due dates, and tax codes. Mailchimp does not store invoice or financial records. Invoice data is outside Mailchimp's scope as an email marketing platform. We export Fortifi invoice data as a structured CSV file for the customer's accounting or ERP system to ingest separately.

Fortifi automation rules, dunning sequences, and renewal triggers are configuration-level settings that are not exportable as data records. We document the automation configuration discovered during scoping (trigger conditions, delay rules, action sequences) in a written inventory for the customer's admin to rebuild in Mailchimp's Customer Journeys automation builder. The rebuild is outside standard migration scope.