Migrate from Synerise to Freshsales

Synerise Profiles are the primary customer identity object and map directly to Freshsales Contact. The Profile's email, first name, last name, phone, and address attributes map to Freshsales standard fields. Custom profile attributes (beyond Synerise defaults) map to Freshsales custom Contact fields. We flag any Synerise custom attribute names that conflict with Freshsales field naming conventions during scoping — Synerise's immutability constraint means conflicts must be resolved before migration rather than renamed on the source side. Email serves as the dedupe key for Contact deduplication during import.

Synerise has no standalone Company object — company data lives as profile attributes (profile.assigned-to-company) or as Brickworks schema records. We run a pre-migration extraction pass to collect every distinct company value from Synerise profiles, deduplicate by domain, and create Freshsales Account records before any Contact import begins. The Account serves as the parent for every Contact that references that company. If company data lives in Brickworks schemas, we extract those records separately and map them to Freshsales Account custom fields or related custom modules depending on schema complexity.

Synerise transaction records (with line items, totals, timestamps, and payment status) map to Freshsales Deal as the header record and to Deal Products as the line item entries. Transaction amounts map to Deal Amount; transaction date maps to Deal Close Date; payment status maps to a custom Deal field or Deal Stage. We resolve the parent Account and Contact references at migration time so that Deals attach to the correct Account and appear in the correct Contact's timeline.

Synerise behavioral events (product.view, page.visit, added-to-cart, transaction, and 40+ other event types) do not have a native Freshsales equivalent because Freshsales is a sales CRM, not a behavioral data platform. We contextualize each event type: purchase-intent events (added-to-cart, checkout-started) become Tasks with a custom intent__c field; content-engagement events (page.visit, product.view) become Notes attached to the Contact; transaction events that were not already captured in the Transaction mapping become Notes with transaction summaries. We preserve the original event timestamp as Task Activity Date or Note Creation Date and flag the triage in the migration manifest so the customer's admin can audit the event-to-activity mapping.

Synerise Catalogs (product and item feeds) map to Freshsales Products. Catalog item attributes map to Freshsales Product custom fields. Product images, descriptions, and SKUs transfer as Product attributes. Note: Synerise AI recommendation models (personalized, visual similarity, top items) are trained on catalog feeds using Synerise's proprietary Cleora.ai image embedding model — this model is not exportable. We document every recommendation configuration (thresholds, feed references, display rules) in the migration manifest and flag that Freddy AI on Freshsales must be trained independently on the migrated catalog images before recommendations resume.

Synerise segments (Boolean per-profile membership flags from the Segmentation builder) transfer as Freshsales Tags on Contact records. Complex segment rule logic — expressions with multiple conditions, date ranges, or behavioral thresholds — cannot be preserved as runtime logic in Freshsales. We document each segment's rule definition in the migration manifest and recommend recreating equivalent segments as Freshsales contact filters or as Freddy AI training signals for the destination's scoring model.

All Synerise custom profile attributes beyond the defaults map to Freshsales custom Contact fields. Type mapping: string attributes to Text, numeric attributes to Number, date attributes to Date, boolean attributes to Checkbox, and list attributes to Picklist or Multi-select Picklist depending on Freshsales field type availability. Critical constraint: Synerise custom attribute names are immutable — we audit every custom attribute name during scoping and flag any that conflict with Freshsales naming conventions or reserved field names before migration. No renaming on Synerise is possible, so conflicts are resolved on the destination side by accepting the original attribute name or mapping it to a sanitized Freshsales field name.

Synerise Automation Hub workflows are fire-and-forget by design — action completion does not gate workflow progression. This means in-flight Synerise workflows have no recoverable state at cutover. We export workflow definitions (trigger nodes, condition logic, action configurations) as JSON in the migration manifest and document which workflows were active so they can be manually re-activated in Freshsales Automations after cutover. Any time-sensitive drip sequences or time-decayed offer automations will have gaps during the re-activation window. We do not migrate Synerise Workflows as Freshsales automations because the models are architecturally different.

Synerise Brickworks schemas are arbitrary record structures used to store vertical-specific data beyond profile attributes. These have no direct Freshsales equivalent. We extract schema definitions (field names, types, constraints) from the Data Modeling Hub and document them in the migration manifest. The customer's admin recreates them as Freshsales custom modules (available on Garden and above) with equivalent field types and constraints. Data stored in Brickworks schema records migrates to the corresponding custom module records, with lookup relationships to Accounts or Contacts resolved during the migration pass.