Migrate from Kuverto to Mailchimp

Kuverto does not maintain a native contact database; contacts exist in connected third-party integrations (CRM, e-commerce, form tools). We extract contact records from any connected integration Kuverto has access to, or from a CSV export produced by the customer before cutover. Each contact maps to a Mailchimp Audience member. Email address is the dedupe key. Standard fields (first name, last name, phone) map to Mailchimp merge fields FNAME, LNAME, PHONE. Any custom Kuverto-sourced properties map to custom Mailchimp merge fields created before import.

Kuverto stores OAuth tokens and API keys for connected platforms (Salesforce, HubSpot, Stripe, Gmail, etc.). These credentials are scoped to Kuverto's environment and are not portable. We inventory every active integration connection during scoping and produce a re-authentication checklist. The customer must reconnect each integration directly in Mailchimp or a connector layer (Zapier, Make) post-migration. We do not migrate integration logic from Kuverto; the automation flow connecting the integration to the contact record must be rebuilt in Mailchimp Automations.

Kuverto agent definitions (system prompt, memory settings, tool permissions) have no equivalent in Mailchimp. Mailchimp Automations are trigger-action flows for email campaigns, not LLM-powered autonomous agents. We extract the agent configuration summary and produce a written document describing each agent's purpose and the business logic it implements, so the customer's marketing team can rebuild equivalent email automations in Mailchimp. This document is a handoff artifact, not a migrated asset.

Kuverto Workflow Mode sequences (each step = 1 AO) represent automation logic that does not transfer to Mailchimp's automation builder. We inventory every active Kuverto workflow: trigger condition, step sequence, branching logic, and downstream actions. We deliver a written workflow map with recommended Mailchimp Automation equivalents (e.g., a Kuverto 'new lead detected' trigger becomes a Mailchimp 'API trigger' automation). The customer's admin rebuilds each workflow in Mailchimp; we do not implement automation logic in the destination platform.

Kuverto supports team workspaces with roles controlling agent editing, log viewing, and integration management. Mailchimp does not have a role-based permission model per audience member. We map Kuverto workspace role structure to a Mailchimp tagging scheme where internal team labels are applied as tags on the Audience member record, or documented separately as a role matrix for the customer's admin. This is informational mapping only; Mailchimp does not enforce role-based access at the contact level.

Kuverto pre-built and customized agent templates represent automation design patterns. We document the business objective of each customized template as a written brief that the customer's email marketing team can use to design equivalent Mailchimp email templates. Template structure, content blocks, and branding do not transfer between platforms; the brief provides functional continuity rather than code or design migration.

Agent Operations are Kuverto's internal billing metric. They have no counterpart in Mailchimp, which bills on subscriber count rather than operation count. Historical AO usage data is not exported and is not relevant to Mailchimp. We do not migrate billing records. Any AO packs purchased on Kuverto do not carry over and are non-refundable; we include a pre-migration AO audit step to ensure the customer exhausts any transferable credit before cutover.

Agent conversation history and execution logs are ephemeral operational outputs stored by Kuverto and are not exportable through the public-facing platform. Mailchimp has no concept of agent conversation logs. Historical agent run data is lost at migration cutover. We advise customers to export any required run reports or agent output records before the migration window if this data is business-critical.