CRM migration
Field-level mapping, validation, and rollback between Civicrm and Freshsales. We move data and schema; workflows are rebuilt natively in Freshsales.
Civicrm
Source
Freshsales
Destination
Compatibility
4 of 9
objects map 1:1 between Civicrm and Freshsales.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from CiviCRM to Freshsales is a cross-domain migration: CiviCRM is a nonprofit-native CRM with Contributions, Memberships, Grants, and Events as first-class entities, while Freshsales is a commercial sales CRM built around Leads, Contacts, Accounts, and Opportunities. There is no CiviCRM-to-Freshsales native migration path, so data portability depends entirely on the CiviCRM REST API (APIv4) or direct MySQL reads, with Freshsales receiving via its REST API. We handle the contact-type split (CiviCRM Individual, Household, Organization subtypes into Freshsales Contact with type flags), map custom field schemas across both platforms' different field architectures, and deliver a written inventory of CiviMail, CiviCase, Smart Groups, and CiviRules that require a rebuild strategy in Freshsales. We do not migrate Workflows, Sequences, automations, or Mailings as code; we provide the written map for your admin to rebuild them post-migration.
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 Civicrm 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.
Civicrm
Contact (Individual)
Freshsales
Contact
1:1CiviCRM Individual subtype contacts map directly to Freshsales Contact records. We extract first_name, last_name, email, phone, address, and all standard contact fields. Any Individual-specific custom fields (prefixed Custom_ in APIv4) map to Freshsales custom fields on the Contact module. The Freshsales contact_type field is set to individual. If the CiviCRM contact has multiple email addresses, we migrate the primary to email and store secondary addresses in Freshsales custom fields.
Civicrm
Contact (Household)
Freshsales
Contact
lossyCiviCRM Household subtype maps to Freshsales Contact with a custom field civicrm_contact_type__c set to Household. Household address becomes the contact address. Since Freshsales has no native Household object, we use a Contact plus a naming convention (Household Name) and a custom flag to preserve the distinction. If the destination also uses Accounts for organizations, the customer chooses during scoping whether Households remain Contacts or convert to a Company record with household flag.
Civicrm
Contact (Organization)
Freshsales
Account
1:1CiviCRM Organization subtype contacts map to Freshsales Account. Organization name becomes Account Name, and the primary address maps to Billing Address. For small organizations that should also be contacts, we create both an Account and a Contact record linked via the Account lookup. Email, phone, and website (if present) transfer to the corresponding Account fields. Organization custom fields land on the Account as custom fields.
Civicrm
Activity
Freshsales
Task or Event
1:1CiviCRM Activities map to Freshsales Task or Event based on activity type. Meetings and events become Freshsales Event records with Start Time, End Time, and Location preserved. Calls, emails, and general activities become Task records with Subject, Description, and Due Date. Assignee maps to the Freshsales User lookup (resolved by email during migration). Activity type label is preserved in a custom field for audit. CiviCRM activities tied to a case chain are linked to the corresponding Freshsales entity.
Civicrm
Custom Fields (Custom_* multi-record)
Freshsales
Custom Fields
lossyCiviCRM multi-record custom groups appear as separate entities with a Custom_* prefix in APIv4. We reconstruct these as Freshsales custom fields on the relevant module (Contact, Account, or custom module). Custom field types are mapped: text fields, picklists, and date fields map to Freshsales equivalents; multi-select picklists map to Freshsales multi-select fields. For high-volume multi-record tables (exceeding approximately 20 records per parent), we paginate the export to stay within CiviCRM API limits.
Civicrm
Group (static)
Freshsales
Segment
1:1CiviCRM static Groups map to Freshsales Segments (static lists). We export the GroupContact table, resolve each contact to its Freshsales equivalent ID, and create Segment membership records. Group hierarchy (parent and child groups) is preserved as a naming convention in Freshsales segment names. The count of groups in scope determines the segment import volume and time.
Civicrm
Group (Smart/dynamic)
Freshsales
Segment (static reconstruction)
lossyCiviCRM Smart Groups use live database query conditions and cannot be reproduced as dynamic queries in Freshsales, which supports static segments only. We evaluate each Smart Group during scoping, export the current query result set as a static list, and document the original Smart Group criteria in a written handoff so the customer's admin can rebuild the logic using Freshsales filters or workflow conditions post-migration.
Civicrm
Contribution
Freshsales
Deal
lossyCiviCRM Contributions (donations, payments, in-kind gifts) have no native Freshsales equivalent. We map them to Freshsales Deals with a custom field civicrm_entity__c set to Contribution, preserving financial_type, total_amount, currency, receive_date, and payment_instrument. If the organization has multiple contribution types, we set the Deal name to a descriptive label combining contact name and contribution type. Price set line items (for tiered or bundled contributions) are stored as Deal custom fields or a linked Notes record.
Civicrm
Membership
Freshsales
Contact Custom Fields + Segment
lossyCiviCRM Membership records map to Freshsales Contact custom fields (membership_type__c, membership_status__c, membership_start_date__c, membership_end_date__c) plus a Segment membership for each active membership type. We preserve the membership ID as a custom field for reconciliation. Membership Price Sets with tiered pricing are documented in the handoff and optionally mapped to Freshsales plan or product equivalents if the customer uses Freshsales subscription management.
| Civicrm | Freshsales | Compatibility | |
|---|---|---|---|
| Contact (Individual) | Contact1:1 | Fully supported | |
| Contact (Household) | Contactlossy | Fully supported | |
| Contact (Organization) | Account1:1 | Fully supported | |
| Activity | Task or Event1:1 | Fully supported | |
| Custom Fields (Custom_* multi-record) | Custom Fieldslossy | Mapping required | |
| Group (static) | Segment1:1 | Fully supported | |
| Group (Smart/dynamic) | Segment (static reconstruction)lossy | Fully supported | |
| Contribution | Deallossy | Fully supported | |
| Membership | Contact Custom Fields + Segmentlossy | Fully supported |
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.
Civicrm gotchas
Server-to-server migration requires CMS settings file portability
Multi-record custom groups can hit MySQL's 61-join limit
No native bulk export — data portability is API- or database-dependent
CiviCase statuses are per-case-type — not a global status list
Hosted Spark tier has no documented API rate limit — performance varies by plan
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
Scoping and source audit
We audit the CiviCRM instance via APIv4 and direct database read (read-only credentials scoped to the CiviCRM database). We inventory every entity in scope: contact subtypes, activities, groups, custom field definitions, multi-record custom tables, ECK entities, contributions, memberships, events, and relationships. We count Smart Groups separately since they migrate as static snapshots. We run a burst test of 500 API requests to measure the effective rate-limit ceiling on self-hosted and Spark instances. The scoping output is a written migration scope document listing every entity, estimated row counts, and the mapping decisions required before import begins.
Data cleansing and deduplication
We run data quality assessment on Contacts (missing email, duplicate records), Contributions (orphaned contacts with no parent), and Memberships (expired records to exclude). We apply deduplication logic based on email as the unique identifier, flagging records with the same email for the customer's admin to resolve before import. We remove soft-deleted records (is_deleted flag in CiviCRM) unless the customer specifies otherwise. This phase produces a clean CSV or JSON export set ready for Freshsales import and can take one to two weeks depending on the volume of dirty data.
Freshsales schema pre-creation
We pre-create the Freshsales schema before any data loads. This includes custom fields on Contact, Account, and Deal modules (mapped from CiviCRM custom field definitions), segments for each CiviCRM static Group, and any custom picklist values matching CiviCRM option groups. We configure territory assignment rules in Freshsales so that territory logic runs on migrated records during or after import. The schema is validated in a Freshsales trial or development account before production migration begins.
Test migration in non-production
We run a full test migration into a Freshsales non-production environment using production-like data volumes. We reconcile record counts for every entity type, spot-check 25-50 records per entity against the CiviCRM source, and verify that custom field values populated correctly. Any mapping corrections, custom field type mismatches, or picklist value gaps are resolved here. We deliver a reconciliation report to the customer's project lead for sign-off before production migration starts.
Production migration in dependency order
We execute production migration in record-dependency order: Organizations to Accounts first (with organization custom fields), Individuals and Households to Contacts (with type flags and membership fields), then Relationships. Groups export as static segment memberships after contacts resolve. Contributions load as Deals with custom financial fields. Activities (calls, emails, meetings, tasks) load last, resolved against the parent Contact or Account by email lookup. Each phase emits a row-count report before the next begins. Smart Group snapshots are captured from the live CiviCRM query result at migration time.
Cutover, delta load, and handoff documentation
We freeze CiviCRM writes during cutover and run a final delta load of any records created or modified after the migration snapshot began. We deliver a written handoff document covering: every active Smart Group with its original filter logic for Freshsales rebuild, the CiviMail and CiviCase inventory for campaign and case rebuild, the ECK entity schema decisions requiring customer input, and the Workflow automation handoff (CiviRules and extension-based automations do not migrate as code). We support a one-week post-cutover window for reconciliation issues.
Platform deep dives
Civicrm
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 Civicrm 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
Civicrm: Not publicly documented — Spark tier has no published limit; self-hosted performance is infrastructure-dependent.
Data volume sensitivity
Civicrm doesn't expose a bulk API — REST + parallelization used for high-volume runs.
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 Civicrm to Freshsales migration scoping. Not seeing yours? Book a call.
Walk through your Civicrm 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 Civicrm
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.