Migrate from cMercury to Nutshell

cMercury Subscribers map to Nutshell Person records. Email address becomes the primary identifier and dedupe key. Subscription status (subscribed, unsubscribed, bounced, risky) migrates as a custom field; cMercury Verify badges (valid, invalid, risky, catch-all) are stored as a custom text field on the Person record so sales reps see contact quality at a glance. Engagement score migrates as a numeric custom field. The mapping resolves by email address match with a duplicate-check pass before insert to prevent multi-record scatter.

cMercury subscriber-level custom profile fields (text, number, date, dropdown) map to Nutshell Person custom fields. We extract the full field schema from cMercury including data type and enumerate options, then pre-create matching fields in Nutshell before any data loads. Multi-value custom fields (checkboxes) map to Nutshell multi-select or are stored as a pipe-delimited text field depending on Nutshell's current field-type support at migration time.

cMercury subscriber tags (flat string labels) migrate as Nutshell Labels on the Person record if the customer's Nutshell plan supports label assignment. If the subscriber has more than 20 distinct tags, we instead create a custom text or multi-select field to avoid label proliferation and preserve the tag vocabulary for segmentation in Nutshell. The customer chooses tag strategy during scoping.

cMercury segments are filter-rule definitions that evaluate at send time. We cannot migrate segment logic as executable rules into Nutshell because Nutshell does not support dynamic segment evaluation. Instead, we resolve the current membership of each named segment at migration time and create Nutshell Static Lists with the segment name. Membership changes made in cMercury after the migration snapshot do not sync automatically; the customer rebuilds segments as static lists in Nutshell as needed.

cMercury Companies (if present in the account) map to Nutshell Company records. The domain field from cMercury becomes the Company Website. If cMercury stores associated subscriber-to-company relationships, we resolve these as Nutshell Person-to-Company relationships by matching domain or manual assignment during the Person import phase.

cMercury engagement scores are numeric values per subscriber reflecting open frequency, click activity, and bounce history. These migrate to a Nutshell custom numeric field (named engagement_score__c or similar) on the Person record. Sales reps see the score as a sortable, filterable property for prioritization. If the score range in cMercury is normalized (0-100 or letter grades), we preserve the normalization; raw numeric scores are imported as-is.

cMercury campaign records (subject, send date, aggregate open/click/bounce counts) have no equivalent object in Nutshell. Nutshell does not store historical marketing campaign performance on contact records. We document the top campaigns and their aggregate stats in a written handoff CSV so the customer can reference them during reporting setup in Nutshell or a separate analytics layer.

cMercury email templates use a proprietary block structure for the drag-and-drop editor. Nutshell has no template library for outbound email composition. Template assets (HTML, images) can be exported from cMercury and stored in a shared drive for manual re-use, but we do not rebuild them into Nutshell-compatible formats as part of standard migration scope.