Migrate from cMercury to Pipedrive

cMercury subscriber records map to Pipedrive People. Each subscriber's email address becomes the Person's primary email field. First name, last name, subscription status, and custom profile fields map to equivalent Pipedrive Person fields or custom fields created during schema setup. The cMercury subscriber ID is preserved in a custom field (cmercury_id__c) for reconciliation. Subscribers without a valid email address are excluded and logged in a separate skip report.

All cMercury subscriber custom fields (text, number, date, dropdown) export with their data types and map to Pipedrive custom fields on the Person object. Field types translate directly: cMercury text to Pipedrive varchar, number to numeric, date to date, dropdown to picklist. Multi-select dropdowns map to Pipedrive multi-select fields. Required-field constraints in cMercury require equivalent required validation in Pipedrive, which we configure during schema setup.

cMercury tags (flat labels applied to subscribers) export as a comma-separated list and load into Pipedrive's Label field on Person. Labels appear in Pipedrive's filter sidebar for segmentation. If a subscriber has more than 10 tags, we spread them across multiple label-style custom fields to stay within Pipedrive's label limits. Tag counts per subscriber are preserved in a numeric custom field for reference.

cMercury Segments are defined by conditional filter rules (source, engagement, custom field values). We translate the segment membership logic into Pipedrive filter conditions and recreate the segment as a named filter view on People. Subscribers are tagged with the segment name as a label so static list behavior is preserved even when Pipedrive's filter views are dynamic. Complex nested conditions may require simplification; we flag any segment with more than three nested condition groups during scoping.

cMercury engagement scores (numeric values per subscriber tracking email interaction) export as a numeric value and load into a Pipedrive custom field (engagement_score__c). A summary Activity note is also created on each Person record noting the original score and the date of migration so the score context is preserved even if the score field is not actively used post-migration. If Pipedrive has a scoring add-on active, we document the mapping for integration configuration.

cMercury Verify badges (valid, invalid, risky, catch-all) per subscriber export as a status value and map to a Pipedrive custom picklist field (email_verification_status__c). Subscribers with invalid or risky badges are flagged in the skip report and loaded as inactive Persons with a note indicating verification failure. Catch-all badges are preserved as a risk flag note. This allows Pipedrive users to filter outreach by email quality before initiating contact.

cMercury campaign records include subject lines, send dates, and aggregate open, click, and bounce rates per subscriber. We aggregate this into a single Activity note per Person summarizing total campaigns received, total opens, total clicks, and bounce history. The note format is structured for readability and includes campaign names and dates as a reference list. Native Pipedrive campaign objects do not exist in Sales CRM plans; this summary approach preserves the data without requiring a custom object configuration.

cMercury email templates use a proprietary block structure for the drag-and-drop editor. Template HTML and image assets export to a folder structure. We deliver the exported assets as a zip file to the customer's admin with a template index noting which templates are active and which are archived. Pipedrive does not have a native template library for outbound email; the HTML assets can be imported into a connected email tool (Gmail, Outlook, or a sales engagement platform) that the customer uses alongside Pipedrive.

cMercury automations are named workflow sequences with triggers, delays, and actions tied to subscriber behavior. No automation data is included in standard exports. We document every automation during discovery: trigger conditions, filter logic, delay durations, and action sequence (send email, add tag, update field, trigger another automation). This inventory is delivered as a structured table for the customer's Pipedrive admin to rebuild using Pipedrive Workflow automation (available from Advanced plan). Automations requiring more than five conditions or external integrations are flagged for partner-assisted rebuild.

cMercury sending domains are configured with DKIM, SPF, and DMARC records tied to cMercury's infrastructure and cannot be transferred. We deliver a DNS reconfiguration checklist during cutover with the records required for the customer's new email sending infrastructure (whether Pipedrive's built-in email, a connected SMTP provider, or a dedicated sending platform). This prevents deliverability gaps during the transition window. The checklist is organized by domain and includes record type, expected value, and TTL guidance.