Migrate from RedEye to Pipedrive

RedEye's Contact records map to Pipedrive Person. Standard properties (name, email, phone, address) migrate directly. We flag contacts with no company association for resolution: either create a standalone Person or link to a default Organisation record. RedEye's lifecycle stage and behavioural properties migrate as custom fields on Person. If a contact has duplicate email entries in RedEye, we deduplicate using RedEye's unique customer identifier before inserting into Pipedrive to prevent duplicate Persons.

RedEye's B2C model treats Company as a lighter-weight secondary linkage on Contact. Pipedrive's Organization is a first-class entity with its own fields, activities, and deal associations. We create an Organization for every RedEye contact with a populated company field, using the RedEye company name as the Organization name. Contacts without a company field create standalone Persons without a linked Organization. This split requires confirmation during scoping because B2C contact databases may have a high proportion of unassociated individual contacts.

RedEye campaigns have no direct Pipedrive equivalent because Pipedrive is a sales CRM, not a marketing campaign platform. We migrate campaign names, descriptions, start and end dates, and tags as Pipedrive Activities (type: campaign reference) linked to the relevant Person or Deal, and campaign labels as Pipedrive Labels for filtering. The campaign's channel assignments (email, SMS, push) do not carry over because Pipedrive does not execute marketing sends; we flag this during scoping and recommend the customer documents channel migration separately.

RedEye's customer journey builder stores workflow definitions in a proprietary format that cannot be exported and re-imported into Pipedrive. We extract the journey tree structure as a structured rule document listing each journey name, trigger conditions, branch conditions, delay durations, and action steps. Pipedrive Workflows use a different trigger model (deal stage changes, activity completion, field updates) rather than behavioural events. The customer uses the journey rule document to rebuild equivalent logic in Pipedrive Workflows post-migration; we do not migrate journey definitions as executable code.

RedEye behavioural events (website actions, email opens, email clicks, purchase triggers, form submissions) migrate as Pipedrive Activity records with custom fields capturing the original event type and timestamp. We preserve the event-contact association using the Person lookup. Event data is flat-migrated as structured text in custom fields (event_type, event_source, event_timestamp) because Pipedrive's activity model is activity-log-style rather than event-stream-style. Event volumes over 200,000 require chunked API writes with parent-record batch resolution to avoid rate limit violations.

RedEye product catalogue records migrate to Pipedrive Products with SKU, name, pricing, and category fields. RedEye's unlimited product record inclusion on both Essentials and Elevate tiers maps directly to Pipedrive's Product object with no tier constraint. Product associations to contacts (purchase history) migrate as deal-linked Product items or as custom fields on Person, depending on the customer's preferred data model, confirmed during scoping.

RedEye dynamic segments based on behavioural rules and demographic criteria migrate as Pipedrive saved Filters. We extract segment definitions as rule-set documentation listing each filter condition, operator, and value, then rebuild equivalent Filters in Pipedrive using its filter builder. Static segments (fixed contact lists) migrate as Pipedrive Labels applied to the relevant Persons. The rebuild is a manual step the customer performs or we perform as a separate configuration task because Pipedrive's filter logic differs from RedEye's behavioural segment syntax.

RedEye custom fields require explicit field-to-field mapping and must be pre-created in Pipedrive before any record import. Pipedrive custom fields are entity-scoped (Person, Organization, Deal, Activity), so a RedEye contact custom field maps to a Person custom field. We extract the full RedEye field schema during scoping, map each field to the equivalent Pipedrive entity, select the closest Pipedrive field type (text, number, date, drop-down, checkbox), and pre-create the fields in the destination. Complex RedEye field types (multi-select, date-time with timezone, computed fields) require customer decisions on how to flatten or restructure before import.

Contact and campaign tags migrate as Pipedrive Labels applied to the relevant entity (Person, Organization, or Deal). We preserve tag names exactly and flag any tag containing characters unsupported by Pipedrive's label schema. Labels serve as the closest Pipedrive analog for RedEye tag-based segmentation and campaign categorisation.

Campaign assets and contact attachments stored in RedEye export as files via RedEye's file export API and re-upload into Pipedrive Files attached to the relevant Person, Organization, or Deal. We preserve the file hierarchy and naming conventions to minimise manual re-linking. Attachments that were email assets (HTML templates, images) do not carry over as functional campaign assets; only the file record is preserved.