Migrate from Salesflare to Mailchimp

Salesflare Contact records map directly to Mailchimp Members within an Audience. We use the contact's email address as the primary key for deduplication. Standard fields mapped include first name, last name, email, phone, and title. Salesflare's enrichment data (company domain, LinkedIn URL) migrates as merge fields if under 255 characters. The Account-Contact relationship does not carry over — all Members exist in a flat audience list in Mailchimp. We preserve the original Salesflare contact ID in a merge field for audit traceability.

Salesflare Accounts do not map to a native Mailchimp object with the same relationship semantics. We handle this as a configuration decision during scoping: either all Contacts merge into a single Mailchimp Audience (most common), or we create separate Audiences per Account and distribute Contacts accordingly. Account metadata (company name, domain, industry, location) migrates as Audience-level merge fields if a single-audience strategy is chosen, or becomes Member-level data in each split audience. Account custom properties migrate under the same 255-character merge field constraint.

Salesflare Tags are flat labels applied to Accounts, Contacts, and Opportunities. Tag names and associations migrate as Mailchimp Tags, which are applied to Members for segmentation purposes. We export the tag-to-contact join table from Salesflare and apply tags to the corresponding Members during import. Mailchimp Tags are not hierarchical and do not carry inheritance logic — each tag assignment is an independent label, matching Salesflare's flat tag model. Tag counts per Member are preserved.

Salesflare custom properties on Contacts migrate to Mailchimp merge fields. We create the corresponding merge field in Mailchimp (TEXT type for short text, NUMBER for numeric properties, DATE for date fields) before import and map property values directly. Merge field names in Mailchimp use uppercase and no spaces, so we transform the Salesflare property API name accordingly. Text properties over 255 characters are flagged for manual review — these cannot map to Mailchimp merge fields and must be truncated, stored externally, or dropped.

Mailchimp merge fields are hard-limited to 255 characters. Any Salesflare custom property with text content exceeding this limit cannot migrate. We identify these fields during scoping, document their current values, and present three options: truncate to 255 characters and accept data loss, export the full values to a CSV stored alongside Mailchimp for admin reference, or exclude the field from migration. The choice is made during scoping and reflected in the migration specification.

Salesflare Opportunities represent deal records with stage, value, expected close date, and pipeline assignment. Mailchimp has no deal, pipeline, or opportunity object. We do not migrate Opportunities as records. We export the opportunity data as a CSV inventory — deal name, stage, value, close date, owner, and related Account — and deliver it to the customer's admin for reference or for import into a separate CRM if they plan to run sales operations alongside Mailchimp. This inventory document is part of the standard migration deliverable.

Salesflare Pipelines define the deal stage names and probabilities available to Opportunities. Mailchimp does not have pipeline or stage management. We export the full pipeline definition (pipeline name, stage labels, stage probabilities, stage order) as a configuration inventory document alongside the opportunity inventory. If the customer plans to use a separate CRM post-migration, these stage definitions serve as input for pipeline setup there.

Salesflare Growth plan limits users to a single email sequence flow. The sequence steps, delay intervals, trigger conditions, and action logic migrate as a written sequence inventory — a documented walkthrough of each step, the delay, the condition branch, and the CRM action (if any). We do not migrate sequence code. Mailchimp Automations are rebuilt by the customer's admin using this inventory as the specification. Growth sequences without conditional branches map most directly to Mailchimp's single-send automation or classic automation patterns.

Salesflare Pro and Enterprise email sequences with multi-step conditional branches migrate as a written workflow inventory. Each branch, condition, delay, and action is documented step-by-step with the original Salesflare step name and logic preserved. Mailchimp's Customer Journey builder handles conditional branching differently — based on tags, segment membership, and activity triggers rather than CRM property changes. We document the functional equivalent in Customer Journey terms so the admin can rebuild the logic. This is a configuration rebuild, not a data migration.

Salesflare Activities (logged calls, emails, meetings, and tasks) are engagement records attached to Contacts. Mailchimp tracks opens, clicks, unsubscribes, and purchases per campaign and per Member but does not store a native activity timeline equivalent. We do not migrate engagement history. We deliver an activity inventory CSV (activity type, date, outcome, linked Contact) for reference. If the customer needs engagement history visible in Mailchimp, the recommended approach is to rebuild open and click tracking through Mailchimp campaigns post-migration.

Salesflare Users represent team members with roles and pipeline assignments. Mailchimp uses subscriber counts and audience tiers rather than per-user CRM licensing. We export the Salesflare user list as a reference document. If Mailchimp roles are needed (for campaign access control), Mailchimp provides user management at the account level with different permission levels. We document which Salesflare users should receive Mailchimp account invites based on their involvement in email operations.

We export Salesflare contacts with bounced or unsubscribed email status and import them into Mailchimp as suppressed members. This is critical for deliverability — sending to suppressed addresses on the first Mailchimp campaign damages sender reputation. We import bounces as bounced status and unsubscribes as unsubscribed status, ensuring these contacts are excluded from future sends. This import runs before the main Members migration to establish the suppression baseline.