CRM migration
Field-level mapping, validation, and rollback between Cordial and Freshsales. We move data and schema; workflows are rebuilt natively in Freshsales.
Cordial
Source
Freshsales
Destination
Compatibility
7 of 10
objects map 1:1 between Cordial and Freshsales.
Complexity
BStandard
Timeline
2-4 weeks
Overview
Moving from Cordial to Freshsales is a platform-type migration: Cordial is an enterprise messaging and marketing CRM built around a flexible JSON contact model and product-centric architecture, while Freshsales is a sales-focused CRM built on the standard Contacts-Accounts-Deals-Activities object model. The primary migration challenge is schema bridging. Cordial stores contacts with unlimited custom attributes and behavioral events; Freshsales stores contacts with a defined field set and custom fields on standard objects. We map Cordial's contact attributes to Freshsales custom fields, resolve Cordial's behavioral event arrays into Freshsales Tasks and custom object records, and unpack nested product variants into individual Freshsales Product2 entries. Cordial's automation programs, segment rules, and message experiment results cannot be exported via API, so these require manual rebuild documentation and UI-based export respectively. We do not migrate Workflows, Sequences, or Forms as code; we deliver written inventories for the customer's admin to rebuild.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Cordial object lands in Freshsales, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Cordial
Contact
Freshsales
Contact (or Lead)
1:1Cordial Contacts map to Freshsales Contact records. The Cordial email address becomes the Freshsales email field and serves as the dedupe key. All standard Cordial fields (first name, last name, phone) map to Freshsales equivalents. Custom contact attributes from Cordial's flexible JSON schema are created as Freshsales custom fields during migration, with type mapping from Cordial string/number/geo types to Freshsales Text/Number/Picklist fields. Array-type attributes (tags, behavioral lists) are normalized to delimited strings or multi-select picklists per the normalization strategy agreed during discovery.
Cordial
Lists
Freshsales
Contact Group
1:1Cordial Lists (static sub-collections within Contacts) map to Freshsales Contact Groups. List membership is preserved as a Contact Group membership record linked to each Contact. We flag any contact belonging to multiple Lists and create corresponding multiple Contact Group memberships in Freshsales.
Cordial
Channels
Freshsales
Contact Communication Preferences
1:1Cordial channel preferences (email opt-in, SMS opt-in) stored as sub-attributes on contacts map to Freshsales contact-level communication preference fields. We map email subscription status to Freshsales Email Status and SMS opt-in to a custom field sms_consent__c. Any non-standard channel preferences are preserved as custom fields.
Cordial
Products
Freshsales
Product2
1:manyCordial products with nested variant arrays (each containing color, size, SKU, and price attributes) are unpacked into separate Freshsales Product2 records, one per variant SKU. The parent product name is preserved in a custom field parent_product_name__c to maintain the relationship. If Freshsales Product Catalog is not enabled on the destination plan (Growth tier includes it), we flag this for customer activation before migration.
Cordial
Products (parent record)
Freshsales
Product2 (parent reference)
lossyCordial parent product records that contain variant arrays but no standalone SKU are preserved as a Freshsales Product2 entry with a custom field is_variant_parent__c set to true, serving as a grouping reference even though the primary SKU data lives in child variant records.
Cordial
Events / Contact Activities
Freshsales
Task
1:1Cordial behavioral events (opens, clicks, purchases, custom event types) with timestamps map to Freshsales Task records linked to the Contact. Event type becomes the Task subject; event metadata (properties, values) is stored in Task description or custom fields. We preserve the original event timestamp in Task due_date and flag high-volume event migrations for batch processing to avoid Freshsales API rate limits.
Cordial
Orders (custom attributes)
Freshsales
Deal + custom fields
1:1Cordial does not have a native Order object; order data is typically stored as custom attributes on contacts or linked via behavioral events. We identify order-related attributes during discovery and map them to Freshsales Deal records (for sales-attributed orders) or to custom fields on the Contact (for historical purchase records). Order total, order date, and order status are preserved as Deal fields or Contact custom fields depending on the customer's data model.
Cordial
Custom Contact Attributes
Freshsales
Custom Fields on Contact
lossyAll Cordial custom contact attributes are enumerated during discovery, typed (string, number, geo, array), and created as Freshsales custom fields before migration. Array-type attributes require normalization: tag lists become multi-select picklists, behavioral history arrays become delimited strings in a text field or a JSON blob in a long-text field. The customer chooses the normalization strategy during scoping. We flag any attribute exceeding Freshsales field type limits for manual review.
Cordial
Segments / Audiences
Freshsales
Contact Group + Saved Filter
1:1Cordial dynamic segments (rules-based audiences built from contact attributes and event conditions) cannot be migrated as executable logic because segment rules have no public export API. We export the segment definition as a written rule summary and identify which contacts currently match each segment. In Freshsales, we create static Contact Groups reflecting the segment membership snapshot at migration time and document the segment rules for manual rebuild as Freshsales Saved Filters or Workflow conditions.
Cordial
Message Analytics
Freshsales
Custom Reports
1:1Cordial message analytics (opens, clicks, bounces, unsubscribes) are available via the Message Analytics Export API but experiment results are explicitly excluded. We export standard message analytics to CSV and import them as Freshsales custom records or as a custom report data set. For A/B and multivariate test results, we recommend manual UI export from Cordial before cutover. Campaign attribution data is preserved in a custom report template for the customer's admin to configure in Freshsales.
| Cordial | Freshsales | Compatibility | |
|---|---|---|---|
| Contact | Contact (or Lead)1:1 | Fully supported | |
| Lists | Contact Group1:1 | Fully supported | |
| Channels | Contact Communication Preferences1:1 | Mapping required | |
| Products | Product21:many | Fully supported | |
| Products (parent record) | Product2 (parent reference)lossy | Fully supported | |
| Events / Contact Activities | Task1:1 | Mapping required | |
| Orders (custom attributes) | Deal + custom fields1:1 | Fully supported | |
| Custom Contact Attributes | Custom Fields on Contactlossy | Fully supported | |
| Segments / Audiences | Contact Group + Saved Filter1:1 | Mapping required | |
| Message Analytics | Custom Reports1:1 | Mapping required |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Cordial gotchas
Message experiment results are not API-exportable
Rate limits are method- and endpoint-specific
Custom contact attribute arrays require schema normalization
Products collection uses nested JSON with variants
Freshsales gotchas
Freddy AI is Pro-tier only despite heavy marketing
Post-migration emails and sequences are disabled
Bot session credits are a one-time 500-session allocation
Phone credits charged per minute with no cap
File storage limits scale with plan tier
Pair-specific challenges
Migration approach
Discovery and schema audit
We audit the source Cordial instance across contact volume, custom attribute count and types, product catalog size and variant structure, list definitions, behavioral event types, order data storage patterns, and active automation programs. We pair this with a Freshsales plan assessment: Growth ($9/user) covers Contacts, Accounts, Deals, Tasks, and basic custom fields; Pro ($39/user) adds contact scoring, sales sequences, and advanced custom fields; Enterprise ($59/user) adds custom modules if the customer has custom objects beyond standard types. The discovery output is a written migration scope and Freshsales plan recommendation.
Attribute schema design and normalization strategy
We enumerate every Cordial custom contact attribute, classify its type (string, number, geo, array), and map each to a Freshsales field type. For array-type attributes, we agree on a normalization strategy with the customer: tag lists become multi-select picklists, behavioral arrays become delimited strings in a text field, and complex nested arrays become long-text JSON blobs. We create all custom fields in Freshsales via the admin UI before any data import and validate that field limits (text length, picklist value count) accommodate the source data.
Product variant unpacking design
We analyze the Cordial product catalog for variant nesting depth and variant attribute types. Each variant SKU becomes a separate Freshsales Product2 record with the parent product ID stored in a custom field. If the customer uses variant-level pricing, we design the Freshsales price book entries to match. We validate the Product Catalog feature is active on the destination Freshsales plan before product migration begins.
Sandbox migration and reconciliation
We run a full migration into a Freshsales sandbox environment using production-like data volume. The customer's team reconciles record counts (Contacts in, Products in, Activities in), spot-checks 20-30 random records against the Cordial source, and validates that array normalization preserved the intended data. Any field mapping corrections, normalization adjustments, or schema additions happen in sandbox before production migration begins.
Production migration in dependency order
We run production migration in record-dependency order: custom fields and Contact Groups (created first), Products (unpacked variants), Contacts (with custom attributes resolved), Accounts (extracted from contact company data), Deals (for order data mapped from Cordial), and Activity history (behavioral events as Tasks via batched API calls with rate-limit handling). Each phase emits a row-count reconciliation report before the next phase begins. We flag any contacts with missing required fields and hold them in a remediation queue.
Cutover, validation, and automation rebuild handoff
We freeze Cordial writes during cutover, run a final delta migration of any records modified during the migration window, then enable Freshsales as the system of record. We deliver the automation program inventory document listing each Cordial program with its trigger, conditions, and recommended Freshsales Workflow equivalent. We support a three-day hypercare window where we resolve reconciliation issues. We do not rebuild Cordial Programs as Freshsales Workflows inside the migration scope; that is a separate engagement or internal admin task.
Platform deep dives
Cordial
Source
Strengths
Weaknesses
Freshsales
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Cordial and Freshsales.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Cordial: Method- and endpoint-specific limits; default limits vary per tier; X-Rate-Limit-* response headers exposed; Retry-After header for backoff; limits are customizable per customer contract.
Data volume sensitivity
Cordial exposes a bulk API — large-volume migrations stream efficiently.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Cordial to Freshsales migration scoping. Not seeing yours? Book a call.
Walk through your Cordial to Freshsales migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Cordial
Other ways to arrive at Freshsales
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.