Migrate from Sales Journey to Freshsales

Discovery and export sourcing

We audit the Sales Journey instance for all standard objects (Contacts, Companies, Deals, Leads), any custom fields the platform supports, pipeline stage names, owner assignments, and engagement/activity volume. Because Sales Journey has minimal public API documentation, we simultaneously assess the available export path—direct UI export, support-assisted export, or API-based extraction—and escalate early if the export mechanism is unclear. The discovery output is a written migration scope document listing every object, custom field, pipeline stage, and owner to be migrated, plus a data quality flag for any records with known gaps.

Destination Freshsales schema setup

We configure the destination Freshsales account before any data moves. This includes creating any custom Contact, Account, Deal, and Lead fields required to receive Sales Journey custom field data. We set up Deal Pipelines with stages mapped from Sales Journey pipeline stages, including probability percentages. We configure the lead conversion field mapping (Sales Journey Lead fields to Freshsales Contact, Account, and Deal fields) per Freshsales' lead conversion model. We confirm the destination Freshsales plan tier to determine API rate limits and batch sizing. Schema changes deploy into a Freshsales test environment for validation before production migration.

Owner reconciliation and User provisioning

We extract every distinct Sales Journey owner referenced on Contacts, Companies, Deals, Leads, and Activity records and match by email against the Freshsales destination account's User table. Any Sales Journey owner without a matching Freshsales User goes to a reconciliation queue. The customer's Freshsales admin provisions any missing Users (active or inactive depending on whether the original Sales Journey user is still active). Migration cannot proceed past this step because OwnerId references are required on most standard objects in Freshsales.

Sandbox migration and reconciliation

We run a full migration into the Freshsales destination account using production-like data volume as a validation pass. The customer's admin reconciles record counts (Contacts in, Accounts in, Deals in, Leads in, Activities in), spot-checks 20-40 random records against the Sales Journey source, and signs off the schema and mapping before production migration begins. Any mapping corrections happen here, not in production. This step also validates that the lead conversion field mapping produces correctly populated Contact-Account-Deal records when a Lead is converted in Freshsales.

Production migration in dependency order

We run production migration in record-dependency order: Accounts (from Sales Journey Companies), Contacts (with AccountId resolved from the Account lookup), Leads (with custom fields mapped), Deals (with AccountId, OwnerId, and pipeline stage resolved), Activity history (Tasks, Calls, Emails, Notes via Freshsales API with rate-limit-aware chunking). Each phase emits a row-count reconciliation report before the next phase begins. Freshsales API rate limits govern batch size: we use exponential backoff and 429 response handling per the plan-tier limits identified in discovery.

Cutover, validation, and automation rebuild handoff

We freeze Sales Journey 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 a written inventory of any Sales Journey workflows, automations, or sequences that require rebuild in Freshsales, with Freshsales Workflow equivalents noted per step. We do not rebuild these inside the migration scope. We support a one-week hypercare window where we resolve any reconciliation issues raised by the customer's sales team. Post-migration, the customer's admin configures Freddy AI scoring models using Freshsales data since these train on in-platform behavior and do not carry over from Sales Journey.