Migrate from Reach to Freshsales

Reach Contacts map directly to Freshsales Contacts using email as the unique identifier. If a Contact in Reach carries company-name and company-domain fields that indicate a distinct business entity, we split the record during migration: the business becomes a Freshsales Account and the person becomes a Contact linked via the AccountId lookup. We validate the split criteria with the customer during scoping because Reach has no documented Account equivalent and company data may be embedded in contact properties. The original Reach contact identifier is preserved in a custom field reach_original_id__c for audit traceability.

Reach's undocumented schema means we discover custom properties at export time by comparing the full column set of the CSV against a baseline Reach contact export. Any column not matching a known standard field becomes a Freshsales custom field pre-created before import. Freshsales enforces a 100-field object limit with sub-limits per type (80 text fields, 30 number fields, 20 multi-select fields, 10 lookup fields). If Reach custom properties exceed these limits, we prioritize the fields actively used in the customer's business process and document the remainder for post-migration configuration.

Reach label and tagging columns extract as values from the CSV export. We map these to Freshsales Tags, which are a native tag object rather than a contact multi-select picklist. Tags migrate with the tag name preserved and applied to the corresponding Freshsales Contact or Account record. We validate that no duplicate tag names exist in the source export before applying, and we strip any tag values exceeding Freshsales character limits.

Reach playlists and screen management assets referenced in reviews may represent files or media links stored against contact records. We extract any attachment-equivalent columns (file URLs, media identifiers, playlist references) as plain-text fields on the Freshsales Contact. Full binary attachment migration requires a separate file inventory from the customer because Reach's export documentation does not describe a file export mechanism. We flag this during scoping and handle it as a conditional scope item.

Reach Enterprise documents a seat-license model with reassignable admin accounts. We extract User records (name, email, role or status) from the Reach export or from the license management interface. Freshsales Users are created by matching on email. Any Reach user without a matching Freshsales User goes to a reconciliation queue for the customer's admin to provision before record import begins. Active vs inactive status is preserved in a custom field reach_user_status__c.

Reach has no distinct Company or Account object documented. If the customer has structured business-entity data in Reach (stored as contact properties such as company name, domain, industry, employee count, or billing address), we extract these as a distinct dataset and create Freshsales Account records during migration. Matching is performed on company domain or exact name match. Any Contact with a matching Account receives the AccountId lookup. This step is conditional on scoping discovery and requires explicit customer confirmation before execution.

The Reach export documentation makes no mention of activity history, call logs, email threads, meeting records, or task lists. We do not migrate activity data unless the customer's actual CSV export confirms the presence of activity columns not documented in available research. We communicate this limitation upfront and recommend that customers document any engagement records they believe exist in Reach so that we can verify against the actual export before declaring scope. New activity data post-migration is captured natively in Freshsales from day one.

If the customer's Reach account contains a distinct Lead record type (separate from Contact) discovered during export, we map it to Freshsales Lead. Freshsales Lead records auto-convert to Contact and Account upon qualification using Freshsales's built-in lead conversion workflow. We preserve any lead score, source, or status fields from Reach as custom fields on the Freshsales Lead record for post-migration scoring and routing.

Reach does not document a Deal or Opportunity object in available research. If the customer has pipeline or deal-stage data stored as custom properties on Contacts (e.g., deal value, stage name, close date as contact fields), we extract these as Freshsales Deal records linked to the corresponding Account or Contact via the Deal's primary contact lookup. We configure the Freshsales pipeline stages, deal statuses, and probability defaults during the schema design phase before migration runs.

If the Reach CSV export contains a notes or comments column, we map these as Freshsales Notes attached to the corresponding Contact or Account via the Notes object's association fields. Rich-text formatting in Reach notes is simplified to plain text during migration to match Freshsales's Notes field capabilities. Notes created post-migration live natively in Freshsales Notes.