Migrate from Synerise to Pipedrive

Synerise Profiles are the primary customer identity object and map directly to Pipedrive People. Default Profile attributes (email, firstName, lastName, phone) map to Pipedrive Person standard fields. Custom profile attributes require pre-migration audit because Synerise attribute names are immutable after creation — any attribute name that conflicts with Pipedrive naming conventions or reserved field names must be resolved before migration. We extract the full attribute list, run a naming conflict check against Pipedrive's reserved field registry, and document any required rename or passthrough mapping.

Synerise does not have a standalone Company object. Company data lives as profile attributes (company name, domain) or Brickworks schema records. We resolve this in two passes: first, we extract distinct company values from profile attributes and Brickworks company schema records; second, we create Pipedrive Organization records and resolve the Organization ID for each Profile before Person import. If Synerise company data is sparse (no structured company schema), we create Organizations from the company attribute on each Profile and accept a flat organization list without hierarchy.

Synerise Deals are native if the workspace uses the e-commerce or sales module. They map to Pipedrive Deals with the Synerise dealstage mapped to Pipedrive Pipeline stage. If Synerise deal data is stored as Brickworks schema records rather than native Deals, we treat them as schema-to-Deal custom field mapping, which requires a pre-migration schema audit and custom field provisioning in Pipedrive before import.

Each Synerise deal pipeline maps to a Pipedrive Pipeline. Stage names and probabilities transfer to Pipedrive stage configuration. If the source workspace has multiple Synerise pipelines (up to 15), we create corresponding Pipedrive Pipelines during schema setup and configure the stage sequence before any Deal records are imported.

Synerise transaction events (transaction event type) carry line items, totals, and timestamps. These map to Pipedrive Deal records for the financial summary and to Activity records (note type) for the transaction timeline entry. The Deal receives the total amount and close date; the Activity receives the line item detail. Transaction events that are not mapped to a Synerise native Deal become Pipedrive Activities linked to the Person and Organization.

Synerise behavioral events (product.view, page.visit, added-to-cart, and 40+ other event types) are not native Pipedrive objects. We translate high-value behavioral events as Pipedrive Activity records of type note — preserving the event name, timestamp, and key properties — linked to the Person. This is a lossy translation by design: Pipedrive's activity model cannot replicate Synerise's real-time behavioral enrichment. We document every behavioral event type in the workspace and the customer's chosen translation strategy during scoping.

Synerise Catalogs (product/item feeds) export as CSV or JSON from the Data Modeling Hub and map to Pipedrive Products. Catalog item attributes become Pipedrive custom fields on the Product object. We extract the full catalog schema during scoping, provision matching Pipedrive custom fields, and import catalog items as Products with Standard Price Book entries.

Synerise Segments are membership flags per Profile (boolean true/false per segment). We export segment membership as custom fields on the Person record — a custom picklist or checkbox field per Synerise segment. Complex segment rule logic cannot be preserved; the segment membership snapshot migrates as a field value. We document every segment definition and its rule logic in the migration manifest for the customer's admin to recreate in Pipedrive as filters or static lists.

Profile tags are exported as Pipedrive Labels. Tag names are free-form strings with no character restrictions on Synerise. We preserve the full tag set per Profile as Label assignments in Pipedrive. Any tag that exceeds Pipedrive's label character limit is truncated and flagged in the reconciliation report.

Brickworks schemas are arbitrary record structures that have no direct Pipedrive equivalent. We audit every Brickworks schema during scoping, classify each as either a People-level attribute extension (stored as Pipedrive custom fields on Person) or a standalone entity (stored as Pipedrive custom fields on Organization or Deal). Schema field types (string, number, date, boolean, array) are mapped to Pipedrive field types (text, numeric, date, checkbox, multiple-select). Schema definitions must be recreated in Pipedrive before migration.

Synerise Owners (users assigned to profiles, companies, and deals) are resolved by email match against the destination Pipedrive User table. Owners without a matching Pipedrive User go to a reconciliation queue. The customer's admin provisions missing Pipedrive Users before record import resumes. Owner migration is gated by user provisioning — no import phase can proceed without resolved OwnerId on Deals.

Synerise Campaign definitions (email, SMS, push, WhatsApp) export from the Campaigns API with audience rules, templates, and scheduling. Campaign names and target audience size migrate as Pipedrive Activity notes linked to the Person. Campaign automation logic (send time, A/B testing, frequency capping) does not migrate and is documented separately for the customer's admin to rebuild in Pipedrive's Automation rules.