Migrate from cMercury to Freshsales

cMercury Subscribers map to Freshsales Contacts with email address as the dedupe key. Each contact carries the original cMercury subscription status (subscribed, unsubscribed, bounced) in a custom field, engagement score in a custom numeric field, and cMercury Verify badge in a custom picklist field. Tags from cMercury migrate as a multi-select picklist on the Contact record. Custom profile fields on the subscriber map to custom Contact fields of equivalent type (text, number, date, dropdown). Freshsales territory assignment rules can be configured to run against the imported contacts if the customer uses territory-based routing.

cMercury tags are flat labels stored as a multi-value property per Subscriber. We export all distinct tag values and create a Freshsales multi-select picklist custom field on Contact. The import populates each contact's tag selections from the cMercury data. Tags used for segmentation in cMercury do not create Freshsales Segments automatically; they serve as filter criteria that the customer's admin uses to build Freshsales Views and Filters post-migration.

cMercury Segments are defined by filter rules combining source, engagement level, and custom field conditions. Freshsales does not have a Segment object; we document each segment's definition with its rule tree and recommend Freshsales Views or Filters as the equivalent. Complex nested conditions with more than three levels of AND/OR nesting do not transfer automatically; the admin rebuilds these as Freshsales filter sequences. We flag which segments are critical for business operations during discovery so the admin prioritises them.

cMercury Campaign records contain send history, subject lines, content blocks, send date, and aggregate performance stats (opens, clicks, bounces, unsubscribes). Freshsales has no standard Campaign object. We migrate campaign metadata as a custom Report record linked to the relevant Contacts, storing subject line, send date, and aggregate open/click counts as custom fields. Individual engagement events (opens and clicks per contact) migrate as Freshsales Activity records (notes or tasks) against each Contact. Teams requiring full campaign analytics in Freshsales should plan to rebuild campaign reporting using Freshsales Reports and Dashboard Builder post-migration.

cMercury templates use a proprietary block structure for the drag-and-drop editor. We extract HTML content and inline image references from each template and prepare them as Freshsales-compatible email template content. The destination format uses Freshsales' template editor block structure. Some layout complexity is lost in translation due to differences in how each platform handles responsive grid systems; we flag templates that require significant reworking and provide the extracted HTML as reference. The admin rebuilds templates in Freshsales Template Editor using the extracted content as a starting point.

All cMercury subscriber custom fields export with their data types preserved. We create Freshsales custom fields of matching type (text, number, date, dropdown, multi-select picklist) before importing any records. The mapping between cMercury field names and Freshsales field API names is documented in the field mapping appendix. Custom fields with a dropdown type require the Freshsales admin to populate the picklist options before migration, as import will skip records with values not present in the picklist definition.

cMercury tracks per-subscriber engagement scores as numeric values. We export these scores and map them to a Freshsales custom numeric field on Contact. Freshsales' Freddy AI generates its own contact scoring model based on Freshsales activity data, which is independent of the migrated cMercury engagement scores. Both scoring systems can coexist on the contact record. The customer chooses whether to use the migrated score as the starting value for Freddy AI retraining or as a static reference field.

cMercury Verify stores validation status per email address (valid, invalid, risky, catch-all). Freshsales has no native email verification feature. We preserve all verification badges as a custom picklist field on the Contact record. This allows the customer's Freshsales admin to filter contacts by verification quality and route high-risk addresses through a verification step before adding them to Freshsales email campaigns. The customer should plan to integrate an email verification API (e.g., ZeroBounce, NeverBounce) with Freshsales for ongoing verification of new contacts.

Images and files stored in cMercury's Asset Library are downloaded and re-uploaded to Freshsales Media Library. File names are preserved; folder organisation may not transfer if cMercury uses a nested folder hierarchy that Freshsales does not support. We flag any oversized assets (over 10 MB) that exceed Freshsales media storage limits. Inline images embedded in templates are re-hosted during template reconstruction rather than linked to the original cMercury CDN URLs which will become inaccessible after account closure.

cMercury automations are named sequences of triggers, delays, and CRM actions. Freshsales Workflows use a different trigger-action model with different configuration options. Automations do not migrate as executable code. We deliver a written inventory of every cMercury automation including its trigger conditions, filter logic, delay durations, action types, and action targets. The customer's Freshsales admin uses this document to rebuild equivalent Workflows in Freshsales. Complex automations with more than five conditions or multiple branching paths typically require one to two hours of admin time per workflow for manual reconstruction.