Migrate from Cordial to Pipedrive

Cordial Contacts migrate to Pipedrive People. The Cordial email field maps to Pipedrive's email address, and the standard name fields map to first_name and last_name. We export every custom contact attribute and map each by key name to a Pipedrive custom field of matching type: strings become text fields, numbers become numeric fields, booleans become checkbox fields, and geo types become text or address sub-fields depending on structure. Array-type attributes (tags, favorite colors, behavior lists) require normalization before import; we agree on a delimiter strategy (semicolon-separated) or split into a related table during scoping.

Cordial's flexible data model stores some attributes as arrays (e.g., subscribed channels, tag lists, color preferences). Pipedrive does not support native array fields on People. We normalize each array attribute to a semicolon-delimited string in a Pipedrive text field, or we create a separate lookup table and link it via a custom ID field. We document each array attribute during discovery and agree on the normalization strategy with the customer before migration.

Cordial Lists represent static sub-collections of Contacts. We export list membership as a boolean flag per list or as a comma-separated string in a Pipedrive custom field on Person. Alternatively, we use Pipedrive Tags to represent list membership, with one tag per Cordial list. The customer chooses the strategy during scoping based on how they use lists in Pipedrive reporting.

Cordial Channels (email opt-in, SMS opt-in, push notifications) are stored as sub-attributes on each Contact. We export these as separate boolean custom fields on Pipedrive Person (e.g., email_opt_in, sms_opt_in). Any non-standard channel preferences (e.g., frequency preferences, consent timestamps) migrate to text fields or get flagged for review if no direct Pipedrive equivalent exists.

Cordial Products migrate to Pipedrive Products. The product name, product code, and price map directly. Cordial products with nested variants (color, size arrays) require unpacking: each variant SKU generates a separate Pipedrive Product row with the variant name appended to the product name and the variant attributes stored in custom fields. We preserve the parent Cordial product ID as a reference field for audit.

Cordial does not have a native Orders object; order data is typically stored as custom attributes on Contact or as purchase events in the behavioral stream. We identify all order-related attributes during discovery. For simple order history (last order date, total spend), we map to custom fields on Pipedrive Person. For structured order records (order ID, amount, date, line items), we map to Pipedrive Deals linked to the Person, using a deal title pattern like 'Order: {order_id}' and storing order metadata in custom fields on the Deal.

Cordial behavioral events (opens, clicks, purchases, custom events) migrate to Pipedrive Activities. We map standard event types to Pipedrive Activity types: email opens and clicks become Task records with a descriptive subject, purchases become Task records with order details in the notes, and custom event types become Task records with the event name in the subject and event properties in the description. Activity timestamps preserve the original Cordial event time for timeline ordering.

Cordial Segments are dynamic rules-based audiences that do not have a direct Pipedrive equivalent because Pipedrive uses static filters rather than dynamic rule evaluation. We export the segment membership snapshot (the list of Contacts that matched each segment at migration time) and store it as a Pipedrive custom field on Person (one field per segment with value 'yes' or 'no'). The segment rule logic is documented separately as a written reference for the customer to recreate as static Pipedrive filters or Smart Lists.

If Cordial stores organization or company data as a related collection, it migrates to Pipedrive Organizations. The organization name maps to Pipedrive's name field, domain maps to the website field, and any custom organization attributes map to custom fields on Organization. If Cordial data is contact-centric with no separate organization collection, we extract domain-based organizations from contact email addresses and create Organization records during migration.

Cordial Owners (user accounts that own contacts or campaigns) map to Pipedrive Users. We resolve owners by email match. Any Cordial Owner without a matching Pipedrive User goes to a reconciliation queue for the customer's admin to provision the User account before record import resumes. Owner resolution must complete before Person and Organization import because OwnerId is a required reference on most standard objects.

Cordial message analytics (opens, clicks, bounces, unsubscribes) are available via the Message Analytics Export API and migrate as Task records on the Person with the campaign name in the subject and the metric (open count, click count) in custom fields. Experiment results (A/B test data) are not API-exportable in Cordial and are flagged for manual UI export before migration cutover. If the customer does not need campaign-level analytics in Pipedrive, we deliver an archived CSV export of message analytics for reference.

Cordial Programs and automation sequences are not API-exportable and do not have a direct Pipedrive Workflow equivalent because the trigger models differ. We document the program structure, trigger points, and step sequence in a written inventory delivered to the customer for manual rebuild in Pipedrive's Workflow builder. This document is out of scope for migration as code.