Migrate from Comet Suite to Mailchimp

Comet contacts become Mailchimp subscribers within a target audience. The contact's primary email address becomes the Mailchimp subscriber key. Status is mapped from Comet contact status to Mailchimp's subscribed/unsubscribed/cleaned states. Properties attach as merge fields. If multiple contacts share the same email, we deduplicate by retaining the most recent record based on the Comet last‑modified timestamp.

Mailchimp has no native company object — company fields (name, industry, website, employee count) migrate as merge fields on each subscriber record linked to that company. This flattens the 1:N relationship and requires deduplication logic when one company has multiple contacts.

Each Comet contact custom property requires a corresponding Mailchimp merge field to be pre-created. Text properties longer than 255 characters exceed Mailchimp's limit and are flagged for truncation or splitting across multiple merge fields before migration. The pre‑migration report lists each affected field, its length, and the recommended handling, which you approve before the migration runs.

Comet's lifecycle stage values (subscriber, lead, MQL, customer) need value mapping to Mailchimp's three-state model (subscribed, unsubscribed, cleaned). Each Comet status that has no Mailchimp equivalent is preserved as a text merge field. During planning, you approve the mapping table; any unmapped stage is stored as a custom field for future segmentation.

Comet tag categories and tag values migrate as Mailchimp tags on each subscriber. Mailchimp tags are flat and label-based; Comet hierarchical categories are flattened into tag names during migration using a category_value format. This approach preserves the original category context while keeping tag names concise for Mailchimp's tag management interface.

Comet owner assignments have no Mailchimp equivalent — Mailchimp has no per-subscriber owner or assignment concept. We preserve the owner email as a merge field (Owner_Email__c) for reference and reconciliation. If multiple contacts share the same owner, each subscriber retains the same Owner_Email__c value, enabling downstream filtering by owner without additional custom logic.

Comet engagement logs (calls, meetings, email history) have no native destination in Mailchimp's audience model. Raw activity data is exported as a CSV reference file for import into a separate BI tool or for manual lookup by support staff. The CSV includes timestamps, owner identifiers, and activity type, allowing analysts to reconstruct engagement timelines in their preferred analytics environment.

Company-level custom properties migrate as merge fields on all subscribers associated with that company. We pre-create the merge field and populate it for each contact record, deduplicating company data during the mapping phase. If a company has multiple contacts, the same merge field values repeat on each subscriber, preserving company context without creating a separate company object.

Comet file attachments associated with contacts or companies cannot be stored in Mailchimp's subscriber records. We export files as a separate archive and provide download instructions; linking them in Mailchimp requires a manual file-hosting step. The archive is organized by contact ID, making it straightforward to match files to the correct subscriber after they are hosted on an external service.

Comet campaign or email send records are not migrated to Mailchimp because Mailchimp campaigns are its own send infrastructure. We export a campaign reference file listing subject lines, send dates, and contact counts for rebuild planning. The reference file can be imported into a spreadsheet or BI tool to help your team recreate comparable campaigns in Mailchimp's campaign builder.