Migrate from Moskit to Mailchimp

Moskit Contact records map to Mailchimp Subscribers within a target Audience. We extract name, email, phone, address fields, and all custom property values. The email address is the dedupe key; if a Subscriber already exists in the target Audience, we update rather than duplicate based on email match. Opt-in status is inferred from Moskit's contact creation context; contacts created through Moskit's form or campaign module carry a confirmed opt-in flag, which we set on Mailchimp's SUBSCRIBER_STATUS field.

Moskit Company records do not map to a native Mailchimp object because Mailchimp has no company or account concept. We handle this in one of two ways during scoping: companies become Tags on the linked Subscriber record (e.g., tag every Subscriber with the Company name for segmentation), or key company fields (industry, size, revenue range) become Merge Fields on the Subscriber record. The customer chooses the strategy. We remap the Moskit contact-to-company relationship by querying each Contact's company_id and applying the corresponding Tag or Merge Field value during the Subscriber import.

Moskit custom fields on Contacts (text, number, date, picklist) become Mailchimp Merge Fields. We define each Merge Field in the target Audience before import, matching Moskit field types to Mailchimp field types (text to TEXT, number to NUMBER, date to DATE, picklist to RADIO or dropdown). Picklist values in Moskit become Mailchimp merge tag options. Merge Field names are limited to 10 characters in Mailchimp, so we truncate or abbreviate long Moskit field names per Mailchimp naming conventions and document the mapping in the field glossary.

Moskit Owner (sales rep) assignments on Contacts carry through as a Tag on each Subscriber (e.g., Tag: Owner: João Silva). Mailchimp does not have a user-assignment model where contacts are owned by team members. Tagging by owner allows segmentation by sales rep for re-engagement campaigns or follow-up sequences. If the customer prefers, we can drop owner tagging and rely on Mailchimp's built-in reporting by Audience instead.

Moskit Deal stage names (e.g., Prospecção, Qualificação, Proposta, Fechado Ganho) are not transferable to Mailchimp as deal records, but the stage name is valuable as a subscriber attribute for re-engagement targeting. We extract the most recent Deal stage from each Contact's associated Deals (using deal association records) and apply it as a Tag on the Subscriber (e.g., Tag: DealStage: Proposta). This allows the customer's team to build Mailchimp segments for warm leads versus closed-won customers without rebuilding the full pipeline logic.

If the customer wants to preserve monetary context, we map Moskit Deal amount to a NUMBER Merge Field (e.g., LAST_DEAL_AMT) on the Subscriber record. This is optional and scoped during discovery. It does not create a deal pipeline in Mailchimp; it only stores the most recent deal value for segmentation purposes (e.g., sending a different nurture sequence to subscribers with closed-won deals above a threshold).

Moskit pipeline stages (custom-named per pipeline) migrate as Tags on the Subscriber record. If Moskit has multiple pipelines, we prefix each tag with the pipeline name (e.g., Tag: PipelineVendas: Qualificação). The customer uses these tags in Mailchimp to build segments that reflect their sales funnel position for email nurture sequences.

Moskit Activity notes linked to Contacts are not migratable as note records in Mailchimp, which has no note object. We extract the most recent note text (up to 150 characters) and store it as a Tag on the Subscriber (e.g., Tag: LastNote: Interested in enterprise plan). This preserves the signal without transferring the full activity timeline. The customer should not expect a full activity history in Mailchimp; that data lives in Moskit and is preserved in the source export.