Migrate from InStream to Freshsales

Discovery and scope audit

We audit the source InStream account across plan tier, contact count, company count, deal count, pipeline stage names, list membership, tag usage, and activity history volume. We extract available custom field definitions from the InStream UI export and identify any social profile URL fields stored in contact records. We confirm the target Freshsales plan and verify that the required custom fields can be created in the destination account. The discovery output is a written migration scope with object counts, pipeline stage mapping table, and custom field reconciliation list.

Data cleansing and preparation

InStream data frequently contains formatting inconsistencies from social imports and free-text fields. We run a data quality pass on contact records to standardize phone number formats, deduplicate email addresses, and flag incomplete records. We remove any records that are hard-deleted in InStream but may still appear in exports. Freshsales documentation recommends data cleansing before migration to prevent dirty data from multiplying in the new system. We deliver a data quality report and resolve duplicates before any records are loaded into Freshsales.

Schema configuration in Freshsales

We configure the destination Freshsales schema before any data loads. This includes creating custom fields to match extracted InStream custom field definitions, configuring Deal stage values to match InStream pipeline stage names, setting up Sales Processes per InStream pipeline, and enabling any Freshsales features (e.g., products, quotes) required by the migration scope. Lead conversion settings are configured to prevent duplicate Account creation when migrated Leads are later converted. Schema is configured in a Freshsales sandbox or trial account first for validation.

Test migration and reconciliation

We run a full test migration into the Freshsales destination using production-like data volume. The customer reconciles record counts (Contacts in, Accounts in, Deals in, Activities in) against InStream source reports, spot-checks 20-30 random records field by field, and validates that pipeline stage mapping preserved deal flow semantics. Any mapping corrections, missing custom fields, or stage name adjustments happen at this stage. We do not proceed to production migration until the customer signs off on the test migration results.

Production migration in dependency order

We run production migration in record-dependency order: Accounts (from InStream Companies) first, then Contacts (with AccountId resolved from the Account import), then Leads for any contacts that did not have a Company association, then Deals (with stage names mapped via the configured stage table), then Tags, then activity history via Freshsales REST API. Each phase emits a row-count reconciliation report before the next phase begins. During cutover, InStream writes are frozen and a final delta migration captures any records modified during the migration window.

Cutover, validation, and inventory delivery

We validate the final Freshsales record counts against InStream source reports, confirm that pipeline stage mapping preserved deal ordering, and verify that all tags are present on the correct contacts. We deliver the List and pipeline configuration inventory to the customer's admin team for manual rebuild in Freshsales. We do not rebuild InStream list segments as Freshsales segments inside the migration scope; the inventory document provides the source list definitions and recommended Freshsales equivalents. We support a three-business-day post-cutover window for reconciliation issues raised by the customer's team.