Migrate from Kinabase to Mailchimp

The primary subscriber-facing Collection in Kinabase maps to a Mailchimp Audience. Each Record becomes a Member with email address as the dedupe key. We map standard fields (First Name, Last Name, Email) to Mailchimp's FNAME, LNAME, EMAIL merge fields, and custom fields to remaining merge field slots. If the Collection is the only subscriber source, it becomes a single Audience; if multiple Collections represent distinct segments, each becomes a separate Audience.

Kinabase Fields of type text, number, date, and dropdown map to Mailchimp Merge Fields with equivalent types. Mailchimp enforces a hard ceiling of 40 merge fields per Audience; Collections exceeding this require field prioritisation during scoping. Multi-select dropdowns map to Mailchimp multi-select merge fields or tag-based taxonomy. We flag any Fields exceeding the merge field limit in the pre-migration audit.

A Kinabase linked Collection field (e.g., a 'Segment' or 'Region' field pointing to a related Collection) creates a cross-collection reference with no direct Mailchimp equivalent. We resolve linked references by querying the target Collection and creating Mailchimp Tags on the Member record — one tag per linked Collection value. For example, a Contact record linked to a 'Segment' Collection record with value 'Enterprise' produces a tag 'Segment:Enterprise' on the Mailchimp Member.

Kinabase computed Fields evaluate a formula at display time and store the result rather than the formula itself. We evaluate each computed Field at migration time and write the resulting value as a static string or number into a Mailchimp Merge Field. The formula does not transfer because Mailchimp has no computed field support. We document all evaluated computed Fields in the pre-migration audit so the customer understands which values were migrated as static data.

If Kinabase has a separate Companies Collection linked to Contacts via a linked Collection field, we have two options depending on Mailchimp plan tier. On Mailchimp Standard and above, we map the company name to the native Company field on the Member record. On Free and Essentials tiers without native company support, we create a custom merge field (COMPANY) and populate it during the contact load. The linked Collection reference is resolved at migration time via the Kinabase linked record export.

Kinabase engagement records (calls, emails, meetings, tasks) have no direct Mailchimp equivalent because Mailchimp Member records do not store a structured activity history. We handle this by writing the most recent engagement timestamp and type to a custom Merge Field (LAST_ACTIVITY) and by creating a tag for the engagement category (e.g., 'engagement_type:email' or 'engagement_type:call'). The full activity timeline is documented in the Migration Data Package as a CSV export for the customer to reference or import into a separate CRM if needed.

Kinabase Tasks are standalone work items associated with records and have no Mailchimp equivalent. Mailchimp Members do not support task or to-do records. Tasks are exported as a separate CSV as part of the Migration Data Package. If task tracking is required in the new stack, the customer should evaluate integrating Mailchimp with a task management tool or adopting a CRM alongside Mailchimp post-migration.

Kinabase custom objects, Deals, Projects, Tickets, Workflows, and stage definitions have no Mailchimp equivalent. Mailchimp is an email marketing platform and does not support custom objects, deal pipelines, project tracking, or workflow automation of the kind Kinabase provides. These objects are exported as structured CSV files in the Migration Data Package. The customer's admin uses the CSV to manually re-enter data or to plan integrations with a complementary CRM platform that works alongside Mailchimp.