Migrate from ForceManager CRM to Mailchimp

ForceManager Contact records map to Mailchimp Members inside a target Audience. We map first name to FNAME, last name to LNAME, email address as the primary Member identifier, phone to PHONE, and address fields to their corresponding merge fields (CITY, STATE, COUNTRY, ADDRESS1, ADDRESS2, ZIP). Owner assignments from ForceManager map to a custom merge field z_owner_name for reference but do not create Mailchimp User records since Mailchimp does not have a per-user access model. We resolve unsubscribed contacts against Mailchimp's suppression list before import to avoid re-engaging opted-out addresses.

ForceManager Company records are not first-class objects in Mailchimp. We extract company name, industry, website, and billing address and map them to a combination of Mailchimp tags (applied to each Member) and merge fields (COMPANY, INDUSTRY, WEBSITE added as custom merge fields to the target Audience). We tag each Member with the source Company name for segmentation by account in Mailchimp. Multiple Contacts from the same Company receive the same Company-level tag during import.

All ForceManager custom fields carry a z_ prefix in the API payload. During extraction we query the Fields endpoint to retrieve human-readable labels (the prefix and type are not embedded in the data payload). We create matching merge fields in the Mailchimp Audience with appropriate types: text fields become TEXT merge tags, date fields become DATE merge tags, numeric fields become NUMBER merge tags, and dropdown fields become either RADIO or dropdown merge tags. The z_ prefix is stripped and replaced with a human-readable label. Custom fields that contain multi-value data (such as multiple selections) are mapped to Mailchimp tags.

ForceManager Activities (calls, meetings, visits, field interactions with GPS timestamps) have no native Mailchimp equivalent. We do not import Activities as Members because Mailchimp's contact model tracks email engagement, not field sales activity. We document the count and type of activities per Contact in a scoping report and flag that the customer should use Mailchimp's Tags to record a manual activity flag if needed. Activity history is preserved in the ForceManager export archive for audit purposes.

ForceManager Opportunities with stage, value, and close date have no Mailchimp equivalent. Mailchimp does not track deal pipelines or sales stages. We export the full Opportunity dataset to a CSV file during migration scoping and deliver it as a reference document so the customer's admin can track deal status in a separate system or spreadsheet post-migration. The Opportunity export includes opportunity name, stage, value, responsible user, and close date.

ForceManager Tasks (with status, due date, and assignee) do not map to Mailchimp. We export task data as a structured CSV and deliver it alongside the migration report. Open tasks are flagged as requiring reassignment to a task management tool outside Mailchimp. Completed tasks are preserved in the ForceManager export archive.

ForceManager User records with team assignments and territory data do not map to Mailchimp's contact model. We export the User roster as a CSV during scoping. Owner assignments on Contacts are mapped to a custom merge field z_rep_owner for reference in Mailchimp. The customer manages team access and permissions directly in Mailchimp's account settings.

ForceManager Sales Order and Sales Order Line entities exist in the API but represent a transactional layer with no Mailchimp equivalent. We export Sales Order data (order ID, line items, quantities, amounts) as a CSV and apply order-related tags to Members where the order is tied to a Contact (for example, tag with order recency or product category). The transactional detail lives in the export document, not in Mailchimp itself.