Migrate from cMercury to Twenty CRM

cMercury Subscribers map directly to Twenty CRM Contacts. We map email address, subscription status (subscribed, unsubscribed, bounced), custom profile fields, and tags. The cMercury subscriber ID is preserved in a custom field cmercury_id__c for audit and cross-reference. Engagement score migrates as a numeric custom property engagement_score__c on the Contact record. Subscribers without an email address are flagged in the reconciliation report for manual review before import.

cMercury custom profile fields (text, number, date, dropdown) are provisioned as custom fields on the Twenty CRM Contact object via the /metadata API before import. We map each field by data type: text to TEXT, numbers to NUMBER, dates to DATE, and dropdowns to SELECT with the picklist options created in Twenty's schema. Field labels are preserved; API names are normalised to lowercase_underscore format per Twenty conventions.

cMercury tags are flat labels applied per subscriber. We export all tags and their per-subscriber assignments, then recreate them in Twenty CRM as tag records linked via the Taggable type on Contact. Twenty's tagging model supports multiple tags per contact. If Twenty's tag count exceeds a practical limit for the customer's use case, we discuss converting high-frequency tags to a multi-select custom field instead.

cMercury tracks per-subscriber engagement scores as numeric values. We export the score value and map it to a custom NUMBER field engagement_score__c on the Twenty CRM Contact. If the customer prefers a qualitative label (High, Medium, Low) rather than the raw score, we apply a transformation rule during import based on the customer's existing score thresholds.

cMercury Verify stores validation status per email address (valid, invalid, risky, catch-all). We preserve this badge as a custom SELECT field email_verification_status__c on the Twenty CRM Contact, carrying the original cMercury verification result. This allows the customer's team to filter contacts by verification status in Twenty and make deliverability decisions before sending from the new email platform.

cMercury Segments are defined by filter rules (source, engagement, custom field values). Twenty CRM does not have a native segment equivalent; instead we recreate segment logic as Named Views on the Contact list with the same filter conditions applied as saved filters. Complex nested conditions that cannot be expressed as a single view are documented as a written filter specification for the customer to implement manually in Twenty.

cMercury campaign records include subject lines, send dates, and aggregate performance stats (opens, clicks, bounces, unsubscribes). Since Twenty CRM has no campaign sending capability, we migrate campaign metadata as Activity records (type = Note) on the Contact record, with the campaign name as the subject and performance stats in the note body. Campaign content blocks are not migratable to Twenty's data model.

Aggregate campaign performance data (open rate, click rate, bounce rate, unsubscribe rate per campaign) is exported from cMercury and delivered as a CSV companion file alongside the migration. This allows the customer's admin to reference historical campaign performance in a spreadsheet or BI tool post-migration, since Twenty CRM reporting does not natively accommodate email marketing metrics.

Images and files stored in cMercury's Asset Library are downloaded and attached to the corresponding Contact record in Twenty CRM via Twenty's file attachment model. File names and folder organisation are preserved where possible. Files without a clear contact association are attached to the primary Company record or delivered as a separate file package.

cMercury sending domains are configured with DKIM, SPF, and DMARC records tied to cMercury's infrastructure. We document the existing domain configuration (DNS records, authentication methods) during discovery and deliver a DNS checklist for the customer to reconfigure in their new email sending platform (SendGrid, AWS SES, Postmark, or equivalent) post-migration. Sending domain ownership cannot be transferred between platforms.

cMercury automations are named workflow sequences with triggers, delays, and actions. We document the full automation tree structure, trigger conditions, and action sequence during discovery and deliver a written automation inventory. Since Twenty CRM does not have a native automation engine equivalent and the cMercury automation model is not compatible with any CRM workflow format, the customer's admin rebuilds automations manually in their chosen platform. We estimate 1-2 hours per complex workflow.