Migrate from Acumen to Mailchimp

Mailchimp merge field type restrictions cause silent truncation or import failure

Mailchimp enforces strict type rules per merge field — text fields cap at 255 characters, number fields reject non-numeric strings, and date fields must use ISO 8601 (YYYY-MM-DD) format. Acumen custom properties may use long-text fields, mixed-format date values, or string-encoded numbers. FlitStack validates field types before import and flags every value that violates Mailchimp's type constraints. Values that exceed the 255-character limit on text fields are truncated and marked in the diff report so your team can decide whether to split them into multiple fields or accept the truncation. This is a common cause of partial migration failures that only surface at import time without pre-flight validation.

Mailchimp counts all contacts — including suppressed ones — toward your plan pricing

Mailchimp's pricing tier is based on total audience size, not just active subscribers. Acumen contacts marked as unsubscribed, bounced, or cleaned are migrated as suppressed members, but they remain in your Mailchimp audience count. If your Acumen instance has a high ratio of inactive contacts (common in CRM databases that accumulate over years), migrating them all to Mailchimp will inflate your plan tier. FlitStack surfaces the contact status distribution before migration so you can decide whether to suppress-only the opted-out records or exclude them entirely and import only subscribed contacts. This decision has a direct billing impact that must be made before the migration runs.

Acumen contact segments require manual recreation in Mailchimp's segment builder

Acumen segments defined by dynamic filter rules (e.g., 'contacts in region North America with deal stage Proposal Sent') have no Mailchimp equivalent. Mailchimp segments are constructed from merge field values and tag memberships after import using Mailchimp's segment builder interface — not a transferable definition. FlitStack exports each Acumen segment as a tag prefix on its members (e.g., 'Segment: North America Proposal Sent') so you can recreate the equivalent Mailchimp segment by filtering on that tag. However, dynamic segments that update automatically as Acumen data changes cannot be replicated — Mailchimp's segment membership must be refreshed manually or via API after the migration.

Multi-select Acumen custom fields explode into N tags — tag namespace collision risk

When Acumen multi-select custom fields (e.g., product_interests with values ['Email', 'SMS', 'Direct Mail']) are migrated as Mailchimp tags, each selected value becomes a separate tag on the member. If multiple Acumen custom fields share overlapping values (e.g., 'Email' appears in both product_interests and communication_preference), Mailchimp will treat these as identical tags across both contexts, causing ambiguity. FlitStack prefixes tags with the field name (e.g., 'product_interests: Email') to avoid collision, but this changes the tag vocabulary from what you may have used in Acumen. Tag renaming after migration requires a separate tag-refactoring pass using Mailchimp's API.

Mailchimp has no native equivalent to Acumen's owner or territory assignment

Acumen tracks an owner_id on every contact record for accountability and territory reporting. Mailchimp has no native owner concept — contacts are not assigned to Mailchimp users, and there is no built-in mechanism to route campaign assignments or manage accountability based on owner. FlitStack preserves owner email and name as read-only custom merge fields (ACUMEN_OWNER_EMAIL, ACUMEN_OWNER_NAME) so the data is available for reference or external attribution tooling. However, no functional Mailchimp feature will use this data automatically. If owner-based routing or campaign accountability is critical to your workflow, you will need to build an external attribution layer or accept that Mailchimp does not support this pattern natively.